The top-level goal is something like this:
<project default="my-goal"
xmlns:j="jelly:core">
<goal name="set-environment">
<j:choose>
<j:when
test="${systemScope['os.name'].startsWith('Windows')}">
<j:set var="jboss.home"
value="${windows.jboss.home}" />
</j:when>
<j:otherwise>
<j:set var="jboss.home"
value="${solaris.jboss.home}" />
</j:otherwise>
</j:choose>
</goal>
<goal name="my-goal" prereqs="set-environment">
<j:set var="maven.multiproject.basedir"
value="${root.build.dir}/sub-projects" />
<attainGoal name="multiproject:install" />
</goal>
</project>
The jboss.home value is used in one of the goals run by
multiproject:install.
I would prefer not to set jboss.home in ~/build.properties because I would
prefer for the project to be entirely self-contained -- that's why I looked
at using bootstrap-project in the first place.
> -----Original Message-----
> From: Brett Porter [mailto:[EMAIL PROTECTED]
> Sent: 24 March 2004 22:38
> To: 'Maven Users List'
> Subject: RE: bootstrap-project not working quite right.
>
>
> Hi Peter,
>
> Inheritence handling in 1.0 is not the best, but is something
> we'll work on
> in future versions of maven.
>
> What actually happens is that maven.xml goals are inherited,
> but properties
> are not. So what is probably happening is that the goal is
> being inherited
> when you run a subproject and resetting the property to what
> it finds in the
> subproject: that being nothing.
>
> How have you defined the goal in the root project?
>
> It is weird that this would only affect bootstrap, because
> while in RC2 it
> is done via an internal call, in RC1 it was a forked maven
> instance that
> should be identical to running from the command line.
>
> Is there a reason you can't set jboss.home in
> ~/build.properties? This makes
> more sense to me.
>
> - Brett
>
> > -----Original Message-----
> > From: Peter Bright [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, 24 March 2004 10:34 PM
> > To: Maven Users List (E-mail)
> > Subject: scm:bootstrap-project not working quite right.
> >
> >
> > Hello
> >
> > I have a multiproject project set up something like this:
> >
> > /root-project
> > maven.xml
> > project.xml
> > project.properties
> > /sub-projects
> > /sub-project-one
> > maven.xml
> > project.xml
> > project.properties
> > /sub-project-two
> > maven.xml
> > project.xml
> > project.properties
> >
> > etc..
> >
> > The root's project.properties defines a couple of
> > (system-dependent) properties (let's say, windows.jboss.home,
> > solaris.jboss.home); a goal within its maven.xml then picks
> > the right one (depending on the OS) and puts them into a
> > third property (say, jboss.home). The sub-projects then use
> > this third property.
> >
> > This all works fine (whether it be ideal or not I don't know.
> > I inherited the layout and am unwilling to rearrange things
> > without good reason).
> >
> > What I would like to do is to be able to use
> > scm:bootstrap-project to check out the project and run the
> > default goal. Here's where the problem lies, using both
> rc1 and rc2.
> >
> > The checkout happens normally, and the project begins
> > building. It then reaches a part that depends on the
> > property dynamically set at runtime -- jboss.home, and
> > promptly fails. <echo>ing the variable shows that it's
> > blank. It gets set fine in the root maven.xml but goals in
> > the subproject maven.xml can no longer see it.
> >
> > If I traverse to the checkout directory and run the same goal
> > from there, it works fine; the jboss.home property gets
> > correctly set and is accessible to the subprojects. It only
> > seems to be when run from scm:boostrap-project that it
> > doesn't seem visible.
> >
> > Does anyone know why this value isn't getting inherited
> > properly when using scm:bootstrap-project? Should the
> > project even work in the first place?
> >
> > I apologize in advance if I'm omitted any necessary details;
> > I'm not really sure what else needs to be said.
> >
> > Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
