From: Werner Keil <werner.keil_at_gmail.com>
Date: Fri, 19 Jul 2013 22:14:58 +0200
Kevin/all,
Thanks for the reply and seconding such worries. Markus among others just
pointed to this listing at Oracle:
https://wikis.oracle.com/display/GlassFish/Java+EE+7+Maven+Coordinates
Quite a striking evidence for a not very coordinated naming, especially the
groupIds. Especially "org.eclipse.persistence" seems extremely bad and out
of the ordinary. While the artifactId is "javax.persistence", a mix of 2
package namespaces. Most others are quite mixed up, only 2 have
"javax.enterprise" in the groupId, but not in a consistent way between the
two either.
Unfortunately even in case of a JSR lead by your own company this looks
confusing:
<artifactId>javax.batch-*annotation*</artifactId>
This is a subset only meant for the annotations,
In fact, if you look at this query:
http://www.maven-repository.com/artifact/javax.batch it is simply *WRONG*[?]
javax.batch-annotation has not gone beyond 1.0-b17, the only artifacts in
version 1.0 final are javax.batch-api or jbatch.
Sad to see, JSR 252 once again is subject to issues or at least
misinformation, whether this was from the Spec Lead's side or authors of
the Wiki (Arun?![?]) I don't want to speculate, but hope, this gets fixed
ASAP?[?]
Given a few Spec Leads (also especially under the EE umbrella) expressed
the desire to relicense artifacts more or less based on where those are
located (even the actual Spec in some cases[?]) this further complicates
the question of using dependency mechanisms like Maven, Artifactory, etc.
If the worst comes to the worst, the repository you'll get something may
contain an artifact under a totally different license.
The JCP.next Working Groups aim to simplify that, but there is practically
nobody in that group or the entire EC even hoping to understand Maven or
similar systems, as mentioned. Interestingly Richard who is responsible for
Oracle's Open Source strategies did at least a while ago also touch code,
whether or not that may help with problems like these, I can't say, but at
least it can't hurt.
In the absense of the mentioned Architecture Council, the EE Umbrella
Spec Lead and EG (at least for 8) should probably try to look after those
things.
Werner
On Fri, Jul 19, 2013 at 6: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
> >
>
