Hi John,
Thanks. I agree that javax.batch 1.0 is there, but I don't see javax.jms
2.0 nor javax.ejb 3.2. I see earlier versions of these, but not the most
current. I tried searching on "javax" and "jms" and "ejb". Maybe I'm not
looking in the right location... Also missing is the latest jpa 2.0 jar.
Again, earlier versions and alternate versions exist with non-javax group
ids, but can those be trusted? For example, there are some artifacts with
org.glassfish.* as their group id. I would assume these are trustable,
but since there are other versions with javax.* group ids, how does one
know which one to use? This is just part of the confusion with the
artifacts and where to find them...
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Kevin Sutter, Java EE and Java Persistence API (JPA) architect
mail: sutter_at_us.ibm.com, Kevin Sutter/Rochester/IBM
http://webspherepersistence.blogspot.com/
phone: tl-553-3620 (office), 507-253-3620 (office)
http://openjpa.apache.org/
From: "John D. Ament" <john.d.ament_at_gmail.com>
To: users_at_javaee-spec.java.net,
Date: 07/19/2013 11:50 AM
Subject: [javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List
for EE 8
Kevin,
So, after doing a quick search, I was able to find these specs up on
search.maven.org: javax.batch 1.0, javax.jms 2.0, javax.ejb-api 3.2.
So, I think the APIs are readily available enough that people can find
them; there's probably some room for improvement around the naming (making
it more consistent, for one, I have no clue what CDI would be called; last
I checked it was javax.enterprise.inject).
On Fri, Jul 19, 2013 at 12:37 PM, Kevin Sutter <sutter_at_us.ibm.com> wrote:
Werner and others,
> Standard artifacts and repositories
This is my current pain in the side... Attempting to find the appropriate
repository for the API jar files for the various technologies has been
challenging. Most of the JSRs used the java.net maven repository. But,
some of the JSRs posted to maven central. While a few others just have
them as part of the RI in Glassfish. I would have thought that the
java.net repo would be the "common" repo, but some of the expert groups do
not agree... This is frustrating. I know I can obtain the full javaee
api on maven central, but the individual api jar files are all spread to
the wind.
Similar type of issue with the specs (early drafts as well as final)...
It would be great if the JCP could define a single repo for storing these
expert group artifacts and require all expert groups to use these
mechanisms. Otherwise, everybody has to search for the proper repo for a
given expert group.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Kevin Sutter, Java EE and Java Persistence API (JPA) architect
mail: sutter_at_us.ibm.com, Kevin Sutter/Rochester/IBM
http://webspherepersistence.blogspot.com/
phone: tl-553-3620 (office), 507-253-3620 (office)
http://openjpa.apache.org/
Werner Keil <werner.keil_at_gmail.com> wrote on 07/19/2013 05:24:51 AM:
> From: Werner Keil <werner.keil_at_gmail.com>
> To: jsr342-experts_at_javaee-spec.java.net,
> Date: 07/19/2013 05:26 AM
> Subject: [javaee-spec users] [jsr342-experts] Re: Wish-List for EE 8
>
> Antonio/all,
>
> Thanks for summing this up on Dzone, too: http://www.dzone.com/
> links/r/my_java_ee_8_wishlist.html
>
> I won't comment on all, especially those that are discussed
> elsewhere or may require further consensus by at least some large
> stakeholders...
>
> No buzzwords
>
> Agree, that is among reasons why a JSR around another buzzword,
> "Social" was turned down, allowing it however, to be fostered along
> the lines of Drools, Hibernate or Arquillian (by the same vendor
> [image removed] ) and I wouldn't outrule some of it spilling back
> into the JCP either in a dedicated JSR or via others (351 being just
> one example where this already started[image removed] )
> Security
>
> See above, given the JCP.next requirements for progress (or
> "hibernation", while of cource some JSRs that didn't get Final are
> still more alive and kicking than others that were declared Final
> [image removed] ) we'll see an EDR of Identity API any time soon,
> and there's going to be a presentation at JavaOne, too. These and a
> few other Spec Leads also got your message for help with Java EE 8
> session content[image removed]
> Enterprise services and stereotypes
>
> This sounds like a great idea, once the definition of such "Service"
> could be standardized and agreed on, too. Plus with EE 8 having to
> carry the burden of SE 8 (see below, things aren't getting so
> modular and reusable as it seems, on the contrary[image removed] )
> it may be too early before Jigsaw or something similar makes Java
> modular enough for that (followed by EE 9[image removed] )
> CDI, CDI, CDI
>
> I can't agree more, and for SE and at least its Embedded version, it
> looks like future CDI Specs should support it. Unfortunately, the
> Java SE ecosystem as a whole got worse with Java 8, especially when
> it comes to reusability and modularization. Your Fellow Java
> Champion Lars Vogel did a nice tutorial on Java Date/Time http://
> www.vogella.com/articles/JavaDateTimeAPI/
>
> Of course, with Java 8 this one won't go away, and while
> java.util.Date is the only one you may call portable as it works all
> the way down to ME Embedded, you got
> java.util.Date/Calendar
> java.util.concurrent.TimeUnit (especially relevant for e.g. new Java
> EE Concurrency[image removed] )
> java.time (incompatible with all the others except a tiny bridge to
> java.util.Calendar)
> javafx.util.Duration used anywhere in JavaFX
> JSR 302 with a HighResolutionTime and API around it, at least for
> Embedded systems or other Security Critical applications, if any of
> it becomes relevant to Java EE 8, at least the estimated schedule of
> both JSRs means, it should be available before or around the time
> Java EE 8 is releases.
>
> plus others like ICU4J or JodaTime where projects use them already
> and do not get rewritten just for the sake of refactoring...
>
> As long as Java keeps growing into a large, monolithic block with
> half a dozen redundant implementations of a (relatively) trivial
> thing like "What's the time?" CDI alone won't help, even if some or
> all of these would be CDI-enabled and work with @Inject.
>
> One of the main problems are "leftover" JSRs like 302, 310 (now
> java.time) or even 107 (JCache, you mentioned it) carrying a legacy
> from a different time (Java EE was still at EJB 2 then or earlier
> [image removed] ) and now half-heartedly squeezed into a Java
> ecosystem of the 21st Century that evolved around technologies like CDI.
> Standard artifacts and repositories
>
> This (aside from Logging, but I leave that aside for now, too[image
> removed] ) could be the most difficult of your wishes. The "IP WG"
> of JSR 358 currently cares not a bit about public APIs, given its
> official scope is only RI/TCK. And depending on the Spec Lead's
> discretion (see https://java.net/jira/browse/JSR358-49 I was the
> only EC Member who identified the problem and the only one with
> enough technical experience to care unfortunately, all others
> discuss legal and other "buzzwords" mostly, and a similar JIRA issue
> you may remember from DevoXX
https://java.net/jira/browse/JSR358-30
> we heard, this is unlikely to happen where people with a more
> technical approach could deal with such problems[image removed] )
>
> Thus you'll end up having some JSRs where the API is considered part
> of the RI, hence its package name may be "com.somecompany.someapi.*"
> while others are defined either via the respective Forge or
> Foundation (org.*) and a few call it "javax.*" or see 310 it gets
> sucked into OpenJDK and ends up "java.*" also quite often the case
> we see "org.glassfish.*" JSRs now.
>
> Based on above JIRA ticket 358-49 almost every Java EE 7 Spec Lead
> and JSR (only 352 reacted too slow or probably still waits for the
> lawyers to talk to each other?[image removed] ) as well as a vast
> majority of those catering towards EE 8 follows minimum requirements
> for the Spec License, but a majority of them also considers the
> scope of the "Spec" to be just a plain text document and the JavaDoc
> of the public API. The API itself usually ends up being part of the
> RI, hence there is no consistent package naming and it's almost
> impossible we'll see a consistent Maven or related artifact naming
either.
>
> --
> Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead,
> Babel Language Champion | Java Godfather | Mærsk DevOps Build Manager
> Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps
> Skype werner.keil | Google+ gplus.to/wernerkeil
>
> * Eclipse DemoCamps Kepler 2013: June-August 2013, Germany,
> Denmark, Austria, Norway. Werner Keil, UOMo Lead, Mærsk DevOps Build
> Manager will present "Triple-E’class DevOps with Hudson, Maven,
> Kokki, Multiconf & PyDev", "M4M 2 the Rescue of M2M"
>
> On Tue, Jul 16, 2013 at 10:32 AM, Antonio Goncalves <
> antonio.goncalves_at_gmail.com> wrote:
> I think that is two different topics.
>
> Back at Devoxx BE 2009, Java EE 6 was going to be released and there
> was already talks about "Java EE 7 and the Cloud". Being involved in
> Java EE and the JCP, plenty of people came to me saying "really,
> Java EE 7 and the Cloud ?". I felt I had nothing to say : no
> consultation between spec leads and expert members. If I go to a 1h
> BOF at JavaOne about Java EE 8, what would I say ? I don't know what
> the spec leads have in mind. I don't know what Java EE 8 will be. I
> would just seat in the room and listen.
>
> What I am proposing is : let's kickoff Java EE 8, at least, between
> spec leads and expert members (if "adoptajsr" adepts want to join,
> great), agree on a road map, and then, we can all go to BOFs,
> conferences, gatherings... and present what Java EE 8 will be. With
> Java EE 7 I would always started my presentations saying "Oracle
> wants Cloud in Java EE 7, but most of the expert members don't".
> That's not a very positive message and doesn't bring cohesion to the
group.
>
> Antonio
>
> On Mon, Jul 15, 2013 at 6:03 PM, Markus Eisele <myfear_at_web.de> wrote:
> Hi Antonio,
>
> As John D. A. pointed out on twitter it might not be the right way
> to do this in a closed circle round. I would offer my insights and I
> would for sure accept such an invitation from oracle but I must say
> that I would love to see a more open (transparent) approach here.
> Might be this could be an adopt-a-JSR effort or some kind of survey.
>
> Cheers,
> M
>
> Am Montag, 15. Juli 2013 schrieb Antonio Goncalves :
>
> Hi all,
>
> I was wondering if we could use JavaOne to brainstorm on Java EE 8.
> And I'm not just talking about a one hour BOF between some spec
> leads/expert members and developers, I am more thinking of a half
> day with only spec leads and expert members.
>
> To be honest, I felt very frustrated when Oracle announced "Java EE
> 7 being Cloudish". Nobody asked what the expert members thought of
> such announcement, of what they had in their mind for the future of
> the plaform.
>
> What do you think of physically meeting before/during/after JavaOne
> and start shaping the future of the platform ?
>
> Antonio
> On Mon, Jul 15, 2013 at 5:48 AM, Markus Eisele <myfear_at_web.de> wrote:
> Hi all,
>
> after the buzz around the EE 7 release is silencing a bit I just
> wanted to take the opportunity to send around a link I came across
> yesterday:
>
> http://arjan-tijms.blogspot.de/2013/07/java-ee-8-wish-list.html
>
> Arjan compiled a list of things he would love to see in EE 8. Good to
> see some of it already on the list but also some new things like
> spending some time to modernize the security frameworks.
>
> Cheers,
> - Markus
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site | Twitter | LinkedIn | Paris JUG | Devoxx France
>