Quoting the spec is somewhat comical...thank god we aren't talking Java ME...
Try deploying your Glassfish EAR on JBoss and see how far you get. JBoss doesn't support Java EE 5 packaging though it does support EJB3 jars. Let's not get into Websphere's lack of compliance. Your speaking idealogically, not reality. The spec isn't BIBLE and there is INTENTIONALLY a lot of room for interpretation in several areas including packaging (Classpath and scope come to mind can get really nasty). There is also the issue of how compliant an appserver really is. For instance, RIGHT NOW, JBoss supports EJB3 but doesn't support the latest servlet spec or Java EE 5 packing rules (I believe scheduled for JBoss 5.x). In fact, I believe a lot of the EJB3 style plugin questions are coming from folks who aren't sure whether to use the EJB plugin or the JAR one (I use the JAR one since in effect that's all that's really needed) because depending on the platform, the packaging maybe slightly different (some even remember the infamous PAR that was in a draft for the peristence stuff). So in a nutshell, for my platform, Jboss is a hybrid Java EE 1.4/5 platform which transcends THE SPEC. Also, there are always extra files needed to make things ACTUALLY work on the platform that is outside the spec as well as platform quirks that need to be taken into account (what's APP-INF/lib unless your on WebLogic again?). Now back on topic (Maven2!) and my original point, it would be nice if the EAR plugin could generate platform specific files on the fly (jboss-web.xmlfor example) or augment the packaging to fit the platform somewhat (for jboss, if I have a lib directory and I'm on JBoss 4.x, it doesn't support the Java EE 5 lib concept and as such you need to put these libraries in the Class-Path manifest entries a la 1.4 of each EJB JAR associated with the EAR to put them on the class-path - I'm not sure how to do that automatically with Maven2, btw maybe there is a way and I haven't found it yet, still learning Maven2 - oh the EAR deployer on JBoss also doesn't support the Extension mechanism defined by the spec as well, so even when a platform does follow the spec, its only up to a certain point). Architecturally speaking, the platform version could dictate the EAR plugin level of compliance, so if I'm using Maven2 EAR plugin on Glassfish it knows to package things according to Java EE 5 but if I'm on JBoss 3.x, go with 1.4 conventions etc. All I'm saying is that packaging for production is more bound by the PLATFORM the EAR is deployed on then the general SPEC level of compliance (which again, is merely a minimal set of requirements ( e.g. descriptors and their XML schema) to be compliant that can be implemented several different ways). Cheers! -aps On 9/19/06, Markus KARG <[EMAIL PROTECTED]> wrote:
Wrong, once more. ;-) The J2EE 1.4 specification contains a mandatory part namely JSR 88 "J2EE Deployment", which clearly says that all deployment is standard now and there should be no vendor specific packaging. In fact, packaging is specified there is very detail. A J2EE server that wants to use the J2EE logo must not depend on vendor specific packaging. Least people have read JSR 88 and do not know about that. I published an article series in German "Java Magazin" about that in 2004, and I contributed to JOnAS' JSR 88 driver, also started my own JSR 88 installation wizard project on SourceForge, so believe I know what I am talking about. ;-)) So actually today there is no need for vendor specific packaging, since all vendors support those "clean" packages. If not, it is a bug and should get reported. In turn, vendor specifics in the EAR and EJB modules are obsolete. Markus Alexander Sack schrieb: > Yes I realize that....just restating the obvious workaround... > > Btw, I really think the EAR plugin and even the EJB one should have > platform specific options if possible (packaging for Glassfish is much > different than JBoss as an example). > > -aps > > On 9/18/06, *Markus KARG* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > Actually we ARE adding them manually but this thread is about how > we can > make MVN to do that automatically... > Nevertheless, I filed an issue with JIRA in the hope of getting it > fixed > in the next plugin release. > > Thanks > Markus > > Alexander Sack schrieb: > > > Thanks guys....weird, I guess I've never ran into these types of > JARs > > before. With that said, it seems you could add them using the > EAR plugin > > but manually. > > > > -aps > > > > On 9/15/06, Markku Saarela <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > >> > >> Actually application-client is part of J2EE specification. See > section > >> of Application clients J2EE 1.4 spec section 9.7 J2EE > Application Client > >> XML Schema. > >> > >> Ant has targets that can create these Application client artifacts. > >> > >> I also favor for building application client jar for Swing > applications > >> with Maven2. > >> > >> Regards, > >> > >> Markku > >> > >> Alexander Sack wrote: > >> > I'm pretty sure the "J2EE client application descriptor" you > speak of > >> > is a > >> > BEA only primitive and not generic enough to be included in > the EAR > >> > plugin > >> > (please correct me if I'm wrong, I don't remember ever seeing > this in > >> the > >> > J2EE spec). > >> > > >> > With that said a light bult has sort of went off and perhaps > the EAR > >> > plugin > >> > should have a PLATFORM identifier that can fine tune the > packaging > >> > based on > >> > Java EE app server. As anyone who has worked with more than > one app > >> > server > >> > knows, the spec has A LOT of room for interpretation and some > >> > platforms just > >> > aren't compliant (either they choose to be or are catching up). > >> > > >> > Good idea, bad idea? > >> > > >> > -aps > >> > > >> > On 9/15/06, Wayne Fay < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > >> >> > >> >> If the current release of the EAR plugin does not support the > >> >> functionality you desire, you have a few options: > >> >> > >> >> 1. Complain about missing functionality on the Maven User list. > >> >> 2. File a JIRA Enhancement report and hope someone looks at your > >> issue > >> >> and decides it is worth spending some time to implement for > you. > >> >> 3. Write the code yourself, then file a JIRA with your changes > >> >> attached and wait for it to be incorporated into the > released code > >> >> which will take some time to actually land in a non-snapshot > repo > >> >> (several weeks at a minimum). > >> >> > >> >> Pick one from above and do it. In the mean time, if you want > >> things to > >> >> work, you will need to be practical about things -- simply > add the > >> >> entry into the application.xml (or whatever file, I'm not > familiar > >> >> with J2EE Client Apps) manually or in the pom.xml and move > on with > >> >> life. > >> >> > >> >> Wayne > >> >> > >> >> On 9/15/06, Markus KARG <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > >> >> > No I do not mean ejb-client but "J2EE Client Application": > >> >> > What you mean is a JAR containing the interfaces of the > EJBs, but > >> >> what I > >> >> > mean is a standalone ("Swing") application that is to be > run inside > >> >> of a > >> >> > "J2EE Client Container". > >> >> > > >> >> > I have seen that EJB-JARs are enlistet in the EAR's > application.xml > >> >> > automatically, and we want this to happen with the "J2EE > Client > >> >> > Application" also, without adding it to the EAR's pom.xml > manually. > >> >> This > >> >> > should be possible since a "J2EE Client Application" always > >> contains > >> a > >> >> > file named META-INF\client-application-xml, so the EAR > task just > >> >> need to > >> >> > look into the JAR to find out about its type. I do not > >> understand why > >> >> > this has to be specified manually. > >> >> > > >> >> > Thanks > >> >> > Markus > >> >> > > >> >> > Stephane Nicoll schrieb: > >> >> > > >> >> > > you mean ejb-client? Your dependency should be > 'ejb-client' not > >> >> 'jar'. > >> >> > > > >> >> > > Anyhow, if you want a jar to be included in the > application.xml, > >> >> just > >> >> > > configure the plugin acccordingly > (includeInApplicationXml) [1] > >> >> > > > >> >> > > Cheers, > >> >> > > Stéphane > >> >> > > > >> >> > > [1] > http://maven.apache.org/plugins/maven-ear-plugin/howto.html > >> >> > > > >> >> > > On 9/15/06, Markus KARG <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > >> >> > > > >> >> > >> I am using the EAR packaging to let Mvn2 create an .ear > file > >> plus > >> >> > >> automatically create an application.xml inside of it. > >> >> > >> It detects all my EJB modules, but it doesn't detect > that one of > >> >> the > >> >> > >> included JARs is not a utility JAR but in fact a "J2EE > Client > >> >> > >> Application JAR". > >> >> > >> Maybe the packaging type I have used for that JAR is > wrong (I > >> used > >> >> JAR > >> >> > >> since I thought the EAR packager will detect the contained > >> >> > >> client-application.xml file). > >> >> > >> So what is the correct way to specify "J2EE Client > Application > >> JAR" > >> >> > >> packaging instead of simple utility "JAR" packaging? > >> >> > >> > >> >> > >> Thanks a lot! > >> >> > >> Markus > >> >> > >> > >> >> > >> > >> >> > >> > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> > > >> >> > >> >> > --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> >> > >> >> > >> > > >> > > >> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> For additional commands, e-mail: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >> > >> > > > > > > > > > > > -- > "What lies behind us and what lies in front of us is of little concern > to what lies within us." -Ralph Waldo Emerson
-- "What lies behind us and what lies in front of us is of little concern to what lies within us." -Ralph Waldo Emerson
