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_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 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_
> <http://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_at_us.ibm.com_
> <mailto:sutter_at_us.ibm.com>> 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_at_us.ibm.com_ <mailto: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_
> <mailto:john.d.ament_at_gmail.com>>
> To: _users_at_javaee-spec.java.net_ <mailto: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_ <http://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_
> <mailto: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_ <http://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_
> <http://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_ <mailto: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_ <mailto:werner.keil_at_gmail.com>>
> wrote on 07/19/2013 05:24:51 AM:
>
> > From: Werner Keil <_werner.keil_at_gmail.com_
> <mailto:werner.keil_at_gmail.com>>
> > To: _jsr342-experts_at_javaee-spec.java.net_
> <mailto: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/_
> <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_
> <http://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_ <mailto: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_
> <mailto: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_
> <mailto: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
> >
>
>
--
http://twitter.com/arungupta
http://blogs.oracle.com/arungupta