Re: Maven cyclic dependecy issue
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
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 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Eric Redmond
http://codehaus.org/~eredmond
Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design Issue with the release plugin (was Re: Maven cyclic dependecy issue)
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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;
modelVersion4.0.0/modelVersion
groupIdcom.project.main/groupId
artifactIdmain/artifactId
version1.0-SNAPSHOT/version
nameMain Project/name
urlhttp://maven.apache.org/url
packagingpom/packaging
properties
main.version1.0-SNAPSHOT/main.version
/properties
modules
modulesub1/module
modulesub2/module
/modules
...
/project
Now say my sub2 project looks like this:
project
parent
artifactIdmain/artifactId
groupIdcom.project.main/groupId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
groupIdcom.project.main.core/groupId
artifactIdmain-core-api/artifactId
nameMain Core API/name
version${main.version}/version
packagingjar/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=improvelocale=en-USsource=hmemailtaglinenov06FORM=WLMTAG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
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
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;
modelVersion4.0.0/modelVersion
groupIdcom.project.main/groupId
artifactIdmain/artifactId
version1.0-SNAPSHOT/version
nameMain Project/name
urlhttp://maven.apache.org/url
packagingpom/packaging
properties
main.version1.0-SNAPSHOT/main.version
/properties
modules
modulesub1/module
modulesub2/module
/modules
...
/project
Now say my sub2 project looks like this:
project
parent
artifactIdmain/artifactId
groupIdcom.project.main/groupId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
groupIdcom.project.main.core/groupId
artifactIdmain-core-api/artifactId
nameMain Core API/name
version${main.version}/version
packagingjar/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=improvelocale=en-USsource=hmemailtaglinenov06FORM=WLMTAG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Eric Redmond
http://codehaus.org/~eredmond
Re: Maven cyclic dependecy issue
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 [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, 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
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;
modelVersion4.0.0/modelVersion
groupIdcom.project.main/groupId
artifactIdmain/artifactId
version1.0-SNAPSHOT/version
nameMain Project/name
urlhttp://maven.apache.org/url
packagingpom/packaging
properties
main.version1.0-SNAPSHOT/main.version
/properties
modules
modulesub1/module
modulesub2/module
/modules
...
/project
Now say my sub2 project looks like this:
project
parent
artifactIdmain/artifactId
groupIdcom.project.main/groupId
version1.0-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
groupIdcom.project.main.core/groupId
artifactIdmain-core-api/artifactId
nameMain Core API/name
version${main.version}/version
packagingjar/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=improvelocale=en-USsource=hmemailtaglinenov06FORM=WLMTAG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven cyclic dependecy issue
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 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Eric Redmond
http://codehaus.org/~eredmond http://codehaus.org/%7Eeredmond
