You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Los Morales <mo...@hotmail.com> on 2006/11/21 16:34:03 UTC
Maven cyclic dependecy issue
Hi,
Im a bit frustrated on how Maven cycles through its dependency. Currently
I have a project consisting of multiple sub projects2 levels deep. Heres
a hierarchy:
-->main
--> sub1
--> sub1sub1
--> sub1sub2
--> sub2
The main project has a POM looking like this:
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.project.main</groupId>
<artifactId>main</artifactId>
<version>1.0-SNAPSHOT</version>
<name>Main Project</name>
<url>http://maven.apache.org</url>
<packaging>pom</packaging>
<properties>
<main.version>1.0-SNAPSHOT</main.version>
</properties>
<modules>
<module>sub1</module>
<module>sub2</module>
</modules>
...
</project>
Now say my sub2 project looks like this:
<project>
<parent>
<artifactId>main</artifactId>
<groupId>com.project.main</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>com.project.main.core</groupId>
<artifactId>main-core-api</artifactId>
<name>Main Core API</name>
<version>${main.version}</version>
<packaging>jar</packaging>
</project>
Sub project 1 and its repective subprojects are similar. Now, from my root
project (main), I run any mvn command, I get the following error:
###################################
[INFO] Error building POM (may not be this project's POM).
Project ID: com.project.main.sub1.sub2:main-sub1-sub2:jar:${main.version}
Reason: Cannot find parent: com.project.main.sub1:main-sub1 for project:
com.project.main.sub1.sub2:main-sub1-sub2:jar:${main.version}
####################################
So I go to my sub2 project and run any mvn command, I get the same error.
Looks like its not able to figure out the runtime value of {main.version}.
Hence I can not continue with any build process. Any help would be
appreciated. Thanks in advance.
-los
_________________________________________________________________
Fixing up the home? Live Search can help
http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmemailtaglinenov06&FORM=WLMTAG
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/22/06, Christian Goetze <ch...@sensage.com> wrote:
> > In between propose and accept is when your QA department would do
> > their work... and if accepted, the exact artifacts they've tested will
> > be promoted to the release repository.
>
> This is I think where the problem is: if the "promotion" involves a
> rebuild,
...
Promotion does *not* involve a rebuild.
Like you, Apache projects need to examine (and vote) on the *exact*
artifacts that get released to the public. Maven's current release
process doesn't allow us to (easily) do this.
The new process (still under discussion as far as I know...) involves
proposing a release, examining it, and then either accepting it or
not.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
Posted by Christian Goetze <ch...@sensage.com>.
Wendy Smoak wrote:
> On 11/22/06, Christian Goetze <ch...@sensage.com> wrote:
>
>> In order to use the release plugin, I have to decide to go for it, and
>> call a particular source tree releasable. This may sound trivial, but it
>> isn't. How do I decide that?
>
>
> We've been struggling with the same issue inside Apache, where our
> policies require a vote on the actual artifacts that will be released.
>
> I haven't seen anything recently, but last month we had a discussion
> about changing the release process to include a "staging" or
> "proposal" phase.
>
> So it would be release:prepare, release:propose, then either
> release:accept or release:clean
>
> In between propose and accept is when your QA department would do
> their work... and if accepted, the exact artifacts they've tested will
> be promoted to the release repository.
This is I think where the problem is: if the "promotion" involves a
rebuild, especially one where the source code changes - even if it's
only the version string, then you have created uncertainty and devalued
the testing effort of QA. That's why I want every build to be done as if
it was a release, and only call something a release by granting access
to it.
This design principle is fundamental in the build system into which I'm
attempting to embed maven - hence my problem :)
>
> Here's the thread:
>
Thanks for the link. I'll read it....
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/22/06, Christian Goetze <ch...@sensage.com> wrote:
> In order to use the release plugin, I have to decide to go for it, and
> call a particular source tree releasable. This may sound trivial, but it
> isn't. How do I decide that?
We've been struggling with the same issue inside Apache, where our
policies require a vote on the actual artifacts that will be released.
I haven't seen anything recently, but last month we had a discussion
about changing the release process to include a "staging" or
"proposal" phase.
So it would be release:prepare, release:propose, then either
release:accept or release:clean
In between propose and accept is when your QA department would do
their work... and if accepted, the exact artifacts they've tested will
be promoted to the release repository.
Here's the thread:
http://www.nabble.com/Maven-and-the-Apache-processes...-t2430753s177.html#a6800959
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
Posted by Christian Goetze <ch...@sensage.com>.
> Maven does several things... one of which is building, but the other
> is to
> gently (OK, maybe not THAT gently) push users to adhere to standards.
> It is
> not by accident that non-standard behaviors are untenable. The
> standard in
> this situation you describe is to use the maven-release-plugin. I know, I
> know... doco sucks - we're working on it.
See below - I think the design of the release plugin is inadequate
>
> Before you think this this is an isolated weakness on the part of Maven,
> note that this kind of push is happening all over, and once you learn the
> standard you see how nice it is to be able to go to any project built
> with
> Maven and be able to use and navigate through it. This is a similar
> thought
> behind Ruby on Rails, and clones like Trax... convention over
> configuration.
I understand that - those are the reasons I chose maven to begin with.
In fact, for the past 9 years I've been developing build systems
designed on that exact premise, except that I haven't really pushed it
out onto people outside my organisation (see
http://www.cg-soft.com/tools/build/, even if it's somewhat dated by now,
I still use that system)
Nevertheless, it only works if the convention is useful and correct. If
the convention is flawed, then you need a way to fix it or work around
it. For now, I'm working around it by simply not using it. Someday, I
hope I can start using it, because the stuff I'm doing now isn't so hot.
> Users shouldn't HAVE to know that in your super-special build system,
> they
> have to type "mvn install -DmyVersion=1.0-alpha-1-SNAPSHOT" to use it.
There are ways around that particular issue (for example, placing that
-D into the wrapper script which invokes maven), but those are besides
the point.
Here is what I do not like about the process implied by the release
plugin. Perhaps I'm not understanding all aspects of it, and perhaps I'm
just smoking dope, but here's what I see:
In order to use the release plugin, I have to decide to go for it, and
call a particular source tree releasable. This may sound trivial, but it
isn't. How do I decide that?
Say I have a QA department, and they tell me: "looking good", so I
release. I go through the motions, but now I need to have faith that the
actual release build is going to be exactly equivalent to the builds QA
used to say "looking good". Trouble is: we're not a faith based
organization. I need to -prove- that it -is- the same - AND I need to
prove it not just to my satisfaction, but to the satisfaction of any
pointy-haired boss that feels the need for some hands-on auditing. That
is actually very hard to do in real life projects. The simple fact of
removing the -SNAPSHOT from version numbers may have all sorts of side
effects - if only by removing any hope of doing binary checksums of the
build products - something you can't really do anyway, since way too
many processes insert useless timestamp info all over the place.
The only way I know of doing this is to produce release candidates that
look exactly as if they were the actual release, and keep building new
ones until QA says it's good. They then use that exact build.
Essentially, manage releases by access control, not by naming.
So I guess the solution is to continually run the release plugin to
generate various new versions with new build numbers, feeding a constant
stream of release candidates to QA. And that's where I hit the second
snag, which may be easy to fix, but it isn't clear at all from the
documentation. The release plugin needs to work non-interactively -
otherwise I'd be sitting there doing nothing else but maven builds.
The third snag is that I need to have a way to explain it how to use
perforce, and in a way that matches the way we are using perforce in
this shop. I guess I can live with the constant automatic checkouts and
checkins of pom.xml files, but I'm not sure how this affects developers...
Finally, I need to integrate maven into a larger system - until the day
comes when maven knows -everything- about -everything-, simply working
on the premise that maven is the ultimate controller is not helpful.
--
cg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven cyclic dependecy issue
Posted by Christian Goetze <ch...@sensage.com>.
Wendy Smoak wrote:
> On 11/22/06, Christian Goetze <ch...@sensage.com> wrote:
>
>> The main point here is that one would like to have -exactly- -one- place
>> where version numbers are defined and changed. Forcing people to
>> manually edit dozens of pom.xml files every time the version number
>> changes is just bad design.
>
>
> The intent is for you to use the release plugin, and for Maven to
> update these version numbers during the release process.
>
> http://maven.apache.org/plugins/maven-release-plugin/introduction.html
>
Trouble with that is that it assumes that our release process maps to
the assumptions made in the plugin. I actually don't have too much of a
beef with it, but it does not address some of the issues that arise in
the non-java world, and it requires that you keep state externally.
I guess my one line criticism is that the release plugin assumes you
know ahead of time that you are going to release this exact upcoming build.
Granted, I'm still a maven newbie and I accept the fact that I may
understand all of the design decisions - so be patient with me please :)
--
cg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven cyclic dependecy issue
Posted by Wendy Smoak <ws...@gmail.com>.
On 11/22/06, Christian Goetze <ch...@sensage.com> wrote:
> The main point here is that one would like to have -exactly- -one- place
> where version numbers are defined and changed. Forcing people to
> manually edit dozens of pom.xml files every time the version number
> changes is just bad design.
The intent is for you to use the release plugin, and for Maven to
update these version numbers during the release process.
http://maven.apache.org/plugins/maven-release-plugin/introduction.html
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven cyclic dependecy issue
Posted by Eric Redmond <er...@gmail.com>.
On 11/22/06, Christian Goetze <ch...@sensage.com> wrote:
>
>
> >>
> >> It could be told by setting -Dmy_version=<version> and using
> >> ${my_version} in the parent reference. But not even that works.
> >
> >
> >
> > You're missing the point. A child pom MUST be able to know what
> > version its
> > parent is BEFORE it can inherit anything. Wayne is right... it's
> > strickly a
> > chicken-and-egg problem. Its a very bad design to create a project that
> > requires a parameter from the command-line to decifer its actualy
> > coordinates... you'd have to type in the version EVERY TIME you used
> > it. So
> > rather than:
> >
> > mvn install
> >
> > You users must enter:
> >
> > mvn install -DmyVersion=1.0-alpha-1-SNAPSHOT
> >
> > You're not really gaining anything here.
>
> Yes you are, because you can modify what "mvn" is and add it to the
> wrapper script. You can then use whatever method pleases you to
> determine the current version number.
>
> The main point here is that one would like to have -exactly- -one- place
> where version numbers are defined and changed. Forcing people to
> manually edit dozens of pom.xml files every time the version number
> changes is just bad design.
Maven does several things... one of which is building, but the other is to
gently (OK, maybe not THAT gently) push users to adhere to standards. It is
not by accident that non-standard behaviors are untenable. The standard in
this situation you describe is to use the maven-release-plugin. I know, I
know... doco sucks - we're working on it.
Before you think this this is an isolated weakness on the part of Maven,
note that this kind of push is happening all over, and once you learn the
standard you see how nice it is to be able to go to any project built with
Maven and be able to use and navigate through it. This is a similar thought
behind Ruby on Rails, and clones like Trax... convention over configuration.
Users shouldn't HAVE to know that in your super-special build system, they
have to type "mvn install -DmyVersion=1.0-alpha-1-SNAPSHOT" to use it.
Eric
--
> cg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Eric Redmond
http://codehaus.org/~eredmond
Re: Maven cyclic dependecy issue
Posted by Christian Goetze <ch...@sensage.com>.
>>
>> It could be told by setting -Dmy_version=<version> and using
>> ${my_version} in the parent reference. But not even that works.
>
>
>
> You're missing the point. A child pom MUST be able to know what
> version its
> parent is BEFORE it can inherit anything. Wayne is right... it's
> strickly a
> chicken-and-egg problem. Its a very bad design to create a project that
> requires a parameter from the command-line to decifer its actualy
> coordinates... you'd have to type in the version EVERY TIME you used
> it. So
> rather than:
>
> mvn install
>
> You users must enter:
>
> mvn install -DmyVersion=1.0-alpha-1-SNAPSHOT
>
> You're not really gaining anything here.
Yes you are, because you can modify what "mvn" is and add it to the
wrapper script. You can then use whatever method pleases you to
determine the current version number.
The main point here is that one would like to have -exactly- -one- place
where version numbers are defined and changed. Forcing people to
manually edit dozens of pom.xml files every time the version number
changes is just bad design.
--
cg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven cyclic dependecy issue
Posted by Eric Redmond <er...@gmail.com>.
On 11/21/06, Christian Goetze <ch...@sensage.com> wrote:
>
> Wayne Fay wrote:
>
> > Its a chicken and egg problem.
> >
> > If you don't hard-code parent version in child = which parent version
> > should I use? Keep in mind the /parent/module layout in the filesystem
> > (with relativePath) is not an absolute requirement ie parent poms
> > could/should be checked into a Maven repo and resolved from there. The
> > fact that ../pom.xml "usually" works to find the parent is just an
> > enhancement to the functionality.
> >
> > So assuming I have 3 parent pom versions in my Maven repo, how does
> > Maven know which one is "right" without being told?
> >
> It could be told by setting -Dmy_version=<version> and using
> ${my_version} in the parent reference. But not even that works.
You're missing the point. A child pom MUST be able to know what version its
parent is BEFORE it can inherit anything. Wayne is right... it's strickly a
chicken-and-egg problem. Its a very bad design to create a project that
requires a parameter from the command-line to decifer its actualy
coordinates... you'd have to type in the version EVERY TIME you used it. So
rather than:
mvn install
You users must enter:
mvn install -DmyVersion=1.0-alpha-1-SNAPSHOT
You're not really gaining anything here.
Eric
--
> cg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Eric Redmond
http://codehaus.org/~eredmond <http://codehaus.org/%7Eeredmond>
Re: Maven cyclic dependecy issue
Posted by Christian Goetze <ch...@sensage.com>.
Wayne Fay wrote:
> Its a chicken and egg problem.
>
> If you don't hard-code parent version in child = which parent version
> should I use? Keep in mind the /parent/module layout in the filesystem
> (with relativePath) is not an absolute requirement ie parent poms
> could/should be checked into a Maven repo and resolved from there. The
> fact that ../pom.xml "usually" works to find the parent is just an
> enhancement to the functionality.
>
> So assuming I have 3 parent pom versions in my Maven repo, how does
> Maven know which one is "right" without being told?
>
It could be told by setting -Dmy_version=<version> and using
${my_version} in the parent reference. But not even that works.
--
cg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven cyclic dependecy issue
Posted by Wayne Fay <wa...@gmail.com>.
Its a chicken and egg problem.
If you don't hard-code parent version in child = which parent version
should I use? Keep in mind the /parent/module layout in the filesystem
(with relativePath) is not an absolute requirement ie parent poms
could/should be checked into a Maven repo and resolved from there. The
fact that ../pom.xml "usually" works to find the parent is just an
enhancement to the functionality.
So assuming I have 3 parent pom versions in my Maven repo, how does
Maven know which one is "right" without being told?
Wayne
On 11/21/06, Los Morales <mo...@hotmail.com> wrote:
> Christian Goetze wrote:
>
> >The trouble is that you need a -reference- to the parent's version in the
> >children, and that reference does not seem to resolve any ${...}
> >substitutions, so it needs to be hard coded.
>
> Hmm... Was this the intended design or could this be fixed up in later
> revisions? Just seems that defining a top-level property should be
> viewable/overriden by every child pom and hence conforming to the
> *inheritance* contract touted by Maven.
>
> -los
>
> _________________________________________________________________
> Get the latest Windows Live Messenger 8.1 Beta version.Join now.
> http://ideas.live.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven cyclic dependecy issue
Posted by Los Morales <mo...@hotmail.com>.
Christian Goetze wrote:
>The trouble is that you need a -reference- to the parent's version in the
>children, and that reference does not seem to resolve any ${...}
>substitutions, so it needs to be hard coded.
Hmm... Was this the intended design or could this be fixed up in later
revisions? Just seems that defining a top-level property should be
viewable/overriden by every child pom and hence conforming to the
*inheritance* contract touted by Maven.
-los
_________________________________________________________________
Get the latest Windows Live Messenger 8.1 Beta version. Join now.
http://ideas.live.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven cyclic dependecy issue
Posted by Christian Goetze <ch...@sensage.com>.
Eric Redmond wrote:
> I see what you are trying to do... but why? If you do not define a child
> project's version, it automatically inherits from its parent. Just take
> <version>${main.version}</version> out.
The trouble is that you need a -reference- to the parent's version in
the children, and that reference does not seem to resolve any ${...}
substitutions, so it needs to be hard coded. In other words, you get to
query/replace all of your project's pom.xml files whenever you bump the
version number.
--
cg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven cyclic dependecy issue
Posted by Los Morales <mo...@hotmail.com>.
Thanks for the reply.
Well... My most (if not all) of my subprojects will be on the same version.
Since I currently have about a dozen sub projects (and there will be more),
I hate to go into each sub project and change the version number in the POM.
I would rather change it in one place and have it reflected across all sub
projects. That's what I thought inheritance of POM's provided. If these
sub poms can't inherit the attribute of the super pom's version number, what
kind of inheritance is this? Is there another way of doing what I described
that works?
-los
>From: "Eric Redmond" <er...@gmail.com>
>Reply-To: "Maven Users List" <us...@maven.apache.org>
>To: "Maven Users List" <us...@maven.apache.org>
>Subject: Re: Maven cyclic dependecy issue
>Date: Tue, 21 Nov 2006 11:19:02 -0500
>
>I see what you are trying to do... but why? If you do not define a child
>project's version, it automatically inherits from its parent. Just take
><version>${main.version}</version> out.
>
>On 11/21/06, Los Morales <mo...@hotmail.com> wrote:
>>
>>Hi,
>>
>>I'm a bit frustrated on how Maven cycles through its
>>dependency. Currently
>>I have a project consisting of multiple sub projects2 levels
>>deep. Here's
>>a hierarchy:
>>
>>-->main
>> --> sub1
>> --> sub1sub1
>> --> sub1sub2
>> --> sub2
>>
>>The main project has a POM looking like this:
>>
>><project xmlns="http://maven.apache.org/POM/4.0.0"
>>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>>http://maven.apache.org/maven-v4_0_0.xsd">
>> <modelVersion>4.0.0</modelVersion>
>> <groupId>com.project.main</groupId>
>> <artifactId>main</artifactId>
>> <version>1.0-SNAPSHOT</version>
>> <name>Main Project</name>
>> <url>http://maven.apache.org</url>
>> <packaging>pom</packaging>
>> <properties>
>> <main.version>1.0-SNAPSHOT</main.version>
>> </properties>
>> <modules>
>> <module>sub1</module>
>> <module>sub2</module>
>> </modules>
>>...
>></project>
>>
>>
>>Now say my sub2 project looks like this:
>>
>><project>
>> <parent>
>> <artifactId>main</artifactId>
>> <groupId>com.project.main</groupId>
>> <version>1.0-SNAPSHOT</version>
>> </parent>
>> <modelVersion>4.0.0</modelVersion>
>> <groupId>com.project.main.core</groupId>
>> <artifactId>main-core-api</artifactId>
>> <name>Main Core API</name>
>> <version>${main.version}</version>
>> <packaging>jar</packaging>
>></project>
>>
>>Sub project 1 and its repective subprojects are similar. Now, from my
>>root
>>project (main), I run any mvn command, I get the following error:
>>
>>###################################
>>[INFO] Error building POM (may not be this project's POM).
>>
>>Project ID: com.project.main.sub1.sub2:main-sub1-sub2:jar:${main.version}
>>
>>Reason: Cannot find parent: com.project.main.sub1:main-sub1 for project:
>>com.project.main.sub1.sub2:main-sub1-sub2:jar:${main.version}
>>####################################
>>
>>
>>So I go to my sub2 project and run any mvn command, I get the same error.
>>Looks like its not able to figure out the runtime value of {main.version}.
>>Hence I can not continue with any build process. Any help would be
>>appreciated. Thanks in advance.
>>
>>-los
>>
>>_________________________________________________________________
>>Fixing up the home? Live Search can help
>>
>>http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmemailtaglinenov06&FORM=WLMTAG
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
>--
>Eric Redmond
>http://codehaus.org/~eredmond
_________________________________________________________________
Get FREE company branded e-mail accounts and business Web site from
Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven cyclic dependecy issue
Posted by Eric Redmond <er...@gmail.com>.
I see what you are trying to do... but why? If you do not define a child
project's version, it automatically inherits from its parent. Just take
<version>${main.version}</version> out.
On 11/21/06, Los Morales <mo...@hotmail.com> wrote:
>
> Hi,
>
> I'm a bit frustrated on how Maven cycles through its
> dependency. Currently
> I have a project consisting of multiple sub projects—2 levels
> deep. Here's
> a hierarchy:
>
> -->main
> --> sub1
> --> sub1sub1
> --> sub1sub2
> --> sub2
>
> The main project has a POM looking like this:
>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.project.main</groupId>
> <artifactId>main</artifactId>
> <version>1.0-SNAPSHOT</version>
> <name>Main Project</name>
> <url>http://maven.apache.org</url>
> <packaging>pom</packaging>
> <properties>
> <main.version>1.0-SNAPSHOT</main.version>
> </properties>
> <modules>
> <module>sub1</module>
> <module>sub2</module>
> </modules>
> ...
> </project>
>
>
> Now say my sub2 project looks like this:
>
> <project>
> <parent>
> <artifactId>main</artifactId>
> <groupId>com.project.main</groupId>
> <version>1.0-SNAPSHOT</version>
> </parent>
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.project.main.core</groupId>
> <artifactId>main-core-api</artifactId>
> <name>Main Core API</name>
> <version>${main.version}</version>
> <packaging>jar</packaging>
> </project>
>
> Sub project 1 and its repective subprojects are similar. Now, from my
> root
> project (main), I run any mvn command, I get the following error:
>
> ###################################
> [INFO] Error building POM (may not be this project's POM).
>
> Project ID: com.project.main.sub1.sub2:main-sub1-sub2:jar:${main.version}
>
> Reason: Cannot find parent: com.project.main.sub1:main-sub1 for project:
> com.project.main.sub1.sub2:main-sub1-sub2:jar:${main.version}
> ####################################
>
>
> So I go to my sub2 project and run any mvn command, I get the same error.
> Looks like its not able to figure out the runtime value of {main.version}.
> Hence I can not continue with any build process. Any help would be
> appreciated. Thanks in advance.
>
> -los
>
> _________________________________________________________________
> Fixing up the home? Live Search can help
>
> http://imagine-windowslive.com/search/kits/default.aspx?kit=improve&locale=en-US&source=hmemailtaglinenov06&FORM=WLMTAG
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Eric Redmond
http://codehaus.org/~eredmond