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
> >
>