well the constraint is mainly to keep javaee-api used in tomcat without all web api
having the javaee-api with jsf in embedded mode doesn't make sense since in openejb-standalone we don't manage jsf that's said we can certainly create a javaee-api-full. If you want to contribute it just enhance: http://svn.apache.org/repos/asf/openejb/trunk/javaee-api/ 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>: > 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
