Marshall Schor wrote:
Thank you for your reply.
I tried to look up what the command line parameter "-N" was for maven
- but couldn't find any reference to it. Can you please point me to
where the command line parameters for maven are defined so I can learn
what this does?
I found documentation for this by typing mvn -?. mvn -N install on the
parent would appear to install the parent to the local repo, without
executing the subgoals.
-Marshall
I'm a little confused on why parents are not to be installed. Did you
mean that parents shouldn't be installed using the "mvn install" command?
Thanks for your help. -Marshall
Michael McCallum wrote:
not a defect and IMO you should never install parents
you can just do an install on the parent with mvn -N
for my projects any user first gets a settings.xml and then can check
out and build any artifact in isotation without the need to mvn
install anything
relying on the parent to inherit version numbers etc gets pretty ugly
and error prone you would be best to encasulate dependencies like
that in a pom project
On Fri, 11 Jan 2008 13:05:37 Marshall Schor wrote:
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]