Re: Maven cyclic dependecy issue

2006-11-22 Thread Christian Goetze
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

Re: Maven cyclic dependecy issue

2006-11-22 Thread Wendy Smoak
On 11/22/06, Christian Goetze [EMAIL PROTECTED] 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

Re: Maven cyclic dependecy issue

2006-11-22 Thread Christian Goetze
Wendy Smoak wrote: On 11/22/06, Christian Goetze [EMAIL PROTECTED] 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

Re: Maven cyclic dependecy issue

2006-11-22 Thread Eric Redmond
On 11/22/06, Christian Goetze [EMAIL PROTECTED] 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

Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)

2006-11-22 Thread Christian Goetze
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

Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)

2006-11-22 Thread Wendy Smoak
On 11/22/06, Christian Goetze [EMAIL PROTECTED] 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

Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)

2006-11-22 Thread Christian Goetze
Wendy Smoak wrote: On 11/22/06, Christian Goetze [EMAIL PROTECTED] 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

Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)

2006-11-22 Thread Wendy Smoak
On 11/22/06, Christian Goetze [EMAIL PROTECTED] 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

Re: Maven cyclic dependecy issue

2006-11-21 Thread Los Morales
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?

Re: Maven cyclic dependecy issue

2006-11-21 Thread Wayne Fay
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

Re: Maven cyclic dependecy issue

2006-11-21 Thread Christian Goetze
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

Maven cyclic dependecy issue

2006-11-21 Thread Los Morales
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

Re: Maven cyclic dependecy issue

2006-11-21 Thread Christian Goetze
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

Re: Maven cyclic dependecy issue

2006-11-21 Thread Eric Redmond
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 [EMAIL PROTECTED] wrote: Hi, I'm a bit frustrated on how Maven cycles through its

Re: Maven cyclic dependecy issue

2006-11-21 Thread Los Morales
Redmond [EMAIL PROTECTED] Reply-To: Maven Users List users@maven.apache.org To: Maven Users List users@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

Re: Maven cyclic dependecy issue

2006-11-21 Thread Eric Redmond
On 11/21/06, Christian Goetze [EMAIL PROTECTED] 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