You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Markus KARG <ma...@quipsy.de> on 2006/09/15 11:15:35 UTC
J2EE Client Application JAR is not detected as J2EE module
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
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Markus KARG <ka...@quipsy.de>.
Alexander Sack schrieb:
> 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.
Then this is a JBoss problem but not a EAR-plugin problem, actually.
> JBoss doesn't support Java EE 5 packaging though it does support
> EJB3 jars.
Actually it is not Java EE 5 packaging we are talking about but J2EE 1.4
packaging, actually.
It has nothing to do with EJB3 in fact.
> Let's not get into Websphere's lack of compliance.
Websphere problem are to be handled by websphere but not by Maven, too.
Why always trying to put workarounds for JBoss and Websphere bugs into
Maven?
I have deployed my J2EE 1.4 EARs without any problems on JOnAS and
Glassfish, so in in fact there are at least two open source J2EE 1.4
compliant products that do not need any special tweaks in Maven, so why
should Maven care for the bugs of others?
> Your speaking idealogically, not reality.
See above. We are working with "clean" EARs for years, actually. So what
is not reality on the fact that we are using clean J2EE 1.4 compliant
EARs on two distinct open source products? What is idealism when I say
"ask JBoss and Websphere to fix their bugs"?
> The spec isn't BIBLE
Why shouldn't it be? If you want a J2EE logo, it IS actually.
> 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).
In fact there is no room if you want a J2EE logo. Ask Bill SHANNON (spec
lead) if you think that there is some room for discussions. Actually
there is none at all. You might think there is, but there is not.
> There is also the issue of how compliant an appserver really is.
Either it is, or it is not. There is a certification by Sun that shows
who 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).
JBoss is not certified to be Java EE 5 compliant but only to be J2EE 1.4
compliant. EJB3 is part of Java EE 5.
> 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).
I think the additions are coming because no one of that people have ever
read the J2EE deployment API spec (JSR 88), actually.
> So in a nutshell, for my platform, Jboss is a hybrid Java EE 1.4/5
> platform which transcends THE SPEC.
Again, JBoss is not certified to be EJB 3 compliant currently. That work
is still in progress. Check again JSR 88 compliant packaging once JBoss
is certified by Java EE 5. Until then, try JSR 88 compliant packagin on
current JBoss using the DeploymentManager described by JSR 88 but not
proprietary means of deployment and THEN you'll see that it will work.
In fact, e. g. JOnAS 4.7.6 is not able to support "clean" packaging when
using proprietary tools, but it is when using the specification
compliant ones.
> 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?).
Wrong, once more, sorry: Check that on Glassfish (= Reference
Implementation) and JOnAS 4.8.x.
Both will work without any vendor specific files, actually.
> 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.xml for 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).
Wouldn't it be a nice solution to have the JBoss specifics in a JBoss
plugin, and the Websphere specifics in a Websphere plugin? Why should
the EAR plugin get loaded with all that things that are special to those
products? For example, ANT provides "clean" tasks that can be extended
by vendor-specific ones for EJB handling. So why not doing that in
Maven, too?
> 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.
Why using EAR plugin at all when the result you like to get is not J2EE
compliant but a JBoss invention? I mean, why not adding a JBoss plugin
that creates the type you like, and then set packagin=jboss-ear instead
of ear?
> 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* <karg@quipsy.de <ma...@quipsy.de>> 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* < karg@quipsy.de
> <ma...@quipsy.de> <mailto:karg@quipsy.de
> <ma...@quipsy.de>>> 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 <markkusaarela@kolumbus.fi
> <ma...@kolumbus.fi>
> > <mailto: markkusaarela@kolumbus.fi
> <ma...@kolumbus.fi>>> 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 < waynefay@gmail.com
> <ma...@gmail.com>
> > <mailto: waynefay@gmail.com <ma...@gmail.com>>> 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 < markus.karg@quipsy.de
> <ma...@quipsy.de>
> > <mailto:markus.karg@quipsy.de
> <ma...@quipsy.de>>> 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
> <http://maven.apache.org/plugins/maven-ear-plugin/howto.html>
> > >> >> > >
> > >> >> > > On 9/15/06, Markus KARG <markus.karg@quipsy.de
> <ma...@quipsy.de>
> > <mailto: markus.karg@quipsy.de
> <ma...@quipsy.de>>> 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:
> users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> > <mailto:users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>>
> > >> >> For additional commands, e-mail:
> users-help@maven.apache.org <ma...@maven.apache.org>
> > <mailto:users-help@maven.apache.org
> <ma...@maven.apache.org>>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >>
> > >>
> >
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail:
> users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> > <mailto:users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>>
> > >> For additional commands, e-mail:
> users-help@maven.apache.org <ma...@maven.apache.org>
> > <mailto:users-help@maven.apache.org
> <ma...@maven.apache.org>>
> > >>
> > >>
> > >
> > >
> >
> >
> >
> >
> >
> >
> > --
> > "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
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Alexander Sack <pi...@gmail.com>.
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 <ka...@quipsy.de> 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* <karg@quipsy.de <ma...@quipsy.de>>
> 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 <markkusaarela@kolumbus.fi
> > <ma...@kolumbus.fi>> 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 < waynefay@gmail.com
> > <ma...@gmail.com>> 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 <markus.karg@quipsy.de
> > <ma...@quipsy.de>> 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 <markus.karg@quipsy.de
> > <ma...@quipsy.de>> 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: users-unsubscribe@maven.apache.org
> > <ma...@maven.apache.org>
> > >> >> For additional commands, e-mail: users-help@maven.apache.org
> > <ma...@maven.apache.org>
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >>
> > >>
> >
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > <ma...@maven.apache.org>
> > >> For additional commands, e-mail: users-help@maven.apache.org
> > <ma...@maven.apache.org>
> > >>
> > >>
> > >
> > >
> >
> >
> >
> >
> >
> >
> > --
> > "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
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Markus KARG <ka...@quipsy.de>.
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* <karg@quipsy.de <ma...@quipsy.de>> 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 <markkusaarela@kolumbus.fi
> <ma...@kolumbus.fi>> 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 < waynefay@gmail.com
> <ma...@gmail.com>> 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 <markus.karg@quipsy.de
> <ma...@quipsy.de>> 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 <markus.karg@quipsy.de
> <ma...@quipsy.de>> 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: users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> >> >> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> >> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
> >>
> >>
> >
> >
>
>
>
>
>
>
> --
> "What lies behind us and what lies in front of us is of little concern
> to what lies within us." -Ralph Waldo Emerson
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Alexander Sack <pi...@gmail.com>.
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 <ka...@quipsy.de> 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 <ma...@kolumbus.fi> 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 <wa...@gmail.com> 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 <ma...@quipsy.de> 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.xmlmanually.
> >> >> 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 <ma...@quipsy.de> 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: users-unsubscribe@maven.apache.org
> >> >> For additional commands, e-mail: users-help@maven.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> >
>
>
>
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Markus KARG <ka...@quipsy.de>.
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 <ma...@kolumbus.fi> 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 <wa...@gmail.com> 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 <ma...@quipsy.de> 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 <ma...@quipsy.de> 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: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Alexander Sack <pi...@gmail.com>.
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 <ma...@kolumbus.fi> 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 <wa...@gmail.com> 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 <ma...@quipsy.de> 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 <ma...@quipsy.de> 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: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Markku Saarela <ma...@kolumbus.fi>.
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 <wa...@gmail.com> 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 <ma...@quipsy.de> 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 <ma...@quipsy.de> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Markus KARG <ma...@gmx.net>.
Sorry, wrong, once more. ;-)
The J2EE specification says that an EAR contains not only EJB, WAR, RAR
and other modules, but also one or more Client Application Modules. When
deploying the EAR on the server, it's the server's job to publish the
client to the client machines. For example, SAS9 is using JNLP /
WebStart to support this demand.
I want the EAR plugin to detect that a dependency is not an EJB, WAR or
RAR but such a Client Application Module (by inspecting whether the JAR
contains a /META-INF/application-client.xml file). Such a JAR is not
only to be contained in the EAR (is it is as any JAR is), but also add
an <java>xyz.jar</java> entry to the automatically generated
application.xml file that the EAR plugin creates and puts into the EAR
(as it does it with EJB, WAR or RAR modules already). In fact from the
view of the J2EE 1.4 specification, a client-application JAR is to be
treated as an EJB, WAR or RAR is treated: Detect that it is a module,
detect the type of the module, contain it in the EAR, add an entry to
the application.xml file. Everything is done by the EAR plugin correctly
but not the last step: The EAR plugin currently detects the type of
module (it needs to know the type to know what to write into the
application.xml) by mapping file extensions to module types. For EJB,
WAR or RAR this is sufficient. But to support client applications, the
EAR plugin must learn to differenciate between utility JARs and client
application JARs (since both share the extension of ".jar", so the type
detection is not possible).
To learn this, the work is easy: For each .jar file found in the
dependencies that is to be added to the EAR, check whether there is a
file called "/META-INF/application-client.xml" found inside of that JAR.
If true, the type of this jar is not "JAR" but "application-client", and
such an entry to the EAR's automatically generated application.xml file
has to be added using the "<java>" type of <module> tag. That's all to
be found inside of the J2EE specification, most of it in chapter 9, but
also in the chapter on the application.xml schema (look at the
declaration of <module> and you will find <java>).
So actually the EAR plugin can be extended to support this essential
part of J2EE 1.4 within one or two code lines. Can anybody please add
that? :-)
Thanks!
Markus
Alexander Sack wrote:
> I stand corrected. Never used this feature.
>
> Alright, but from reading the 1.4 spec, it seems that this jar is
> deployed
> outside the app server as a CLIENT. The client application.xml file is
> deployed within a JAR a read by another container than your main EAR
> application, no? So what do you expect the EAR plugin to do exactly?
>
> -aps
>
> On 9/16/06, Markus KARG <ma...@gmx.net> wrote:
>>
>> Alexander,
>>
>> please read J2EE 1.4 specification: The "J2EE Client Application
>> Descriptor" is a mandatory part of J2EE 1.4. It is no BEA invention.
>> Quoted from "Java(tm) 2 Platform Enterprise Edition Specification, v1.4"
>> chapter 9.7 "J2EE Application Client XML Schema":
>>
>> "J2EE.9.7 J2EE Application Client XML Schema
>> The XML grammar for a J2EE application client deployment descriptor is
>> defined
>> by the J2EE application-client schema. The root element of the
>> deployment
>> descriptor for an application client is application-client. The content
>> of the XML
>> elements is in general case sensitive. This means, for example, that
>> <res-
>> auth>Container</res-auth> must be used, rather than
>> <res-auth>container</
>> res-auth>.
>> All valid application-client deployment descriptors must conform to the
>> following XML Schema definition, or to a DTD definition from a previous
>> version
>> of this specification. (See Appendix J2EE.A, "Previous Version DTDs.")
>> The
>> deployment descriptor must be named META-INF/application-client.xml
>> in the
>> application client's .jar file. Note that this name is case-sensitive."
>>
>> So there is actually no room for interpretation. You might want to read
>> J2EE 1.4 spec chapter 9 "Application Clients".
>>
>> Markus
>>
>> 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 <wa...@gmail.com> 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 <ma...@quipsy.de> 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 <ma...@quipsy.de> 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: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>>
>>
>>
>>
>
>
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Alexander Sack <pi...@gmail.com>.
I stand corrected. Never used this feature.
Alright, but from reading the 1.4 spec, it seems that this jar is deployed
outside the app server as a CLIENT. The client application.xml file is
deployed within a JAR a read by another container than your main EAR
application, no? So what do you expect the EAR plugin to do exactly?
-aps
On 9/16/06, Markus KARG <ma...@gmx.net> wrote:
>
> Alexander,
>
> please read J2EE 1.4 specification: The "J2EE Client Application
> Descriptor" is a mandatory part of J2EE 1.4. It is no BEA invention.
> Quoted from "Java(tm) 2 Platform Enterprise Edition Specification, v1.4"
> chapter 9.7 "J2EE Application Client XML Schema":
>
> "J2EE.9.7 J2EE Application Client XML Schema
> The XML grammar for a J2EE application client deployment descriptor is
> defined
> by the J2EE application-client schema. The root element of the deployment
> descriptor for an application client is application-client. The content
> of the XML
> elements is in general case sensitive. This means, for example, that <res-
> auth>Container</res-auth> must be used, rather than <res-auth>container</
> res-auth>.
> All valid application-client deployment descriptors must conform to the
> following XML Schema definition, or to a DTD definition from a previous
> version
> of this specification. (See Appendix J2EE.A, "Previous Version DTDs.") The
> deployment descriptor must be named META-INF/application-client.xml in the
> application client's .jar file. Note that this name is case-sensitive."
>
> So there is actually no room for interpretation. You might want to read
> J2EE 1.4 spec chapter 9 "Application Clients".
>
> Markus
>
> 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 <wa...@gmail.com> 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 <ma...@quipsy.de> 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 <ma...@quipsy.de> 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: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> >
>
>
>
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Markus KARG <ma...@gmx.net>.
Alexander,
please read J2EE 1.4 specification: The "J2EE Client Application
Descriptor" is a mandatory part of J2EE 1.4. It is no BEA invention.
Quoted from "Java(tm) 2 Platform Enterprise Edition Specification, v1.4"
chapter 9.7 "J2EE Application Client XML Schema":
"J2EE.9.7 J2EE Application Client XML Schema
The XML grammar for a J2EE application client deployment descriptor is
defined
by the J2EE application-client schema. The root element of the deployment
descriptor for an application client is application-client. The content
of the XML
elements is in general case sensitive. This means, for example, that <res-
auth>Container</res-auth> must be used, rather than <res-auth>container</
res-auth>.
All valid application-client deployment descriptors must conform to the
following XML Schema definition, or to a DTD definition from a previous
version
of this specification. (See Appendix J2EE.A, “Previous Version DTDs.”) The
deployment descriptor must be named META-INF/application-client.xml in the
application client’s .jar file. Note that this name is case-sensitive."
So there is actually no room for interpretation. You might want to read
J2EE 1.4 spec chapter 9 "Application Clients".
Markus
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 <wa...@gmail.com> 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 <ma...@quipsy.de> 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 <ma...@quipsy.de> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Alexander Sack <pi...@gmail.com>.
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 <wa...@gmail.com> 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 <ma...@quipsy.de> 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 <ma...@quipsy.de> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Wayne Fay <wa...@gmail.com>.
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 <ma...@quipsy.de> 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 <ma...@quipsy.de> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Markus KARG <ma...@quipsy.de>.
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 <ma...@quipsy.de> 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
>>
>>
>>
>
>
Re: J2EE Client Application JAR is not detected as J2EE module
Posted by Stephane Nicoll <st...@gmail.com>.
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 <ma...@quipsy.de> 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
>
>
>
--
Un chewing-gum? Non merci, jamais pour parler.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org