>From what you've said it seems that all your problems are solved by hardcoding the version in the parent. Ie don't use the property. Which is standard practice.
I don't know what causes the problem that you are describing, but if it goes away when you stop punishing yourself with it then that would be a good option IMHO. William > -----Original Message----- > From: Marshall Schor [mailto:[EMAIL PROTECTED] > Sent: Friday, 11 January 2008 12:42 PM > To: Maven Users List > Subject: [***POSSIBLE SPAM***] - Re: - possible maven defect? > - Sender is forged (SPF Fail) > > William Ferguson wrote: > > 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. > > > True, but that's not what we're doing, exactly. In our code, > the "reference to the parent POM" *is* *"hard-coded", and > doesn't contain any references such as > ${property-defined-in-parent} for the very reason you describe. > > You should really have groupId, artifactId and version > hard-coded in > > all POMs. > > > Well, that's the question. We have groupId and artifactId > hard-coded. > The version *is* inheriting from the parent, via a > ${property-defined-in-parent} (*this is working*). > What's not working is the parent itself being able to have a > ${property-defined-in-itself} value for the <version> value. > > 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- > > release-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. > > > Because we are a project in the Apache Incubator, our version > names include the word "incubator" in them to insure that > users realize they are working with an incubating project. > > The reason we define version numbers this way is that we have > some conflicting naming standards - some require > 0.7.0-incubating-SNAPSHOT, while others (Eclipse plugins, in > particular) want 0.7.0.incubating-SNAPSHOT (not the "." > instead of the '-' in front of the word "incubating". > > So we thought that we could put all this kind of stuff in one > common, factored out, "parent", and be done with it :-) > > -Marshall > > 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] > > > > > > > > > > > --------------------------------------------------------------------- > 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]
