Skip to main content

[javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List for EE 8

  • From: Arun Gupta <arun.p.gupta@...>
  • To: "jsr342-experts@..." <jsr342-experts@...>
  • Cc: "users@..." <users@...>
  • Subject: [javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List for EE 8
  • Date: Fri, 19 Jul 2013 13:35:59 -0700

Werner,

I'll update the wiki once I land in Shanghai and have network connectivity.

The maven central URLs mentioned on that page are authoritative anyway.

Thanks
Arun

Sent from my iPhone

On Jul 19, 2013, at 1:14 PM, Werner Keil <werner.keil@...> wrote:

> 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<33D.gif>
> 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?!<322.gif>) I don't want to speculate, but hope, this gets 
> fixed ASAP?<35F.gif>
> 
> 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<326.gif>) 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@...> 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@..., 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@...> wrote on 07/19/2013 05:24:51 AM:
>
>> > From: Werner Keil <werner.keil@...> 
>> > To: jsr342-experts@..., 
>> > 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@...> 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@...> 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@...> 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 
>> > 


[javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List for EE 8

(continued)

[javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List for EE 8

Arun Gupta 07/19/2013

[javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List for EE 8

Kevin Sutter 07/19/2013

[javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List for EE 8

arjan tijms 07/19/2013

[javaee-spec users] Re: Wish-List for EE 8

Bill Shannon 07/19/2013

[javaee-spec users] Re: Wish-List for EE 8

Antonio Goncalves 07/22/2013

[javaee-spec users] Re: Wish-List for EE 8

Bill Shannon 07/22/2013

[javaee-spec users] Re: Wish-List for EE 8

Pete Muir 07/22/2013

[javaee-spec users] Re: Wish-List for EE 8

Anatole Tresch 07/22/2013

[javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List for EE 8

Pete Muir 07/19/2013

[javaee-spec users] [jsr342-experts] Re: Re: Wish-List for EE 8

Werner Keil 07/19/2013

[javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List for EE 8

Arun Gupta 07/19/2013
 
 
Close
loading
Please Confirm
Close