William Ferguson wrote:
>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.
Hi William -
The only reason I was, as you say, "punishing myself" with this approach
was an attempt to follow the DRY philosophy (
http://en.wikipedia.org/wiki/Don't_repeat_yourself
<http://en.wikipedia.org/wiki/Don%27t_repeat_yourself> ), which has
served us well in the past in reducing maintenance difficulties. It's
possible that using maven's Release plugin would alleviate some of this,
and I'll look into that further. We do have version info in places I
don't think Maven would know about (such as in our documentation, and
inside the names of our Eclipse plugins - which use a slightly different
syntax than normal maven things.)
Thanks for your help and advice.
-Marshall
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
