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
begin:vcard fn:Markus KARG n:KARG;Markus org:QUIPSY QUALITY GmbH;Entwicklung / R & D adr:;;Stuttgarter Strasse 23;Pforzheim;Baden-Wuerttemberg;75179;Bundesrepublik Deutschland email;internet:[EMAIL PROTECTED] title:Staatl. gepr. Inf. tel;work:+49-7231-9189-52 tel;fax:+49-7231-9189-59 note:QUIPSY(R) Entwicklung / R & D x-mozilla-html:TRUE url:http://www.quipsy.de version:2.1 end:vcard
smime.p7s
Description: S/MIME Cryptographic Signature
