> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: dimanche 21 août 2005 09:08
> To: Maven Developers List
> Subject: Re: [m2] Is "sibling jars" use case supported?
>
> I don't understand a part of this - you talk about using dependency
> properties, but the only thing you want to change per jar is some config
> file in the JAR?
What I was suggesting below was to add a feature in the *m1* jar plugin that
allows to depend on other jars so that jars could be added to jars. A bit
like a simplified jarjar feature. I discussed it on IRC and it was pointed
to me that this was the goal of the m2 assembly plugin and that instead of
adding this feature to the m1 jar plugin it would be better to backport the
m2 assembly plugin...
I agreed but I don't have the time right now to do this backport.
In addition to this, my question here was on jars whereas I've found that my
use case was actually about ejb-jars... :-) Now the ejb plugin does support
depending on a jar but it does not unpack it so it was good enough for me.
> What is the different config file?
They are different deployment descriptors.
In the end I've implemented it using 3 projects: a common one producing a
jar and 2 others producing ejb-jars wrapping this jar with:
<postGoal name="ejb:ejb">
<ant:jar update="true"
destfile="${maven.ejb.build.dir}/${maven.ejb.final.name}">
<ant:zipfileset
src="${pom.getDependencyPath(
'com.sun.j2ee.blueprints:components-asyncsender-common')}"/>
</ant:jar>
<ant:jar update="true"
destfile="${maven.ejb.build.dir}/${maven.ejb.client.final.name}">
<ant:zipfileset
src="${pom.getDependencyPath(
'com.sun.j2ee.blueprints:components-asyncsender-common')}"
excludes="${maven.ejb.client.base.excludes},
${maven.ejb.client.excludes}"/>
</ant:jar>
</postGoal>
Not very neat but I don't see any other solution right now apart from
either:
- backporting the assembly plugin
- adding a specific: ejb:modify-dd goal in the ejb plugin. But that would
require also adding new install and deploy goals to deploy the modified
ejb-jar and that's not scaling.
> If you always want to generate both,
> I think separate projects are ideal, where the second project uses the
> assembly plugin to repack the original JAR with the new config file.
Yep, that's what I was suggesting for m2 and I wanted confirmation. Thanks.
> If it is one jar produced twice for different environments, profiles are
> the right solution. In this way, only one jar is produced in the run,
> but the one produced depends on the target environment (using profiles).
Yes, that's another solution but that would require internally calling this
project twice from higher level projects as both ejb-jars are required to be
packaged in 2 different EARs (one standard and one admin). Now yes we could
probably bubble this up in the build so that there is a "standard" build and
an "admin one.
In any case, I was only really asking if there was a solution for this use
case in m2 and the answer is yes and it's the assembly plugin.
Don't worry for my m1 need as in the end I was doing this to transform the
Java Petstore Ant build for an article and in the end I'm using the
xPetstore instead and I don't have this need anymore.
[snip]
Thanks
-Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
