You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2010/03/10 12:52:38 UTC
Re: Maven 3.0 Artefact/Dependency version discussion request
The user list is here users@maven.apache.org and you can subscribe to discuss your issues using users-subscribe@maven.apache.org.
On Mar 10, 2010, at 5:45 AM, Trojan, Krzysztof wrote:
> Dear Sir,
>
> First of all I would like to apologize for writing to you directly. I have inadequate information about roles and responsibilities in the Maven project, so I write to You, as Maven PMC member and project founder, hoping you can distribute my email to the right people.
>
> I have been among Maven users for some time now. I am responsible for moving a really big banking solution build to Maven, that we hoped to solve a number of manageability problems we have had in the past. We have found Maven to suit our needs very well, but we are sometimes struggling with Maven ever changing behaviour and APIs. Having said that, Maven still is our tool of choice.
>
> However, we have found that Maven 3.0 is moving in a direction that we find a little bit dangerous for us. We have some arguments against proposed changes, and we kindly ask to open a discussion. In very short words, Maven 3.0 tries to restrict usage of expressions evaluated during build in some parts of the pom.xml (or a project descriptor, more generically speaking). We can see the warning saying something like “using an expression here is a BAD BAD thing, it will threaten stability of your build. We may stop supporting this one day”. While we can agree that build stability may be impacted, in the end it is MY (the developer) responsibility to avoid it. Build stability may be impacted by 10 other things you have no control over.
>
> Here is an extract:
> [WARNING] Some problems were encountered while building the effective model for com.fnis.crb:BigBankingProject:jar:${BigBankingProject.module.version}
> [WARNING] 'version' contains an expression but should be a constant. @ com.fnis.crb:BigBankingProject:${BigBankingProject.module.version}, C:\Workspaces\Corebank_Maven\BigBankingProject\pom.xml
>
> A little bit further down in the log there is
> [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
> [WARNING]
>
> If you want to warn me – fine, thank you, I have been warned. If you have the behaviour configurable (like being able to switch on some “relaxed” mode) – fine. But if the tool says: “you are stupid, but we have a cure, we will prevent you from doing those dangerous things …” it is a complete misunderstanding. The flexibility is ALWAYS a good thing, and the fact that there will be people who can screw things up badly just because they can, cannot be the justification to remove flexibility in favour of some “ONLY GOOD WAY”. And expressions are one of the ways of providing flexibility.
>
> I am unsure if the restriction the warning mention ('version' contains an expression but should be a constant) is only for the main artefact defined in pom.xml, or also applies to dependencies (can I have an expression in dependency version ? I know from the discussions documented in the Internet you were concerned with having a version not resolved to a concrete value – you also mentioned version ranges as potential threat).
>
> If you want to hear the exact use case, I can elaborate it, but it is way too complicated for an initial email.
>
> The main idea behind our solution is that we inject properties into the build specifying the versions of dependencies we want to use. Imagine modules A, B and C; A depends on B, and B depends on C. Now we have a feature branch that changes A and C … my way is to use A and C from branch, but B from trunk. I want to build A, it references B from trunk … but as B references C, I need a way to tell B to use C built from branch – here is where expression in the <version> is used, B knows to depend on C in “some version” (${C.module.version}), the actual value of ${C.module.version} is injected, so it gets resolved to correct version in the repository. I hope I have made it clear enough … There are several similar use cases possible, but only if such “deferred dependency binding” is possible. I kindly request not to forbid it, or at least add some switch that enables this.
>
> Maybe some special switch to Maven ? Or a property that is treated specially, like –Zmy.versionprop=XXX instead of –Dmy.version.property=XXX. If I use –Z (just an example, may be anything you want), just assume I know what I am doing, if it is found in the version … let it be. Of course this is all oversimplification, we would need to find a workable solution for embedded Maven, and to define this properties in profiles … but I hope you get the general idea.
>
> I just would like to open a discussion, that I hope will influence the direction Maven is going to.
>
> Kind regards,
> Krzysztof Trojan
> Senior Application Technician
> FIS Technology Services (Poland)
> Al. Jerozolimskie 81, 02-001 Warsaw, Poland
> krzysztof.trojan@fnis.com
> Tel: +48 601 98 96 96
> Fax: +48 22 695 05 51
> www.fisglobal.com
> <image001.jpg>
> This e-mail contains privileged and confidential information intended for the use of the addressees named above. If you are not the intended recipient of this e-mail, you are hereby notified that you must not disseminate it, copy it or take any action in respect of any information contained in it. If you have received this e-mail in error please notify the sender immediately by e-mail and destroy this e-mail and its attachments
>
>
> _____________
>
> The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
> _____________
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 28/03/2011 4:30 AM, bryan.dollery wrote:
> Hi Ron,
>
> Maven isn't meant to be enforcing convention. It's meant to work without
> configuration /if/ convention fits in your particular domain. Where
> convention doesn't fit it's meant to be configurable.
To a certain extent that is true but as you can see in the forum, there
are limits
> As for best practice... Using maven for version management is /not/ best
> practice. It's a convention that maven has introduced and which doesn't
> really work very well. The ability to configure things in this area is
> critical to maven's success.
>
Again, you can disagree with Maven's functionality and philosophy but it
is very successful as it is.
> Final point: ant is not a substitute for maven. They are completely
> different things used for different purposes should not be directly
> compared. One is not substitutable for the other. Ant is a build system --
> maven is much more than that.
>
Some people want to do things in a very particular way. Ant is a very
flexible system and can do anything that you want.
Maven is a very powerful tool that supports a particular way of doing
things.
Ron
> Bryan
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Re-Maven-3-0-Artefact-Dependency-version-discussion-request-tp83857p4267200.html
> Sent from the Maven - Users mailing list archive at Nabble.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 3.0 Artefact/Dependency version discussion request
Posted by "bryan.dollery" <br...@bt.com>.
Hi Ron,
Maven isn't meant to be enforcing convention. It's meant to work without
configuration /if/ convention fits in your particular domain. Where
convention doesn't fit it's meant to be configurable.
As for best practice... Using maven for version management is /not/ best
practice. It's a convention that maven has introduced and which doesn't
really work very well. The ability to configure things in this area is
critical to maven's success.
Final point: ant is not a substitute for maven. They are completely
different things used for different purposes should not be directly
compared. One is not substitutable for the other. Ant is a build system --
maven is much more than that.
Bryan
--
View this message in context: http://maven.40175.n5.nabble.com/Re-Maven-3-0-Artefact-Dependency-version-discussion-request-tp83857p4267200.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 26/03/2011 8:21 AM, bryan.dollery wrote:
> Hi,
>
> I am also getting grief from maven for using variables in my version fields.
> For me, this is unavoidable. Let me explain...
>
> In my parent pom I have:
>
> ${productVersion}
>
> And in my properties I have:
>
> 0-SNAPSHOT
> 13.0.${productRevision}
>
> On a developer's machine, this produces a version number of
>
> 13.0.0-SNAPSHOT
>
> Which is exactly what I want.
>
> However, in my hudson CI server, as part of the maven command I have:
>
> -DivpnRevision=$SVN_REVISION-nt3
>
> The $SVN_REVISION variable is provided by hudson. It contains the svn
> revision number that has just been built, and the '-nt3' bit is the
> environment it was built for.
>
> I do this because subversion is my revision control system and it, rightly,
> controls the revision number (the clue as to it's purpose is in it's name).
> This is not a job I want to hand off to maven, for many reasons.
>
> If I use maven 3 for my builds, then my IDEs (both eclipse and intellij) are
> totally messed up -- maven 3 messes up the classpath because it can't deal
> with the variables. So, I'm stuck on maven 2.
>
> Now, I don't see this as providing the slightest obstacle to my ability to
> get repeatable builds. Rather, it's the opposite -- if I want to repeat a
> build all I have to know is the subversion revision number of the build I
> want and I can check out that revision and rebuild to recreate an exact copy
> of the original.
>
> Just because maven thinks that an alternative approach is 'convention'
> doesn't mean that I shouldn't be able to achieve this. CoC is supposed to
> allow one the choice of following convention, but provide the ability to use
> configuration where the convention does not fit one's requirements.
>
> So, what to do?
>
If you don't want to follow the conventions that Maven enforces, you are
better off with Ant.
Fighting the Maven way and not following "Best Practices" just leads to
frustration and a lot of long discussions with the same conclusion.
Maven is a powerful tool but it implements a very definite philosophical
approach to building software.
Ron
> Bryan
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Re-Maven-3-0-Artefact-Dependency-version-discussion-request-tp83857p4265445.html
> Sent from the Maven - Users mailing list archive at Nabble.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 3.0 Artefact/Dependency version discussion request
Posted by Anders Hammar <an...@hammar.net>.
/Anders (mobile)
Den 2 jun 2011 00.23 skrev "Russ Tremain" <ru...@releasetools.org>:
> At 9:26 PM +0200 5/29/11, Arnaud Héritier wrote:
>>For now it is just impossible to use properties in GAV for various
technical
>>and also philosophical reasons.
>
>
> I still don't see why the maven deployment plugin cannot be responsible
for hardening artifact properties inside deployed poms.
> The help plugin goal help:effective-pom does this for example.
>
> This would effectively synchronize the external location of the artifact
with the contents of the artifact's pom.
>
> /r
>
>
>>You may not be agree with the philosophy behind this choice but it is sure
>>that for now it is more secure in Maven to avoid this usage as it creates
>>many issues.
>>
>>About the philosophy even if I can be agree that having in the project
>>version the one of the SCM may be useful it is with really few SCMs.
>>For exemple with CVS it is impossible as each file has a different
version.
>>And For a DSCM like Git & co your version will be a hash and thus you
won't
>>be able to sort them.
>>
>>Arnaud
>>
>>
>>On Thu, May 26, 2011 at 5:24 PM, Manfred Moser <ma...@mosabuam.com>
wrote:
>>
>>> Why dont you use the buildnumber plugin? That might be able to do it for
>>> you..
>>>
>>> http://mojo.codehaus.org/buildnumber-maven-plugin/
>>>
>>> > For what it's worth, I agree with you both (version strings should be
>>> > controlled via the -ahem- version control system), but I am willing to
>>> > allow Maven (more to the point, the maven-release-plugin) to take care
>>> > of the version strings for me.
>>> >
>>> > However, if you don't want to, you can still do it yourself with Maven
>>> > 3 ... but you *can't* do it with properties at the command-line; you
>>> > *will* need to update the poms. Just do it outside of maven before
>>> > you perform the final build - should not be hard. If doing that is
>>> > too much to ask ... then, yeah, Maven may not be the right framework
>>> > for you. But consider that you will need to do *something* similar --
>>> > either you write your own around maven, or you write your own around
>>> > some other system.
>>> >
>>> > On Tue, May 17, 2011 at 11:12 AM, Russ Tremain <russt@releasetools.org
>
>>> > wrote:
>>> >> +1.
>>> >>
>>> >> this is the major reason I won't be upgrading to maven 3.
>>> >>
>>> >> I do think that versions should be fixed at maven deploy time - i.e.,
>>> >> when artifacts are deployed to the repository.
>>> >>
>>> >> -Russ
>>> >>
>>> >> At 5:21 AM -0700 3/26/11, bryan.dollery wrote:
>>> >>>Hi,
>>> >>>
>>> >>>I am also getting grief from maven for using variables in my version
>>> >>> fields.
>>> >>>For me, this is unavoidable. Let me explain...
>>> >>>
>>> >>>In my parent pom I have:
>>> >>>
>>> >>>${productVersion}
>>> >>>
>>> >>>And in my properties I have:
>>> >>>
>>> >>> 0-SNAPSHOT
>>> >>> 13.0.${productRevision}
>>> >>>
>>> >>>On a developer's machine, this produces a version number of
>>> >>>
>>> >>> 13.0.0-SNAPSHOT
>>> >>>
>>> >>>Which is exactly what I want.
>>> >>>
>>> >>>However, in my hudson CI server, as part of the maven command I have:
>>> >>>
>>> >>> -DivpnRevision=$SVN_REVISION-nt3
>>> >>>
>>> >>>The $SVN_REVISION variable is provided by hudson. It contains the svn
>>> >>>revision number that has just been built, and the '-nt3' bit is the
>>> >>>environment it was built for.
>>> >>>
>>> >>>I do this because subversion is my revision control system and it,
>>> >>> rightly,
>>> >>>controls the revision number (the clue as to it's purpose is in it's
>>> >>> name).
>>> >>>This is not a job I want to hand off to maven, for many reasons.
>>> >>>
>>> >>>If I use maven 3 for my builds, then my IDEs (both eclipse and
intellij)
>>> >>> are
>>> >>>totally messed up -- maven 3 messes up the classpath because it can't
>>> >>> deal
>>> >>>with the variables. So, I'm stuck on maven 2.
>>> >>>
>>> >>>Now, I don't see this as providing the slightest obstacle to my
ability
>>> >>> to
>>> >>>get repeatable builds. Rather, it's the opposite -- if I want to
repeat
>>> >>> a
>> > >>>build all I have to know is the subversion revision number of the
build
>>> >>> I
>>> >>>want and I can check out that revision and rebuild to recreate an
exact
>>> >>> copy
>>> >>>of the original.
>>> >>>
>>> >>>Just because maven thinks that an alternative approach is
'convention'
>>> >>>doesn't mean that I shouldn't be able to achieve this. CoC is
supposed
>>> >>> to
>>> >>>allow one the choice of following convention, but provide the ability
to
>>> >>> use
>>> >>>configuration where the convention does not fit one's requirements.
>>> >>>
>>> >>>So, what to do?
>>> >>>
>>> >>>Bryan
>>> >
>>> > ---------------------------------------------------------------------
>>> > 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
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Anders Hammar <an...@hammar.net>.
This has been discussed for the release plugin. The thing is, someone has to
implement it. Maybe this "someone" is you?
Btw, sorry for the previous empty mail. I blame my phone...
/Anders (mobile)
Den 2 jun 2011 00.23 skrev "Russ Tremain" <ru...@releasetools.org>:
> At 9:26 PM +0200 5/29/11, Arnaud Héritier wrote:
>>For now it is just impossible to use properties in GAV for various
technical
>>and also philosophical reasons.
>
>
> I still don't see why the maven deployment plugin cannot be responsible
for hardening artifact properties inside deployed poms.
> The help plugin goal help:effective-pom does this for example.
>
> This would effectively synchronize the external location of the artifact
with the contents of the artifact's pom.
>
> /r
>
>
>>You may not be agree with the philosophy behind this choice but it is sure
>>that for now it is more secure in Maven to avoid this usage as it creates
>>many issues.
>>
>>About the philosophy even if I can be agree that having in the project
>>version the one of the SCM may be useful it is with really few SCMs.
>>For exemple with CVS it is impossible as each file has a different
version.
>>And For a DSCM like Git & co your version will be a hash and thus you
won't
>>be able to sort them.
>>
>>Arnaud
>>
>>
>>On Thu, May 26, 2011 at 5:24 PM, Manfred Moser <ma...@mosabuam.com>
wrote:
>>
>>> Why dont you use the buildnumber plugin? That might be able to do it for
>>> you..
>>>
>>> http://mojo.codehaus.org/buildnumber-maven-plugin/
>>>
>>> > For what it's worth, I agree with you both (version strings should be
>>> > controlled via the -ahem- version control system), but I am willing to
>>> > allow Maven (more to the point, the maven-release-plugin) to take care
>>> > of the version strings for me.
>>> >
>>> > However, if you don't want to, you can still do it yourself with Maven
>>> > 3 ... but you *can't* do it with properties at the command-line; you
>>> > *will* need to update the poms. Just do it outside of maven before
>>> > you perform the final build - should not be hard. If doing that is
>>> > too much to ask ... then, yeah, Maven may not be the right framework
>>> > for you. But consider that you will need to do *something* similar --
>>> > either you write your own around maven, or you write your own around
>>> > some other system.
>>> >
>>> > On Tue, May 17, 2011 at 11:12 AM, Russ Tremain <russt@releasetools.org
>
>>> > wrote:
>>> >> +1.
>>> >>
>>> >> this is the major reason I won't be upgrading to maven 3.
>>> >>
>>> >> I do think that versions should be fixed at maven deploy time - i.e.,
>>> >> when artifacts are deployed to the repository.
>>> >>
>>> >> -Russ
>>> >>
>>> >> At 5:21 AM -0700 3/26/11, bryan.dollery wrote:
>>> >>>Hi,
>>> >>>
>>> >>>I am also getting grief from maven for using variables in my version
>>> >>> fields.
>>> >>>For me, this is unavoidable. Let me explain...
>>> >>>
>>> >>>In my parent pom I have:
>>> >>>
>>> >>>${productVersion}
>>> >>>
>>> >>>And in my properties I have:
>>> >>>
>>> >>> 0-SNAPSHOT
>>> >>> 13.0.${productRevision}
>>> >>>
>>> >>>On a developer's machine, this produces a version number of
>>> >>>
>>> >>> 13.0.0-SNAPSHOT
>>> >>>
>>> >>>Which is exactly what I want.
>>> >>>
>>> >>>However, in my hudson CI server, as part of the maven command I have:
>>> >>>
>>> >>> -DivpnRevision=$SVN_REVISION-nt3
>>> >>>
>>> >>>The $SVN_REVISION variable is provided by hudson. It contains the svn
>>> >>>revision number that has just been built, and the '-nt3' bit is the
>>> >>>environment it was built for.
>>> >>>
>>> >>>I do this because subversion is my revision control system and it,
>>> >>> rightly,
>>> >>>controls the revision number (the clue as to it's purpose is in it's
>>> >>> name).
>>> >>>This is not a job I want to hand off to maven, for many reasons.
>>> >>>
>>> >>>If I use maven 3 for my builds, then my IDEs (both eclipse and
intellij)
>>> >>> are
>>> >>>totally messed up -- maven 3 messes up the classpath because it can't
>>> >>> deal
>>> >>>with the variables. So, I'm stuck on maven 2.
>>> >>>
>>> >>>Now, I don't see this as providing the slightest obstacle to my
ability
>>> >>> to
>>> >>>get repeatable builds. Rather, it's the opposite -- if I want to
repeat
>>> >>> a
>> > >>>build all I have to know is the subversion revision number of the
build
>>> >>> I
>>> >>>want and I can check out that revision and rebuild to recreate an
exact
>>> >>> copy
>>> >>>of the original.
>>> >>>
>>> >>>Just because maven thinks that an alternative approach is
'convention'
>>> >>>doesn't mean that I shouldn't be able to achieve this. CoC is
supposed
>>> >>> to
>>> >>>allow one the choice of following convention, but provide the ability
to
>>> >>> use
>>> >>>configuration where the convention does not fit one's requirements.
>>> >>>
>>> >>>So, what to do?
>>> >>>
>>> >>>Bryan
>>> >
>>> > ---------------------------------------------------------------------
>>> > 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
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Russ Tremain <ru...@releasetools.org>.
At 9:26 PM +0200 5/29/11, Arnaud Héritier wrote:
>For now it is just impossible to use properties in GAV for various technical
>and also philosophical reasons.
I still don't see why the maven deployment plugin cannot be responsible for hardening artifact properties inside deployed poms.
The help plugin goal help:effective-pom does this for example.
This would effectively synchronize the external location of the artifact with the contents of the artifact's pom.
/r
>You may not be agree with the philosophy behind this choice but it is sure
>that for now it is more secure in Maven to avoid this usage as it creates
>many issues.
>
>About the philosophy even if I can be agree that having in the project
>version the one of the SCM may be useful it is with really few SCMs.
>For exemple with CVS it is impossible as each file has a different version.
>And For a DSCM like Git & co your version will be a hash and thus you won't
>be able to sort them.
>
>Arnaud
>
>
>On Thu, May 26, 2011 at 5:24 PM, Manfred Moser <ma...@mosabuam.com> wrote:
>
>> Why dont you use the buildnumber plugin? That might be able to do it for
>> you..
>>
>> http://mojo.codehaus.org/buildnumber-maven-plugin/
>>
>> > For what it's worth, I agree with you both (version strings should be
>> > controlled via the -ahem- version control system), but I am willing to
>> > allow Maven (more to the point, the maven-release-plugin) to take care
>> > of the version strings for me.
>> >
>> > However, if you don't want to, you can still do it yourself with Maven
>> > 3 ... but you *can't* do it with properties at the command-line; you
>> > *will* need to update the poms. Just do it outside of maven before
>> > you perform the final build - should not be hard. If doing that is
>> > too much to ask ... then, yeah, Maven may not be the right framework
>> > for you. But consider that you will need to do *something* similar --
>> > either you write your own around maven, or you write your own around
>> > some other system.
>> >
>> > On Tue, May 17, 2011 at 11:12 AM, Russ Tremain <ru...@releasetools.org>
>> > wrote:
>> >> +1.
>> >>
>> >> this is the major reason I won't be upgrading to maven 3.
>> >>
>> >> I do think that versions should be fixed at maven deploy time - i.e.,
>> >> when artifacts are deployed to the repository.
>> >>
>> >> -Russ
>> >>
>> >> At 5:21 AM -0700 3/26/11, bryan.dollery wrote:
>> >>>Hi,
>> >>>
>> >>>I am also getting grief from maven for using variables in my version
>> >>> fields.
>> >>>For me, this is unavoidable. Let me explain...
>> >>>
>> >>>In my parent pom I have:
>> >>>
>> >>>${productVersion}
>> >>>
>> >>>And in my properties I have:
>> >>>
>> >>> 0-SNAPSHOT
>> >>> 13.0.${productRevision}
>> >>>
>> >>>On a developer's machine, this produces a version number of
>> >>>
>> >>> 13.0.0-SNAPSHOT
>> >>>
>> >>>Which is exactly what I want.
>> >>>
>> >>>However, in my hudson CI server, as part of the maven command I have:
>> >>>
>> >>> -DivpnRevision=$SVN_REVISION-nt3
>> >>>
>> >>>The $SVN_REVISION variable is provided by hudson. It contains the svn
>> >>>revision number that has just been built, and the '-nt3' bit is the
>> >>>environment it was built for.
>> >>>
>> >>>I do this because subversion is my revision control system and it,
>> >>> rightly,
>> >>>controls the revision number (the clue as to it's purpose is in it's
>> >>> name).
>> >>>This is not a job I want to hand off to maven, for many reasons.
>> >>>
>> >>>If I use maven 3 for my builds, then my IDEs (both eclipse and intellij)
>> >>> are
>> >>>totally messed up -- maven 3 messes up the classpath because it can't
>> >>> deal
>> >>>with the variables. So, I'm stuck on maven 2.
>> >>>
>> >>>Now, I don't see this as providing the slightest obstacle to my ability
>> >>> to
>> >>>get repeatable builds. Rather, it's the opposite -- if I want to repeat
>> >>> a
> > >>>build all I have to know is the subversion revision number of the build
>> >>> I
>> >>>want and I can check out that revision and rebuild to recreate an exact
>> >>> copy
>> >>>of the original.
>> >>>
>> >>>Just because maven thinks that an alternative approach is 'convention'
>> >>>doesn't mean that I shouldn't be able to achieve this. CoC is supposed
>> >>> to
>> >>>allow one the choice of following convention, but provide the ability to
>> >>> use
>> >>>configuration where the convention does not fit one's requirements.
>> >>>
>> >>>So, what to do?
>> >>>
>> >>>Bryan
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Arnaud Héritier <ah...@gmail.com>.
For now it is just impossible to use properties in GAV for various technical
and also philosophical reasons.
You may not be agree with the philosophy behind this choice but it is sure
that for now it is more secure in Maven to avoid this usage as it creates
many issues.
About the philosophy even if I can be agree that having in the project
version the one of the SCM may be useful it is with really few SCMs.
For exemple with CVS it is impossible as each file has a different version.
And For a DSCM like Git & co your version will be a hash and thus you won't
be able to sort them.
Arnaud
On Thu, May 26, 2011 at 5:24 PM, Manfred Moser <ma...@mosabuam.com> wrote:
> Why dont you use the buildnumber plugin? That might be able to do it for
> you..
>
> http://mojo.codehaus.org/buildnumber-maven-plugin/
>
> > For what it's worth, I agree with you both (version strings should be
> > controlled via the -ahem- version control system), but I am willing to
> > allow Maven (more to the point, the maven-release-plugin) to take care
> > of the version strings for me.
> >
> > However, if you don't want to, you can still do it yourself with Maven
> > 3 ... but you *can't* do it with properties at the command-line; you
> > *will* need to update the poms. Just do it outside of maven before
> > you perform the final build - should not be hard. If doing that is
> > too much to ask ... then, yeah, Maven may not be the right framework
> > for you. But consider that you will need to do *something* similar --
> > either you write your own around maven, or you write your own around
> > some other system.
> >
> > On Tue, May 17, 2011 at 11:12 AM, Russ Tremain <ru...@releasetools.org>
> > wrote:
> >> +1.
> >>
> >> this is the major reason I won't be upgrading to maven 3.
> >>
> >> I do think that versions should be fixed at maven deploy time - i.e.,
> >> when artifacts are deployed to the repository.
> >>
> >> -Russ
> >>
> >> At 5:21 AM -0700 3/26/11, bryan.dollery wrote:
> >>>Hi,
> >>>
> >>>I am also getting grief from maven for using variables in my version
> >>> fields.
> >>>For me, this is unavoidable. Let me explain...
> >>>
> >>>In my parent pom I have:
> >>>
> >>>${productVersion}
> >>>
> >>>And in my properties I have:
> >>>
> >>> 0-SNAPSHOT
> >>> 13.0.${productRevision}
> >>>
> >>>On a developer's machine, this produces a version number of
> >>>
> >>> 13.0.0-SNAPSHOT
> >>>
> >>>Which is exactly what I want.
> >>>
> >>>However, in my hudson CI server, as part of the maven command I have:
> >>>
> >>> -DivpnRevision=$SVN_REVISION-nt3
> >>>
> >>>The $SVN_REVISION variable is provided by hudson. It contains the svn
> >>>revision number that has just been built, and the '-nt3' bit is the
> >>>environment it was built for.
> >>>
> >>>I do this because subversion is my revision control system and it,
> >>> rightly,
> >>>controls the revision number (the clue as to it's purpose is in it's
> >>> name).
> >>>This is not a job I want to hand off to maven, for many reasons.
> >>>
> >>>If I use maven 3 for my builds, then my IDEs (both eclipse and intellij)
> >>> are
> >>>totally messed up -- maven 3 messes up the classpath because it can't
> >>> deal
> >>>with the variables. So, I'm stuck on maven 2.
> >>>
> >>>Now, I don't see this as providing the slightest obstacle to my ability
> >>> to
> >>>get repeatable builds. Rather, it's the opposite -- if I want to repeat
> >>> a
> >>>build all I have to know is the subversion revision number of the build
> >>> I
> >>>want and I can check out that revision and rebuild to recreate an exact
> >>> copy
> >>>of the original.
> >>>
> >>>Just because maven thinks that an alternative approach is 'convention'
> >>>doesn't mean that I shouldn't be able to achieve this. CoC is supposed
> >>> to
> >>>allow one the choice of following convention, but provide the ability to
> >>> use
> >>>configuration where the convention does not fit one's requirements.
> >>>
> >>>So, what to do?
> >>>
> >>>Bryan
> >
> > ---------------------------------------------------------------------
> > 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 3.0 Artefact/Dependency version discussion request
Posted by Manfred Moser <ma...@mosabuam.com>.
Why dont you use the buildnumber plugin? That might be able to do it for
you..
http://mojo.codehaus.org/buildnumber-maven-plugin/
> For what it's worth, I agree with you both (version strings should be
> controlled via the -ahem- version control system), but I am willing to
> allow Maven (more to the point, the maven-release-plugin) to take care
> of the version strings for me.
>
> However, if you don't want to, you can still do it yourself with Maven
> 3 ... but you *can't* do it with properties at the command-line; you
> *will* need to update the poms. Just do it outside of maven before
> you perform the final build - should not be hard. If doing that is
> too much to ask ... then, yeah, Maven may not be the right framework
> for you. But consider that you will need to do *something* similar --
> either you write your own around maven, or you write your own around
> some other system.
>
> On Tue, May 17, 2011 at 11:12 AM, Russ Tremain <ru...@releasetools.org>
> wrote:
>> +1.
>>
>> this is the major reason I won't be upgrading to maven 3.
>>
>> I do think that versions should be fixed at maven deploy time - i.e.,
>> when artifacts are deployed to the repository.
>>
>> -Russ
>>
>> At 5:21 AM -0700 3/26/11, bryan.dollery wrote:
>>>Hi,
>>>
>>>I am also getting grief from maven for using variables in my version
>>> fields.
>>>For me, this is unavoidable. Let me explain...
>>>
>>>In my parent pom I have:
>>>
>>>${productVersion}
>>>
>>>And in my properties I have:
>>>
>>> 0-SNAPSHOT
>>> 13.0.${productRevision}
>>>
>>>On a developer's machine, this produces a version number of
>>>
>>> 13.0.0-SNAPSHOT
>>>
>>>Which is exactly what I want.
>>>
>>>However, in my hudson CI server, as part of the maven command I have:
>>>
>>> -DivpnRevision=$SVN_REVISION-nt3
>>>
>>>The $SVN_REVISION variable is provided by hudson. It contains the svn
>>>revision number that has just been built, and the '-nt3' bit is the
>>>environment it was built for.
>>>
>>>I do this because subversion is my revision control system and it,
>>> rightly,
>>>controls the revision number (the clue as to it's purpose is in it's
>>> name).
>>>This is not a job I want to hand off to maven, for many reasons.
>>>
>>>If I use maven 3 for my builds, then my IDEs (both eclipse and intellij)
>>> are
>>>totally messed up -- maven 3 messes up the classpath because it can't
>>> deal
>>>with the variables. So, I'm stuck on maven 2.
>>>
>>>Now, I don't see this as providing the slightest obstacle to my ability
>>> to
>>>get repeatable builds. Rather, it's the opposite -- if I want to repeat
>>> a
>>>build all I have to know is the subversion revision number of the build
>>> I
>>>want and I can check out that revision and rebuild to recreate an exact
>>> copy
>>>of the original.
>>>
>>>Just because maven thinks that an alternative approach is 'convention'
>>>doesn't mean that I shouldn't be able to achieve this. CoC is supposed
>>> to
>>>allow one the choice of following convention, but provide the ability to
>>> use
>>>configuration where the convention does not fit one's requirements.
>>>
>>>So, what to do?
>>>
>>>Bryan
>
> ---------------------------------------------------------------------
> 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 3.0 Artefact/Dependency version discussion request
Posted by Zac Thompson <za...@gmail.com>.
For what it's worth, I agree with you both (version strings should be
controlled via the -ahem- version control system), but I am willing to
allow Maven (more to the point, the maven-release-plugin) to take care
of the version strings for me.
However, if you don't want to, you can still do it yourself with Maven
3 ... but you *can't* do it with properties at the command-line; you
*will* need to update the poms. Just do it outside of maven before
you perform the final build - should not be hard. If doing that is
too much to ask ... then, yeah, Maven may not be the right framework
for you. But consider that you will need to do *something* similar --
either you write your own around maven, or you write your own around
some other system.
On Tue, May 17, 2011 at 11:12 AM, Russ Tremain <ru...@releasetools.org> wrote:
> +1.
>
> this is the major reason I won't be upgrading to maven 3.
>
> I do think that versions should be fixed at maven deploy time - i.e., when artifacts are deployed to the repository.
>
> -Russ
>
> At 5:21 AM -0700 3/26/11, bryan.dollery wrote:
>>Hi,
>>
>>I am also getting grief from maven for using variables in my version fields.
>>For me, this is unavoidable. Let me explain...
>>
>>In my parent pom I have:
>>
>>${productVersion}
>>
>>And in my properties I have:
>>
>> 0-SNAPSHOT
>> 13.0.${productRevision}
>>
>>On a developer's machine, this produces a version number of
>>
>> 13.0.0-SNAPSHOT
>>
>>Which is exactly what I want.
>>
>>However, in my hudson CI server, as part of the maven command I have:
>>
>> -DivpnRevision=$SVN_REVISION-nt3
>>
>>The $SVN_REVISION variable is provided by hudson. It contains the svn
>>revision number that has just been built, and the '-nt3' bit is the
>>environment it was built for.
>>
>>I do this because subversion is my revision control system and it, rightly,
>>controls the revision number (the clue as to it's purpose is in it's name).
>>This is not a job I want to hand off to maven, for many reasons.
>>
>>If I use maven 3 for my builds, then my IDEs (both eclipse and intellij) are
>>totally messed up -- maven 3 messes up the classpath because it can't deal
>>with the variables. So, I'm stuck on maven 2.
>>
>>Now, I don't see this as providing the slightest obstacle to my ability to
>>get repeatable builds. Rather, it's the opposite -- if I want to repeat a
>>build all I have to know is the subversion revision number of the build I
>>want and I can check out that revision and rebuild to recreate an exact copy
>>of the original.
>>
>>Just because maven thinks that an alternative approach is 'convention'
>>doesn't mean that I shouldn't be able to achieve this. CoC is supposed to
>>allow one the choice of following convention, but provide the ability to use
>>configuration where the convention does not fit one's requirements.
>>
>>So, what to do?
>>
>>Bryan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Russ Tremain <ru...@releasetools.org>.
+1.
this is the major reason I won't be upgrading to maven 3.
I do think that versions should be fixed at maven deploy time - i.e., when artifacts are deployed to the repository.
-Russ
At 5:21 AM -0700 3/26/11, bryan.dollery wrote:
>Hi,
>
>I am also getting grief from maven for using variables in my version fields.
>For me, this is unavoidable. Let me explain...
>
>In my parent pom I have:
>
>${productVersion}
>
>And in my properties I have:
>
> 0-SNAPSHOT
> 13.0.${productRevision}
>
>On a developer's machine, this produces a version number of
>
> 13.0.0-SNAPSHOT
>
>Which is exactly what I want.
>
>However, in my hudson CI server, as part of the maven command I have:
>
> -DivpnRevision=$SVN_REVISION-nt3
>
>The $SVN_REVISION variable is provided by hudson. It contains the svn
>revision number that has just been built, and the '-nt3' bit is the
>environment it was built for.
>
>I do this because subversion is my revision control system and it, rightly,
>controls the revision number (the clue as to it's purpose is in it's name).
>This is not a job I want to hand off to maven, for many reasons.
>
>If I use maven 3 for my builds, then my IDEs (both eclipse and intellij) are
>totally messed up -- maven 3 messes up the classpath because it can't deal
>with the variables. So, I'm stuck on maven 2.
>
>Now, I don't see this as providing the slightest obstacle to my ability to
>get repeatable builds. Rather, it's the opposite -- if I want to repeat a
>build all I have to know is the subversion revision number of the build I
>want and I can check out that revision and rebuild to recreate an exact copy
>of the original.
>
>Just because maven thinks that an alternative approach is 'convention'
>doesn't mean that I shouldn't be able to achieve this. CoC is supposed to
>allow one the choice of following convention, but provide the ability to use
>configuration where the convention does not fit one's requirements.
>
>So, what to do?
>
>Bryan
>
>
>--
>View this message in context: http://maven.40175.n5.nabble.com/Re-Maven-3-0-Artefact-Dependency-version-discussion-request-tp83857p4265445.html
>Sent from the Maven - Users mailing list archive at Nabble.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 3.0 Artefact/Dependency version discussion request
Posted by "bryan.dollery" <br...@bt.com>.
Hi,
I am also getting grief from maven for using variables in my version fields.
For me, this is unavoidable. Let me explain...
In my parent pom I have:
${productVersion}
And in my properties I have:
0-SNAPSHOT
13.0.${productRevision}
On a developer's machine, this produces a version number of
13.0.0-SNAPSHOT
Which is exactly what I want.
However, in my hudson CI server, as part of the maven command I have:
-DivpnRevision=$SVN_REVISION-nt3
The $SVN_REVISION variable is provided by hudson. It contains the svn
revision number that has just been built, and the '-nt3' bit is the
environment it was built for.
I do this because subversion is my revision control system and it, rightly,
controls the revision number (the clue as to it's purpose is in it's name).
This is not a job I want to hand off to maven, for many reasons.
If I use maven 3 for my builds, then my IDEs (both eclipse and intellij) are
totally messed up -- maven 3 messes up the classpath because it can't deal
with the variables. So, I'm stuck on maven 2.
Now, I don't see this as providing the slightest obstacle to my ability to
get repeatable builds. Rather, it's the opposite -- if I want to repeat a
build all I have to know is the subversion revision number of the build I
want and I can check out that revision and rebuild to recreate an exact copy
of the original.
Just because maven thinks that an alternative approach is 'convention'
doesn't mean that I shouldn't be able to achieve this. CoC is supposed to
allow one the choice of following convention, but provide the ability to use
configuration where the convention does not fit one's requirements.
So, what to do?
Bryan
--
View this message in context: http://maven.40175.n5.nabble.com/Re-Maven-3-0-Artefact-Dependency-version-discussion-request-tp83857p4265445.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Baptiste MATHUS <ml...@batmat.net>.
2010/3/12 Trojan, Krzysztof <kr...@fisglobal.com>
> Hi,
>
> > Well, if I read correctly what you said, you're putting the dependencies
> between project with external properties that defines versions. I guess you
> know one of the main objectives of maven is letting users be able to have an
> always reproducible build.
>
> While a desire to have the build reproducible is OK, I am just questioning
> if a tool should enforce it by removing flexibility. Going this way we will
> end up forbidding dependencies on snapshots (cause somebody could have
> uploaded a broken snapshot to the repo) ? Or force the snapshots to be
> uniquely identified ?
>
Well, what you say is one of the foundation of maven. SNAPSHOT is designed
to change any time. So it's totally OK to develop with such version, and
that was designed for it. SNAPSHOT (or anything moving) is just forbidden
when releasing, which is thoroughly acceptable to me. We release a 25+
modules multi-modules project about once a month using the release-plugin.
We're always using a SNAPSHOT version to define dependency versions between
each others. When we release, all those SNAPSHOT must simply be removed and
be fixed (either manually if this is an externally managed project, or
automatically if the snapshot from a dependency which is in included in the
multi-module project).
So, no. Your example is not the right one. Because when a project has been
tagged, only release versions can be present in the pom.
Though I agree that flexibility is great, you can't have flexibility
everywhere. It always highers software complexity since you're basically
adding *if*s.
Making the build depend on external factor like changing version is just
something too important for maven opiniated design to allow, I guess.
Note I'm no maven developer, but I totally agree this is a good idea to
enforce this. I'm not saying this MUST not be flexible, but I think this is
not a use case where it should be.
> I am not externalizing dependencies to 3rd party stuff - only to siblings
> projects. And this is my responsibility to keep versions of sibling projects
> consistent. In the end, it is my CI process responsibility to check if the
> project can be built, and the changes introduced in such "mixed" branches
> can be built.
>
> Actually, at the moment the only place such "dynamic deferred dependency
> binding" is used, is in snapshot dependencies on sibling projects in
> development branches (and trunk). So the build is unstable by definition
> (depending on snapshot). When tagging I will anyway use a script to replace
> <version>${some.version}<version> with <version>RELEASE-X.Y.Z<version> in
> all the pom.xml's.
>
Not sure to understand precisely what you do. But it seems like what you do
is the kind of this handled gracefully by the maven-release-plugin. Did you
have a look at it? If yes, what doesn't correspond to your needs?
> > I suppose you version the properties used to tag along the project
> itself? If not, then you're out of luck IMO.
>
> Yes, the version related properties (and SCM paths inferred from them) are
> kept in SCM. Actually, in profiles.xml next to the aggregator project
> pom.xml.
>
> The properties in profiles.xml are used also in CI to checkout sources to
> workspace from SCM (I have a Hudson SCM plugin that uses an (Ant) script to
> implement checkout operation, and I think I will make it public soon).
>
Well. I'm using hudson too to build our 25+ multimodules project, and also
build something like 15 multimodules projects (each containing between 5 and
15 modules I'd say). We never needed ant to checkout.
We also use hudson to trigger our release
>
> When tagging there is no danger anyway - the sources are moved to /tags, so
> whatever branch they were originally does not matter. The SCM path will be
> changed to ..../tags/some_tag anyway, and the version properties will be set
> to the release version ID the tag is connected to. This is why we are
> tagging, don't you think? We do not rely on some file to keep information
> that we released code based on revision @7890 - we just do svn copy
> http://xxxxxx/svn/trunk@7890 http://xxxxxx/svn/tags/RELEASE-X.Y.Z
>
>
Well, your release process seems very complicated. I suppose there are
reasons behind this complexity...
I'm also tagging quite often. But only use the release-plugin to do that.
And before using it, I released a lot of times without it. I always had
forgotten something (snapshot version left, scm tag not updated correctly,
sibling project version not-up-to-date, forgotten to go back to snapshot
version...).
> In the long term I ask for introducing a notion of some kind of global
> profiles, with a semantics that such global profile can define properties
> that are used in every aspect of the process. I think it could be something
> as simple as <global>true</global> in a profile definition, that would
> trigger special behaviour (that the profile is injected to every pom.xml,
> say a dependency pom read from repository). From my perspective the profile
> is OK to hold only properties, not plugin config or dependencyManagement or
> anything else, but it is an open question what should be allowed in such
> special profile. We could also use a separate file for that
> (global_profile.xml ;), but it is not necessarily best.
>
What would you do with such global profile when tagging? Are you sure your
need couldn't be achieved using a "corporate" pom? This way, you'd have a
clean way to know what the config was at a time, and so on.
IMO, the problem you're reporting has to do with the mantra of maven:
convention over configuration. Some find it too limiting, others like me
just finds it's kind of refreshing to not reinvent the wheel on each new
project.
Too much flexibility kills flexibility, I guess :-).
Cheers
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
RE: Maven 3.0 Artefact/Dependency version discussion request
Posted by "Trojan, Krzysztof" <kr...@fisglobal.com>.
Hi,
> Well, if I read correctly what you said, you're putting the dependencies between project with external properties that defines versions. I guess you know one of the main objectives of maven is letting users be able to have an always reproducible build.
While a desire to have the build reproducible is OK, I am just questioning if a tool should enforce it by removing flexibility. Going this way we will end up forbidding dependencies on snapshots (cause somebody could have uploaded a broken snapshot to the repo) ? Or force the snapshots to be uniquely identified ?
I am not externalizing dependencies to 3rd party stuff - only to siblings projects. And this is my responsibility to keep versions of sibling projects consistent. In the end, it is my CI process responsibility to check if the project can be built, and the changes introduced in such "mixed" branches can be built.
Actually, at the moment the only place such "dynamic deferred dependency binding" is used, is in snapshot dependencies on sibling projects in development branches (and trunk). So the build is unstable by definition (depending on snapshot). When tagging I will anyway use a script to replace <version>${some.version}<version> with <version>RELEASE-X.Y.Z<version> in all the pom.xml's.
> I suppose you version the properties used to tag along the project itself? If not, then you're out of luck IMO.
Yes, the version related properties (and SCM paths inferred from them) are kept in SCM. Actually, in profiles.xml next to the aggregator project pom.xml.
The properties in profiles.xml are used also in CI to checkout sources to workspace from SCM (I have a Hudson SCM plugin that uses an (Ant) script to implement checkout operation, and I think I will make it public soon).
When tagging there is no danger anyway - the sources are moved to /tags, so whatever branch they were originally does not matter. The SCM path will be changed to ..../tags/some_tag anyway, and the version properties will be set to the release version ID the tag is connected to. This is why we are tagging, don't you think? We do not rely on some file to keep information that we released code based on revision @7890 - we just do svn copy http://xxxxxx/svn/trunk@7890 http://xxxxxx/svn/tags/RELEASE-X.Y.Z
The problem is more generic anyway, cause for now I had problems to inject version properties - the unchanged maven is not propagating properties set in local profile when reading dependencies pom's from repository - so the properties are not substituted anyway in transitive dependency designators. I could pass them with -Dxxx=yyy but it is not the most convenient way (well, there is nothing to prevent me to change the mvn.sh to read some pom.properties and inject them to Maven, but then there is a question how to handle this in embedded environments - like m2eclipse, without patching them all ).
In the long term I ask for introducing a notion of some kind of global profiles, with a semantics that such global profile can define properties that are used in every aspect of the process. I think it could be something as simple as <global>true</global> in a profile definition, that would trigger special behaviour (that the profile is injected to every pom.xml, say a dependency pom read from repository). From my perspective the profile is OK to hold only properties, not plugin config or dependencyManagement or anything else, but it is an open question what should be allowed in such special profile. We could also use a separate file for that (global_profile.xml ;), but it is not necessarily best.
Such behaviour is not available anyway for now - so I have patched Maven to treat profiles with some ID specially (inject them globally) (something like if (profile.getId().contains("my_magic_string")) injectProfile(profile) - this is oversimplification, of course, cause I need a way of propagating the "global" profiles to other pom's, and current 2.2.x API actually do not pass ProfileManager instance to every place I would like to use it in).
This would not break any existing build (cause no existing build would contain <global> set to true ;). And will allow special cases (like mine). The responsibility for the build belongs to build manager in the end, so I don't think Maven team should go too far in restricting people from doing those "evil" things. Forbidding an expression in version, or actually any other part of the pom, is that one step too far.
Regards,
Krzysztof Trojan
----------------
From: bmathus@gmail.com [mailto:bmathus@gmail.com] On Behalf Of Baptiste MATHUS
Sent: 12 March 2010 14:22
To: Maven Users List
Cc: Trojan, Krzysztof
Subject: Re: Maven 3.0 Artefact/Dependency version discussion request
Answering putting Krzysztof in copy. But please, subscribe to the users maven list, because not sure everybody will think about clicking on "reply all".
Well, if I read correctly what you said, you're putting the dependencies between project with external properties that defines versions. I guess you know one of the main objectives of maven is letting users be able to have an always reproducible build.
When externalizing versions between dependencies, how can guaranty that if you extract a version two years after an scm tag, you'll be able to build it?
I suppose you version the properties used to tag along the project itself? If not, then you're out of luck IMO.
Can you explain a bit more what is your use case for proceeding this way?
Cheers
2010/3/10 Jason van Zyl <ja...@maven.org>
The user list is here users@maven.apache.org and you can subscribe to discuss your issues using users-subscribe@maven.apache.org.
On Mar 10, 2010, at 5:45 AM, Trojan, Krzysztof wrote:
> Dear Sir,
>
> First of all I would like to apologize for writing to you directly. I have inadequate information about roles and responsibilities in the Maven project, so I write to You, as Maven PMC member and project founder, hoping you can distribute my email to the right people.
>
> I have been among Maven users for some time now. I am responsible for moving a really big banking solution build to Maven, that we hoped to solve a number of manageability problems we have had in the past. We have found Maven to suit our needs very well, but we are sometimes struggling with Maven ever changing behaviour and APIs. Having said that, Maven still is our tool of choice.
>
> However, we have found that Maven 3.0 is moving in a direction that we find a little bit dangerous for us. We have some arguments against proposed changes, and we kindly ask to open a discussion. In very short words, Maven 3.0 tries to restrict usage of expressions evaluated during build in some parts of the pom.xml (or a project descriptor, more generically speaking). We can see the warning saying something like "using an expression here is a BAD BAD thing, it will threaten stability of your build. We may stop supporting this one day". While we can agree that build stability may be impacted, in the end it is MY (the developer) responsibility to avoid it. Build stability may be impacted by 10 other things you have no control over.
>
> Here is an extract:
> [WARNING] Some problems were encountered while building the effective model for com.acme:BigBankingProject:jar:${BigBankingProject.module.version}
> [WARNING] 'version' contains an expression but should be a constant. @ com.acme.crb:BigBankingProject:${BigBankingProject.module.version}, C:\Workspaces\Corebank_Maven\BigBankingProject\pom.xml
>
> A little bit further down in the log there is
> [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
> [WARNING]
>
> If you want to warn me - fine, thank you, I have been warned. If you have the behaviour configurable (like being able to switch on some "relaxed" mode) - fine. But if the tool says: "you are stupid, but we have a cure, we will prevent you from doing those dangerous things ..." it is a complete misunderstanding. The flexibility is ALWAYS a good thing, and the fact that there will be people who can screw things up badly just because they can, cannot be the justification to remove flexibility in favour of some "ONLY GOOD WAY". And expressions are one of the ways of providing flexibility.
>
> I am unsure if the restriction the warning mention ('version' contains an expression but should be a constant) is only for the main artefact defined in pom.xml, or also applies to dependencies (can I have an expression in dependency version ? I know from the discussions documented in the Internet you were concerned with having a version not resolved to a concrete value - you also mentioned version ranges as potential threat).
>
> If you want to hear the exact use case, I can elaborate it, but it is way too complicated for an initial email.
>
> The main idea behind our solution is that we inject properties into the build specifying the versions of dependencies we want to use. Imagine modules A, B and C; A depends on B, and B depends on C. Now we have a feature branch that changes A and C ... my way is to use A and C from branch, but B from trunk. I want to build A, it references B from trunk ... but as B references C, I need a way to tell B to use C built from branch - here is where expression in the <version> is used, B knows to depend on C in "some version" (${C.module.version}), the actual value of ${C.module.version} is injected, so it gets resolved to correct version in the repository. I hope I have made it clear enough ... There are several similar use cases possible, but only if such "deferred dependency binding" is possible. I kindly request not to forbid it, or at least add some switch that enables this.
>
> Maybe some special switch to Maven ? Or a property that is treated specially, like -Zmy.versionprop=XXX instead of -Dmy.version.property=XXX. If I use -Z (just an example, may be anything you want), just assume I know what I am doing, if it is found in the version ... let it be. Of course this is all oversimplification, we would need to find a workable solution for embedded Maven, and to define this properties in profiles ... but I hope you get the general idea.
>
> I just would like to open a discussion, that I hope will influence the direction Maven is going to.
>
> Kind regards,
> Krzysztof Trojan
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
_____________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven 3.0 Artefact/Dependency version discussion request
Posted by Baptiste MATHUS <ml...@batmat.net>.
Answering putting Krzysztof in copy. But please, subscribe to the users
maven list, because not sure everybody will think about clicking on "reply
all".
Well, if I read correctly what you said, you're putting the dependencies
between project with external properties that defines versions. I guess you
know one of the main objectives of maven is letting users be able to have an
always reproducible build.
When externalizing versions between dependencies, how can guaranty that if
you extract a version two years after an scm tag, you'll be able to build
it?
I suppose you version the properties used to tag along the project itself?
If not, then you're out of luck IMO.
Can you explain a bit more what is your use case for proceeding this way?
Cheers
2010/3/10 Jason van Zyl <ja...@maven.org>
> The user list is here users@maven.apache.org and you can subscribe to
> discuss your issues using users-subscribe@maven.apache.org.
>
> On Mar 10, 2010, at 5:45 AM, Trojan, Krzysztof wrote:
>
> > Dear Sir,
> >
> > First of all I would like to apologize for writing to you directly. I
> have inadequate information about roles and responsibilities in the Maven
> project, so I write to You, as Maven PMC member and project founder, hoping
> you can distribute my email to the right people.
> >
> > I have been among Maven users for some time now. I am responsible for
> moving a really big banking solution build to Maven, that we hoped to solve
> a number of manageability problems we have had in the past. We have found
> Maven to suit our needs very well, but we are sometimes struggling with
> Maven ever changing behaviour and APIs. Having said that, Maven still is our
> tool of choice.
> >
> > However, we have found that Maven 3.0 is moving in a direction that we
> find a little bit dangerous for us. We have some arguments against proposed
> changes, and we kindly ask to open a discussion. In very short words, Maven
> 3.0 tries to restrict usage of expressions evaluated during build in some
> parts of the pom.xml (or a project descriptor, more generically speaking).
> We can see the warning saying something like “using an expression here is a
> BAD BAD thing, it will threaten stability of your build. We may stop
> supporting this one day”. While we can agree that build stability may be
> impacted, in the end it is MY (the developer) responsibility to avoid it.
> Build stability may be impacted by 10 other things you have no control over.
> >
> > Here is an extract:
> > [WARNING] Some problems were encountered while building the effective
> model for
> com.fnis.crb:BigBankingProject:jar:${BigBankingProject.module.version}
> > [WARNING] 'version' contains an expression but should be a constant. @
> com.fnis.crb:BigBankingProject:${BigBankingProject.module.version},
> C:\Workspaces\Corebank_Maven\BigBankingProject\pom.xml
> >
> > A little bit further down in the log there is
> > [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> > [WARNING]
> > [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> > [WARNING]
> >
> > If you want to warn me – fine, thank you, I have been warned. If you have
> the behaviour configurable (like being able to switch on some “relaxed”
> mode) – fine. But if the tool says: “you are stupid, but we have a cure, we
> will prevent you from doing those dangerous things …” it is a complete
> misunderstanding. The flexibility is ALWAYS a good thing, and the fact that
> there will be people who can screw things up badly just because they can,
> cannot be the justification to remove flexibility in favour of some “ONLY
> GOOD WAY”. And expressions are one of the ways of providing flexibility.
> >
> > I am unsure if the restriction the warning mention ('version' contains an
> expression but should be a constant) is only for the main artefact defined
> in pom.xml, or also applies to dependencies (can I have an expression in
> dependency version ? I know from the discussions documented in the Internet
> you were concerned with having a version not resolved to a concrete value –
> you also mentioned version ranges as potential threat).
> >
> > If you want to hear the exact use case, I can elaborate it, but it is way
> too complicated for an initial email.
> >
> > The main idea behind our solution is that we inject properties into the
> build specifying the versions of dependencies we want to use. Imagine
> modules A, B and C; A depends on B, and B depends on C. Now we have a
> feature branch that changes A and C … my way is to use A and C from branch,
> but B from trunk. I want to build A, it references B from trunk … but as B
> references C, I need a way to tell B to use C built from branch – here is
> where expression in the <version> is used, B knows to depend on C in “some
> version” (${C.module.version}), the actual value of ${C.module.version} is
> injected, so it gets resolved to correct version in the repository. I hope I
> have made it clear enough … There are several similar use cases possible,
> but only if such “deferred dependency binding” is possible. I kindly request
> not to forbid it, or at least add some switch that enables this.
> >
> > Maybe some special switch to Maven ? Or a property that is treated
> specially, like –Zmy.versionprop=XXX instead of –Dmy.version.property=XXX.
> If I use –Z (just an example, may be anything you want), just assume I know
> what I am doing, if it is found in the version … let it be. Of course this
> is all oversimplification, we would need to find a workable solution for
> embedded Maven, and to define this properties in profiles … but I hope you
> get the general idea.
> >
> > I just would like to open a discussion, that I hope will influence the
> direction Maven is going to.
> >
> > Kind regards,
> > Krzysztof Trojan
> > Senior Application Technician
> > FIS Technology Services (Poland)
> > Al. Jerozolimskie 81, 02-001 Warsaw, Poland
> > krzysztof.trojan@fnis.com
> > Tel: +48 601 98 96 96
> > Fax: +48 22 695 05 51
> > www.fisglobal.com
> > <image001.jpg>
> > This e-mail contains privileged and confidential information intended for
> the use of the addressees named above. If you are not the intended recipient
> of this e-mail, you are hereby notified that you must not disseminate it,
> copy it or take any action in respect of any information contained in it. If
> you have received this e-mail in error please notify the sender immediately
> by e-mail and destroy this e-mail and its attachments
> >
> >
> > _____________
> >
> > The information contained in this message is proprietary and/or
> confidential. If you are not the intended recipient, please: (i) delete the
> message and all copies; (ii) do not disclose, distribute or use the message
> in any manner; and (iii) notify the sender immediately. In addition, please
> be aware that any message addressed to our domain is subject to archiving
> and review by persons other than the intended recipient. Thank you.
> > _____________
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !