My apologies Marshall, not quite sure how it occurred but my answer was
for an entirely different question by someone else.
To answer your question, Maven seems to be working largely as designed.
I'm actually surprised that your child POMs could build in any scenario
if their reference to the parent POM contains a build property only
found in the parent POM. Because that would be a circular reference.
You should really have groupId, artifactId and version hard-coded in all
POMs.
The standard Maven way of doing things would be to have the version
hard-coded with a similar value as the version of the parent in the
child POMs. You would then use the release-plugin to manage the
increment of the version.
Is there a particular reason that you needed to define ?
<uimaj-ee-version>0.7.0</uimaj-version>
<uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT</uimaj-re
lease-version>
I think you need to reconsider your project version. I think you want it
as 0.7.0-SNAPSHOT.
"incubating" would seem to belong as part of an artifactId or assembly
annotation (see the asembly plugin).
I hope this helps.
William
> -----Original Message-----
> From: Marshall Schor [mailto:[EMAIL PROTECTED]
> Sent: Friday, 11 January 2008 10:06 AM
> To: Maven Users List
> Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect?
> - Sender is forged (SPF Fail)
>
> William Ferguson wrote:
> > Marshall,
> >
> > the standard solution for what you are attempting would be to
> > install/deploy those libraries "not managed by Maven" into your own
> > repository or corporate repository and then you *would*
> have access to
> > them.
> >
> > William
> >
> Hi William -
>
> I must have not communicated well. All of the libraries are
> manged by Maven. The situation where the failure occurs is
> like a startup - when a user first checks out the set of
> projects (having child POMs) and the main parent POM, then
> tries to do a "mvn install" on the parent.
>
> (I'm assuming here that they check out a development level,
> where the components have not been installed to any repository, yet).
>
> This first "mvn install" is intended to install of the parts
> into the local repository, but it only works if you don't use
> ${ ... } variable substitution in the way I was trying to use it.
>
> My question is whether this limitation on use of variable
> substitution is a maven defect, or whether it is working as
> designed (in which case - I'd appreciate learning what the
> philosophy is behind this design choice).
>
> -Marshall
> >
> >> -----Original Message-----
> >> From: Marshall Schor [mailto:[EMAIL PROTECTED]
> >> Sent: Friday, 11 January 2008 9:40 AM
> >> To: Maven Users List
> >> Subject: [***POSSIBLE SPAM***] - possible maven defect? -
> Sender is
> >> forged (SPF Fail)
> >>
> >> We define shared values as <property> elements in a parent POM and
> >> use them in child POMs. We have fragments like this, near
> the top of
> >> the parent POM:
> >>
> >> . . .
> >> <properties>
> >> . . .
> >> <uimaj-ee-version>0.7.0</uimaj-version>
> >>
> >> <uimaj-ee-release-version>${uimaj-version}-incubating-SNAPSHOT
> >> </uimaj-release-version>
> >>
> >> . . .
> >> <version>0.7.0-incubating-SNAPSHOT</version>
> >>
> >> I noticed I might be able to replace the
> >>
> >> <version>0.7.0-incubating-SNAPSHOT</version>
> >>
> >> with
> >>
> >> <version>${uimaj-ee-release-version}</version>
> >>
> >> This only kind of worked. The way it would fail, would
> be if there
> >> were no existing versions of the parent POM in any
> repository, then
> >> the "mvn install" command for the parent POM would fail
> when scanning
> >> the child POMs, saying, for example:
> >>
> >> [ERROR] FATAL ERROR
> >> [INFO]
> >>
> >> --------------------------------------------------------------
> >> ----------
> >> [INFO] Error building POM (may not be this project's POM).
> >>
> >>
> >> Project ID:
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>
> >> Reason: Cannot find parent: org.apache.uima:uimaj-ee
> for project:
> >>
> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version} for
> >> project
> >> org.apache.uima:uimaj-ee-core:jar:${uimaj-ee-release-version}
> >>
> >> I found (as a workaround) that if I modified the parent
> POM to have
> >> no children (commenting out the <module> elements), then
> mvn install
> >> for the parent POM would run; furthermore, I could then
> uncomment out
> >> the <module> children and mvn install on the parent POM would now
> >> build the children OK (I guess because the parent POM was
> findable in
> >> the local repository).
> >>
> >> This problem doesn't seem to occur if the parent POM doesn't use
> >> substitutable property values for its own <version>
> number. In that
> >> case the parent POM need not be previously installed in the local
> >> repository.
> >>
> >> Is this expected behavior in Maven, or is this a defect?
> >>
> >> -Marshall
> >>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
