Well like all these things, after you've written them down, the answer pops
up.

I now simply define a property in the profile (that can be different per
build profile) e.g.

<junitee.optional.war.excluded>false</junitee.optional.war.excluded>

then in the EAR's pom.xml I configure the maven-ear-plugin

<webModule>
  <groupId>mygroup</groupId>
  <artifactId>myArtifact</artifactId>
  <contextRoot>/myContextRoot</contextRoot>
  <bundleFileName>myArtifact.war</bundleFileName>
  <excluded>${junitee.optional.war.excluded}</excluded>
</webModule>







On 17/02/06, Lee Meador <[EMAIL PROTECTED]> wrote:
>
> How about an optional ant task that runs after the 'package' phase in the
> ear project that runs winzip or something similar to delete the war from
> the
> ear. Ant probably has a way to remove a file from a jar but I don't
> remember
> ever needing to do that.
>
> Its ugly but it would work.
>
> I do something similar to run the websphere 'end point enabler' on the ear
> that maven 2 just finished building. It adds an additional war into the
> ear
> and what-not.
>
> -- Lee
>
> On 2/17/06, Pete <[EMAIL PROTECTED]> wrote:
> >
> > I have an EAR project that includes a normal webapp, but also a JUnitEE
> > testing WAR.
> > For some builds we need it in the EAR, but for a live build we don't
> want
> > it
> > aggregated.
> >
> > Now I guess I could wrap the EAR plugin in a profile, but the EAR
> plugin's
> > <configuration> section is very long, so this would mean repeating all
> of
> > it
> > bar one <webModule>  , and it would also mean we would need to maintain
> > changes in two places - probably leading to an error only detectable in
> a
> > live build.
> >
> > Is there any more simple way to achieve this ?
> >
> > I remember in Ant I used to cheat by declaring a property  e.g.
> > optional.junitee.war
> > and then I'd only set its value to the war file name if not a '
> live.build'
> > ,
> > so for a live build it would be unset and the Ant EAR/JAR mechanism
> > doesn't
> > complain if it can't aggregate a file. In Maven all dependencies have to
> > be
> > valid, so I can't use this dynamic dependency type of thing.
> >
> > Any thoughts / ideas appreciated .
> >
> >
>
>
> --
> -- Lee Meador
> Sent from gmail. My real email address is [EMAIL PROTECTED]
>
>

Reply via email to