Skip to main content

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

  • From: Kevin Sutter <sutter@...>
  • To: users@...
  • Subject: [javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List for EE 8
  • Date: Fri, 19 Jul 2013 15:41:31 -0500

Thanks, Arun, for the pointer to the maven coordinate page.  This does 
help with navigating the repos and finding the right information.  Now, if 
we could get everybody to follow the naming and versioning rules...  :-)

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



From:   Arun Gupta <arun.p.gupta@...>
To:     users@..., 
Cc:     Kevin Sutter/Rochester/IBM@IBMUS
Date:   07/19/2013 02:32 PM
Subject:        [javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List 
for EE 8



I updated the page at:

https://wikis.oracle.com/display/GlassFish/Java+EE+7+Maven+Coordinates

to describe all the Java EE 7 maven coordinates.

The complete list of Maven dependencies can be seen at:

 - 
http://search.maven.org/remotecontent?filepath=javax/javaee-web-api/7.0/javaee-web-api-7.0.pom

 - 
http://search.maven.org/remotecontent?filepath=javax/javaee-api/7.0/javaee-api-7.0.pom


It would be useful to read the general rules for maven versioning for Java 
EE specifications:

https://wikis.oracle.com/display/GlassFish/Maven+Versioning+Rules

Let me know if you see something missing.

Thanks,
Arun

On 7/19/13 11:39 AM, Kevin Sutter wrote:
Thanks, John.  The search wasn't find these for me, but traversing the 
tree found them.  Thanks. 

Yes, JPA is javax.persistence, but there is no 2.1 nor even 2.0 api jars 
available here... 

Bringing up javaee apis...  What is the difference between 
javaee-endorsed-api and javaee-api? 

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




From:        "John D. Ament" <john.d.ament@...> 
To:        users@..., 
Date:        07/19/2013 01:01 PM 
Subject:        [javaee-spec users] Re: [jsr342-experts] Re: Re: Wish-List 
for EE 8 



JMS 2.0 api: 
http://search.maven.org/#artifactdetails%7Cjavax.jms%7Cjavax.jms-api%7C2.0%7Cjar
 

EJB 3.2 api: 
http://search.maven.org/#artifactdetails%7Cjavax.ejb%7Cjavax.ejb-api%7C3.2%7Cjar
 


JPA's a little more difficult because there doesn't seem to be consistency 
- is it JPA or is it javax.persistence ? 

Personally, I think the best course of action for the API JARs, even JEE 
full and web profiles, is to have each API be its own JAR, groupId = 
javax.ee.{module}, artifactId = {module}-api.  Then introduce a 
javax.ee:web-profile BOM that brings in the webprofile stack, and a 
javax.ee:full-profile.  Or we keep things similar to the way they are, so 
groupId = javax.{module}, and then javax.ee points to these.  Either way, 
I don't think web-profile or full profile should be their own JARs. 

John 


On Fri, Jul 19, 2013 at 1:51 PM, Kevin Sutter <sutter@...> wrote: 
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@..., 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@...> 
To:        users@..., 
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@...> 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 
> 



-- 
http://twitter.com/arungupta
http://blogs.oracle.com/arungupta



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

(continued)

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

Werner Keil 07/15/2013

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

Markus Eisele 07/15/2013

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

Antonio Goncalves 07/16/2013

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

Werner Keil 07/19/2013

[javaee-spec users] [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

John D. Ament 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

John D. Ament 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

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