>From an app dev perspective, I don't want to see any server specific dependencies in my POMs. In theory, I should be fine using the offical javax:javaee-api with scope provided. In practice, this is a real PITA since Oracle provides munged bytecodes, which breaks most tests https://community.jboss.org/wiki/WhatsTheCauseOfThisExceptionJavalangClassFormatErrorAbsentCode.
For this reason, I always use the Geronimo Spec APIs in place of javax:javaee-api, but this is a bit tedious because there's no umbrella jar and you need to pick all the individual spec jars. So if Apache or anyone else provided a COMPLETE drop-in dependency, app devs would require just one JAVA EE dependency. This is completely unrelated to what you do in the server: it's just irrelevant to the app dev whether you have an all-in-one-minus-faces JAR or the whole lot of individual Geronimo spec JARs in tomee/lib. Of course I could roll my own all-in-one dependency the way JBoss did, only based on Apache artifacts, but why should every TomEE user have to do that on their own? Best regards, Harald 2012/12/14 Romain Manni-Bucau <rmannibu...@gmail.com>: > forget about compile time, all will work > > i don't speak about java interface or implementation, i speak about > jar api and jar implementation > > the main point is for users customizing the server itself (tomee/lib). > If you want to put mojorra here you can't without managing the whole > javaee api jars manually if we put the jsf api inside. In practise it > is easier to not do it. > > BTW i still don't really get your issue. > > The renaming is IMO not relevant because: > 1) the api inside are standards (if we call it oepnejb-javaee-api it > will sounds like our own stuff) > 2) the groupId already differentiate it > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2012/12/14 Harald Wellmann <hwellmann...@gmail.com>: >> I think you're mixing up interface and implementation. The API JAR >> should be used at compile time only, not at runtime. >> >> Well, what's the point in a Java EE umbrella jar if it's not complete? >> So far, I've been using individual Geronimo Spec dependencies which I >> was hoping to replace by a single overall dependency. >> >> The issue is that the name is misleading, because the TomEE Java EE >> API JAR is NOT a drop-in JAR for the official version. So I'd suggest >> you either add the missing Ffaces stuff, or change the name, or maybe >> provide two distinct artifacts. >> >> JBoss has a drop-in artifact which appears to be complete, which I >> haven't tried yet. >> >> Are you saying that a webapp compiled with the JBoss API flavour >> (provided scope only) cannot be deployed to TomEE? >> >> Best regards, >> Harald >> >> 2012/12/14 Romain Manni-Bucau <rmannibu...@gmail.com>: >>> YOU yes but you are not alone and javaee-api is not only used in TomEE. >>> >>> basically we added it in javaee-api for a time but was adding more >>> drawbacks than advantages. >>> >>> That's said what's the issue with having 2 dependencies? >>> >>> Romain Manni-Bucau >>> Twitter: @rmannibucau >>> Blog: http://rmannibucau.wordpress.com/ >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> Github: https://github.com/rmannibucau >>> >>> >>> >>> 2012/12/14 Harald Wellmann <hwellmann...@gmail.com>: >>>> Suppose the jsf-api were contained in javaee-api. When I compile my >>>> app against javaee-api, I have to use Maven scope "provided" anyway, >>>> and I don't really care which API implementations are used by the app >>>> server runtime. So where's the problem? >>>> >>>> Best regards, >>>> Harald >>>> >>>> 2012/12/14 Romain Manni-Bucau <rmannibu...@gmail.com>: >>>>> impl and api part of this spec are linked == the api jar can't be use >>>>> with other impl (mojarra api + myfaces impl or the opposite wouldn't >>>>> work) >>>>> >>>>> Romain Manni-Bucau >>>>> Twitter: @rmannibucau >>>>> Blog: http://rmannibucau.wordpress.com/ >>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>> Github: https://github.com/rmannibucau >>>>> >>>>> >>>>> >>>>> 2012/12/14 Harald Wellmann <hwellmann...@gmail.com>: >>>>>> I don't get the point. Other Java EE Spec JARs also contain real >>>>>> classes and not just interfaces. What's so special about the JSF API? >>>>>> >>>>>> 2012/12/14 Romain Manni-Bucau <rmannibu...@gmail.com>: >>>>>>> yes, >>>>>>> >>>>>>> it is in myfaces-api. >>>>>>> >>>>>>> The JSF API contains...implementation..so it cannot be part of the >>>>>>> main javaee-api otherwise you cannot override it anymore. >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> Twitter: @rmannibucau >>>>>>> Blog: http://rmannibucau.wordpress.com/ >>>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>>>>>> Github: https://github.com/rmannibucau >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2012/12/14 Harald Wellmann <hwellmann...@gmail.com>: >>>>>>>> When I came across this artifact >>>>>>>> >>>>>>>> <groupId>org.apache.openejb</groupId> >>>>>>>> <artifactId>javaee-api</artifactId> >>>>>>>> <version>6.0-4</version> >>>>>>>> >>>>>>>> I was hoping to have found a drop-in replacement for the infamous >>>>>>>> javax:javaee-api containing mutilated bytecode. >>>>>>>> >>>>>>>> But it's not the complete Java EE API, javax.faces is missing for >>>>>>>> instance. Any good reason for that? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Harald
