Re: How to use 5 digit version numbers with Maven ?
in fact, the way the issue is described is misleading: "How to use 5 digit version numbers with Maven ?" and "Maven only handles 3 digit version numbers using the versions-maven-plugin" it should be phrased: "How to use 5 digit version numbers with versions-maven-plugin?" and "versions-maven-plugin only handles 3 digit version numbers" because Maven itself has no limitation on digits: like Karl Heinz pointed out, there was a limitation in Maven 2, but it was removed in Maven 3 with https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning and FYI, Maven itself does only comparison on versions, no updates Plugins can do a lot of different things, and multiple plugins propose to update version: the most known being maven-release-plugin (from Apache Maven team) and versions-maven-plugin (from MojoHaus team) Regards, Hervé (who worked hard a few yeas ago on removing the limitation in Maven 3 :) ) Le jeudi 7 janvier 2016 20:16:44 Karl Heinz Marbaise a écrit : > Hi, > > On 1/7/16 1:08 PM, Mehul Sanghvi wrote: > > We need to use 5 digit version numbers going forward. Maven only handles > > 3 > > digit version numbers > > where is this documented ? > > which is simply not true. > > https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning > > Since Maven 3 you can use as many version numbers as you like... > > > using the versions-maven-plugin. Is there a way to use 5 digits for > > project.version ? > > > > What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and > > 1.2.3.4.5 vs 1.2.3 after > > the release. > > You should simply use itcause it works... > > > Furthermore if you use Maven 3.2.5+ you can check the behaviour on > command line via: (You have to change the maven-artifact-VERSION.jar > accordingly to your Maven installation) this small CLI app which is > included in your maven distribution: > > ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar > 1.0.2.5-SNAPSHOT 1.0.2.6-SNAPSHOT > Display parameters as parsed by Maven (in canonical form) and comparison > result: > 1. 1.0.2.5-SNAPSHOT == 1.0.2.5-snapshot > 1.0.2.5-SNAPSHOT < 1.0.2.6-SNAPSHOT > 2. 1.0.2.6-SNAPSHOT == 1.0.2.6-snapshot > ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar > 1.0.2.5.0.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT > Display parameters as parsed by Maven (in canonical form) and comparison > result: > 1. 1.0.2.5.0.0-SNAPSHOT == 1.0.2.5-snapshot > 1.0.2.5.0.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT > 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot > ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar > 1.0.2.5.10.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT > Display parameters as parsed by Maven (in canonical form) and comparison > result: > 1. 1.0.2.5.10.0-SNAPSHOT == 1.0.2.5.10-snapshot > 1.0.2.5.10.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT > 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot > ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar > 1.0.2.5.100.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT > Display parameters as parsed by Maven (in canonical form) and comparison > result: > 1. 1.0.2.5.100.0-SNAPSHOT == 1.0.2.5.100-snapshot > 1.0.2.5.100.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT > 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot > > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to use 5 digit version numbers with Maven ?
We need to use 5 digit version numbers going forward. Maven only handles 3 digit version numbers using the versions-maven-plugin. Is there a way to use 5 digits for project.version ? What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and 1.2.3.4.5 vs 1.2.3 after the release. cheers, mehul -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
RE: How to use 5 digit version numbers with Maven ?
Like many more advanced Maven scenarios, the documentation is sketchy at best. Here is an example version rules xml file http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://mojo.codehaus.org/versions-maven-plugin/rule/2.0.0 http://mojo.codehaus.org/versions-maven-plugin/xsd/rule-2.0.0.xsd;> -Original Message- From: Mehul Sanghvi [mailto:mehul.sang...@gmail.com] Sent: Thursday, January 07, 2016 6:31 AM To: Maven Users List Subject: Re: How to use 5 digit version numbers with Maven ? Is there documentation on the mercury scheme ? I tried following the link at http://www.mojohaus.org/versions-maven-plugin/version-rules.html, but that just gives me a "Page Not Found". cheers, mehul On Thu, Jan 7, 2016 at 7:27 AM, Robert Patrick <robert.patr...@oracle.com> wrote: > Yes, you can use the Mercury version numbering scheme for artifacts > having the 5 digit version number. Create a version rules XML file > that specifies which artifacts use Mercury and which artifacts use Maven > version schemes. > Pass the file using the versions plugin's rulesUri or > -Dmaven.version.rules... > > > On Jan 7, 2016, at 6:08 AM, Mehul Sanghvi <mehul.sang...@gmail.com> > wrote: > > > > We need to use 5 digit version numbers going forward. Maven only > handles 3 > > digit version numbers > > using the versions-maven-plugin. Is there a way to use 5 digits for > > project.version ? > > > > What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and > > 1.2.3.4.5 vs 1.2.3 after > > the release. > > > > > > > > cheers, > > > > mehul > > > > -- > > Mehul N. Sanghvi > > email: mehul.sang...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to use 5 digit version numbers with Maven ?
Is there documentation on the mercury scheme ? I tried following the link at http://www.mojohaus.org/versions-maven-plugin/version-rules.html, but that just gives me a "Page Not Found". cheers, mehul On Thu, Jan 7, 2016 at 7:27 AM, Robert Patrick <robert.patr...@oracle.com> wrote: > Yes, you can use the Mercury version numbering scheme for artifacts having > the 5 digit version number. Create a version rules XML file that specifies > which artifacts use Mercury and which artifacts use Maven version schemes. > Pass the file using the versions plugin's rulesUri or > -Dmaven.version.rules... > > > On Jan 7, 2016, at 6:08 AM, Mehul Sanghvi <mehul.sang...@gmail.com> > wrote: > > > > We need to use 5 digit version numbers going forward. Maven only > handles 3 > > digit version numbers > > using the versions-maven-plugin. Is there a way to use 5 digits for > > project.version ? > > > > What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and > > 1.2.3.4.5 vs 1.2.3 after > > the release. > > > > > > > > cheers, > > > > mehul > > > > -- > > Mehul N. Sanghvi > > email: mehul.sang...@gmail.com > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Mehul N. Sanghvi email: mehul.sang...@gmail.com
Re: How to use 5 digit version numbers with Maven ?
Yes, you can use the Mercury version numbering scheme for artifacts having the 5 digit version number. Create a version rules XML file that specifies which artifacts use Mercury and which artifacts use Maven version schemes. Pass the file using the versions plugin's rulesUri or -Dmaven.version.rules... > On Jan 7, 2016, at 6:08 AM, Mehul Sanghvi <mehul.sang...@gmail.com> wrote: > > We need to use 5 digit version numbers going forward. Maven only handles 3 > digit version numbers > using the versions-maven-plugin. Is there a way to use 5 digits for > project.version ? > > What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and > 1.2.3.4.5 vs 1.2.3 after > the release. > > > > cheers, > > mehul > > -- > Mehul N. Sanghvi > email: mehul.sang...@gmail.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to use 5 digit version numbers with Maven ?
Hi, On 1/7/16 1:08 PM, Mehul Sanghvi wrote: We need to use 5 digit version numbers going forward. Maven only handles 3 digit version numbers where is this documented ? which is simply not true. https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning Since Maven 3 you can use as many version numbers as you like... using the versions-maven-plugin. Is there a way to use 5 digits for project.version ? What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and 1.2.3.4.5 vs 1.2.3 after the release. You should simply use itcause it works... Furthermore if you use Maven 3.2.5+ you can check the behaviour on command line via: (You have to change the maven-artifact-VERSION.jar accordingly to your Maven installation) this small CLI app which is included in your maven distribution: ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar 1.0.2.5-SNAPSHOT 1.0.2.6-SNAPSHOT Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 1.0.2.5-SNAPSHOT == 1.0.2.5-snapshot 1.0.2.5-SNAPSHOT < 1.0.2.6-SNAPSHOT 2. 1.0.2.6-SNAPSHOT == 1.0.2.6-snapshot ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar 1.0.2.5.0.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 1.0.2.5.0.0-SNAPSHOT == 1.0.2.5-snapshot 1.0.2.5.0.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar 1.0.2.5.10.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 1.0.2.5.10.0-SNAPSHOT == 1.0.2.5.10-snapshot 1.0.2.5.10.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar 1.0.2.5.100.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT Display parameters as parsed by Maven (in canonical form) and comparison result: 1. 1.0.2.5.100.0-SNAPSHOT == 1.0.2.5.100-snapshot 1.0.2.5.100.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: CD, version numbers, IDE integration
We will have a full write up but we need to change the way resolution works to
make building partial sets from the reactor correctly (--projects, --am, and
--amd). My requirement is that there be full documentation before we release it.
On Aug 31, 2014, at 10:40 PM, Milos Kleint mkle...@gmail.com wrote:
netbeans is also embedding 3.0.5 (which is used for project loading
exclusively, for building any version can be used)
Milos
On Mon, Sep 1, 2014 at 8:22 AM, Mark Derricutt m...@talios.com wrote:
Currently IntelliJ embeds 3.0.5 and gets perplexed over anything 3.2.x
specific ( it really doesn't like the tiles plugin ).
I have a fork of Idea where I've bumped the embedded version of Maven but
as yet, it dies horribly with RMI Classloader issues :(
On 1 Sep 2014, at 4:57, Benson Margulies wrote:
sure that IntelliJ would be most perplexed by
version${our-version}/version at the top of a project hierarchy. I
gave up on Eclipse some time ago, but I'd be nearly as surprised if
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
CD, version numbers, IDE integration
As of Maven 3.2.x, we have this ability to parameterize a project
version, or to drop some sort of extension point module into a Maven
install to take control of versioning.
I'm considering pushing this as an approach. However, I would be
grateful for some more details about it. Has anyone published anything
substantive?
In particular, how do people get IDEs to cope with this? I'm pretty
sure that IntelliJ would be most perplexed by
version${our-version}/version at the top of a project hierarchy. I
gave up on Eclipse some time ago, but I'd be nearly as surprised if
M2E did not suffer digestive distress in the same circumstance. Is the
practical alternative to put a fixed string in there but use the
extension mechanism to override it in actual builds?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: CD, version numbers, IDE integration
Takari's CD solution will be open sourced around the end of September. We have
two implementations in progress: one for a customer with a large project (500+
modules) in p4, and another for Facebook Presto which is a smaller project (20+
modules). The large project has been using the mechanism for 3-4 months now,
and we're just finishing the first prototype for the Presto team. We still have
many details to work out and it's my primary focus right now. When we're done
and it works for these two projects the documentation will be published in the
form of an online book. One of our requirements is interop with Eclipse and
IDEA.
We are currently using a mechanism to pass in a revision, but we have a working
version of a metadata generator that turn 1.0.0.generation into something like
1.0.0.[date]-[buildNumber]-[sha1] for the Git implementation. Happy to chat
about it offline but we won't release it until it works completely end-to-end
for our two customers.
On Aug 31, 2014, at 12:57 PM, Benson Margulies bimargul...@gmail.com wrote:
As of Maven 3.2.x, we have this ability to parameterize a project
version, or to drop some sort of extension point module into a Maven
install to take control of versioning.
I'm considering pushing this as an approach. However, I would be
grateful for some more details about it. Has anyone published anything
substantive?
In particular, how do people get IDEs to cope with this? I'm pretty
sure that IntelliJ would be most perplexed by
version${our-version}/version at the top of a project hierarchy. I
gave up on Eclipse some time ago, but I'd be nearly as surprised if
M2E did not suffer digestive distress in the same circumstance. Is the
practical alternative to put a fixed string in there but use the
extension mechanism to override it in actual builds?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
The modern conservative is engaged in one of man's oldest exercises in moral
philosophy; that is,
the search for a superior moral justification for selfishness.
-- John Kenneth Galbraith
Re: CD, version numbers, IDE integration
Currently IntelliJ embeds 3.0.5 and gets perplexed over anything 3.2.x
specific ( it really doesn't like the tiles plugin ).
I have a fork of Idea where I've bumped the embedded version of Maven
but as yet, it dies horribly with RMI Classloader issues :(
On 1 Sep 2014, at 4:57, Benson Margulies wrote:
sure that IntelliJ would be most perplexed by
version${our-version}/version at the top of a project hierarchy. I
gave up on Eclipse some time ago, but I'd be nearly as surprised if
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: CD, version numbers, IDE integration
netbeans is also embedding 3.0.5 (which is used for project loading
exclusively, for building any version can be used)
Milos
On Mon, Sep 1, 2014 at 8:22 AM, Mark Derricutt m...@talios.com wrote:
Currently IntelliJ embeds 3.0.5 and gets perplexed over anything 3.2.x
specific ( it really doesn't like the tiles plugin ).
I have a fork of Idea where I've bumped the embedded version of Maven but
as yet, it dies horribly with RMI Classloader issues :(
On 1 Sep 2014, at 4:57, Benson Margulies wrote:
sure that IntelliJ would be most perplexed by
version${our-version}/version at the top of a project hierarchy. I
gave up on Eclipse some time ago, but I'd be nearly as surprised if
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Moving to maven-compatible version numbers?
Hello. I'm working on a project that uses version numbers of the form: 2.0-rc9 Where '2' is the major version, '0' is the minor version, and 'rc9' is obviously some sort of qualifier - this one being release candidate 9. Obviously, Maven doesn't deal with this too well (it falls back to lexicographical ordering with regards to version ranges). I'm looking at this page: http://mojo.codehaus.org/versions-maven-plugin/version-rules.html Given that there aren't build numbers, what's the least intrusive and most correct version numbering scheme to switch to for this project? By least intrusive, I believe I mean closest to the existing one in terms of meaning. I think it's probably going to be: M.N.P-rc09 Where 'M' is the major version, 'N' is the minor version, 'P' is the incremental version and '-rc09' is a qualifier in a format such that '-rc10' would be lexicographically greater than '-rc09' (in order for version ranges to work correctly). Any assistance would be appreciated (or any just shut up and use that messages, too). - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. I see this as a completely different task where you're simply using Maven as a utility tool. When using Maven as a build tool, you will be deploying the artifacts to a repository. What you then do with the artifacts after that (like e.g. publish to an app server) is outside of the build story, and should be handled as a separate task. Ok, but in that case I'm just simplifying life: We're having lots of projects building at least one EAR, and each EAR is deployed to the same application server(s), but in different flavors: developer (snapshot) build, integration build and/or release build. Using a CI server configured with special jobs doing these deployment tasks would result in having to implement the same tasks again and again. IMHO this is more error-prone than having a default job in a parent pom doing that... Regards Thorsten
Re: Re: Re: useing profiles to control properties to drive version numbers in poms
We're having lots of projects building at least one EAR, and each EAR is deployed to the same application server(s), but in different flavors: developer (snapshot) build, integration build and/or release build. Using a CI server configured with special jobs doing these deployment tasks would result in having to implement the same tasks again and again. IMHO this is more error-prone than having a default job in a parent pom doing that... When been over this several times on this list. You have to extract the configuration out of the binary. You mustn't have a Maven build that could generate different flavors of an artifact. Which one would you deploy to the repository? If you can't separate the configuration out of the binary, you should have multiple projects each one generate one of the flavors. /Anders - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, When been over this several times on this list. You have to extract the configuration out of the binary. You mustn't have a Maven build that could generate different flavors of an artifact. Which one would you deploy to the repository? Ok, this was a bit misleading by me. With flavors I just meant * mvn clean deploy by command or on a nightly base * mvn release:prepare release:perform final releases / pre-releases meant for an integration build and/or tests by our business department If you can't separate the configuration out of the binary, you should have multiple projects each one generate one of the flavors. +1 Regards Thorsten
RE: useing profiles to control properties to drive version numbers in poms
Chad path of least resistance is to set the version of the project in pom.xml
(at top) and then reference project.version e.g.
version${project.version}/version HTH
Martin
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est
interdite. Ce message sert à l'information seulement et n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
From: chad.da...@emc.com
To: users@maven.apache.org
Date: Fri, 16 Mar 2012 12:51:03 -0400
Subject: useing profiles to control properties to drive version numbers in
poms
Does anyone have any experience using a property to control the version
numbers in poms? Like, version${myVersion}/version and the myVersion
property can be set in profiles. . .
Thoughts?
Re: Re: useing profiles to control properties to drive version numbers in poms
Hi, Yes, profiles are evil. If you use them for changing / defining _what_ gets built and/or how, yes. If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. Regards Thorsten
Re: Re: useing profiles to control properties to drive version numbers in poms
If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. I see this as a completely different task where you're simply using Maven as a utility tool. When using Maven as a build tool, you will be deploying the artifacts to a repository. What you then do with the artifacts after that (like e.g. publish to an app server) is outside of the build story, and should be handled as a separate task. You could use Maven to do that, and then you could have any number of profiles to alter the behavior. But I want to stress that that's not a build job. This is my repository-focused view of things. /Anders - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
On 18/03/2012 5:41 PM, Thorsten Heit wrote: Hi, Yes, profiles are evil. If you use them for changing / defining _what_ gets built and/or how, yes. If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. Not clear that profiles are the right approach for that. You will probably be unhappy going down this road. I might be off-base but it does not sound like the right way to solve that problem. In any event, good luck. I hope that you are able to prove me wrong. Ron Regards Thorsten -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
On 18/03/2012 5:53 PM, Anders Hammar wrote: If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. I'm using profiles at work for the sole purpose of deciding what to do with the build artifact, i.e. activating different deployment targets (application servers) for an EAR. I see this as a completely different task where you're simply using Maven as a utility tool. When using Maven as a build tool, you will be deploying the artifacts to a repository. What you then do with the artifacts after that (like e.g. publish to an app server) is outside of the build story, and should be handled as a separate task. You could use Maven to do that, and then you could have any number of profiles to alter the behavior. But I want to stress that that's not a build job. This is my repository-focused view of things. And a very sensible view at that! /Anders - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
Not good.
Dependency versions should be deterministic. For the same reason avoid
version ranges.
/Anders (mobile)
Den 16 mar 2012 17.52 skrev chad.da...@emc.com:
Does anyone have any experience using a property to control the version
numbers in poms? Like, version${myVersion}/version and the myVersion
property can be set in profiles. . .
Thoughts?
RE: useing profiles to control properties to drive version numbers in poms
Not good. Dependency versions should be deterministic. For the same reason avoid version ranges. That's pretty definitive, and I think I agree on a gut level. Can you articulate any specific issues? I'd appreciate it if you could. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
Search the forum for profile. You will see people in all kinds of difficulty and dead-ends caused by trying to use profiles. There are (apparently) some actual uses for profiles but far more cases of misuse. We have never used profiles but from watching the forum for 4+years, my advice is to get your builds working well without profiles and then see if there is an opportunity for optimization with profiles. Profiles are processed at a certain point in the maven build process so there are things that you can not do with them. Maven supports a certain build philosophy and will defeat anyone who tries to go against this. Try to go down the simplest road and let Maven do its thing. Version ranges are another bad idea. There is no reason not to pick a version of a dependency. You are only going to have 1 version at run-time anyway and it might as well be one that you pick and have tested. If you search the forum, you will find problems and silliness caused by the use of version ranges. I hope that this helps. Ron On 16/03/2012 1:18 PM, chad.da...@emc.com wrote: Not good. Dependency versions should be deterministic. For the same reason avoid version ranges. That's pretty definitive, and I think I agree on a gut level. Can you articulate any specific issues? I'd appreciate it if you could. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
The thing is that having the possibility of change a dependency version during build time would/could sound as a good thing. BUT, you have to remember that your pom gets deployed to a repo and will be consumed by other people. If the pom does not have pinned downed versions but would change depending on what profiles are specified. Something that will work for someone will not work for someone else. If you would write a new release plugin that would update the pom that gets deployed to specify the exact versions used during build, it would be fine. But that's not the case with the current release plugin. /Anders On Fri, Mar 16, 2012 at 18:18, chad.da...@emc.com wrote: Not good. Dependency versions should be deterministic. For the same reason avoid version ranges. That's pretty definitive, and I think I agree on a gut level. Can you articulate any specific issues? I'd appreciate it if you could. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: useing profiles to control properties to drive version numbers in poms
Yes, profiles are evil. If you think you should be using profiles, think again. If you still think they are the solution, please think it through once more. If you still persist, go use Ant. Profiles are simply very rarely a good solution. /Anders On Fri, Mar 16, 2012 at 19:31, Ron Wheeler rwhee...@artifact-software.com wrote: Search the forum for profile. You will see people in all kinds of difficulty and dead-ends caused by trying to use profiles. There are (apparently) some actual uses for profiles but far more cases of misuse. We have never used profiles but from watching the forum for 4+years, my advice is to get your builds working well without profiles and then see if there is an opportunity for optimization with profiles. Profiles are processed at a certain point in the maven build process so there are things that you can not do with them. Maven supports a certain build philosophy and will defeat anyone who tries to go against this. Try to go down the simplest road and let Maven do its thing. Version ranges are another bad idea. There is no reason not to pick a version of a dependency. You are only going to have 1 version at run-time anyway and it might as well be one that you pick and have tested. If you search the forum, you will find problems and silliness caused by the use of version ranges. I hope that this helps. Ron On 16/03/2012 1:18 PM, chad.da...@emc.com wrote: Not good. Dependency versions should be deterministic. For the same reason avoid version ranges. That's pretty definitive, and I think I agree on a gut level. Can you articulate any specific issues? I'd appreciate it if you could. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Recommended way of maintaining dependant version numbers
I have a number of closely related projects which I build from a top level
pom file than in turn invokes each one of the directory builds. Originally
I did each project with a constant version number, that I manually updated.
However, I quickly found this became unmaintainable, as changes to a
dependencies often broke of fixed problems in the child projects. So I
would get a report like EMEA channel load version 2.0.1 was had error foo.
So since often someone would forget to update the child version numbers I
would then have to ask questions like what version the salesforce API was
populated in there lib directory to know exactly what code base was in use.
So, I updated the version numbers to be inherited as follows:
RedHatSForceEnterprise.version23.0.0/RedHatSForceEnterprise.version
RedHatSForceUtils.version${RedHatSForceEnterprise.version}.2/RedHatSForceUtils.version
RedHatSForceAccountPurge.version${RedHatSForceUtils.version}.4/RedHatSForceAccountPurge.version
RedHatSForceAspire.version${RedHatSForceUtils.version}.1/RedHatSForceAspire.version
RedHatSForceTools.version${RedHatSForceUtils.version}.3/RedHatSForceTools.version
...
The child pom.xml files simply have version statements such as:
version${RedHatSForceEnterprise.version}/version
So for example if someone reports a problem with the RedHatSForceTools
application, I know exactly what version of the of the utils, and enterprise
api being used as well.
This has worked well for me for the last 3 years, and has avoided all issues
with version numbers not being updated, and knowing exactly what versions of
dependencies are in each build.
Now here is the problem. After a recent update of maven, everytime I build
I get the following type of warning:
[INFO] [WARNING]
[INFO] [WARNING] Some problems were encountered while building the effective
model for com.redhat.sforce:RedHatSForceEnterprise:jar:23.0.0
[INFO] [WARNING] 'version' contains an expression but should be a constant.
@
com.redhat.sforce:RedHatSForceEnterprise:${RedHatSForceEnterprise.version},
/autohome/docbill/source/svn/SA4/projects/salesforce/sforce/RedHatSForceEnterprise/generate-sources.xml,
line 13, column 12
[INFO] [WARNING]
[INFO] [WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[INFO] [WARNING]
[INFO] [WARNING] For this reason, future Maven versions might no longer
support building such malformed projects.
[INFO] [WARNING]
So clearly the way I am managing the versions is no-longer valid. What is
the recommended way to do this?
Regards,
Bill
--
View this message in context:
http://maven.40175.n5.nabble.com/Recommended-way-of-maintaining-dependant-version-numbers-tp5547974p5547974.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Release version numbers in large multi-module project
it will choose the version that is closest... with the provisio that ranges can trim the selection. keep in mind that version1.0.0/version is You can select any version but if you can pick 1.0.0 version[1.0.0]/version is You must select 1.0.0 or fail the build version[1.0.0,2.0.0)/version is You must select any version from 1.0.0 up to but not including 2.0.0 or fail the build -Stephen On 24 September 2010 02:18, Stuart Sierra m...@stuartsierra.com wrote: On Tue, Sep 21, 2010 at 8:16 AM, Anders Hammar and...@hammar.net wrote: Not sure I understand. But basically, the end user controls the transitive dependencies. Your artifacts can't do that. So if he wants to use version A of Clojure, he can do that regardless of the version of your artifacts he's using (it might not work though). Ok, this was one of the things I was trying to figure out. Say that Bob is working on Project Bob (not affiliated with Microsoft ;) which declares a dependency on Clojure 1.0.0 and clojure.contrib.sql 1.3.0. Meanwhile, clojure.contrib.sql has a dependency (via the dependencyManagement section of its parent POM) on Clojure 1.2.0. This *is* possible in Clojure, although perhaps unlikely. Will Maven fail with an error, or just silently choose Clojure 1.2.0? -S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release version numbers in large multi-module project
On Tue, Sep 21, 2010 at 8:16 AM, Anders Hammar and...@hammar.net wrote: Not sure I understand. But basically, the end user controls the transitive dependencies. Your artifacts can't do that. So if he wants to use version A of Clojure, he can do that regardless of the version of your artifacts he's using (it might not work though). Ok, this was one of the things I was trying to figure out. Say that Bob is working on Project Bob (not affiliated with Microsoft ;) which declares a dependency on Clojure 1.0.0 and clojure.contrib.sql 1.3.0. Meanwhile, clojure.contrib.sql has a dependency (via the dependencyManagement section of its parent POM) on Clojure 1.2.0. This *is* possible in Clojure, although perhaps unlikely. Will Maven fail with an error, or just silently choose Clojure 1.2.0? -S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release version numbers in large multi-module project
IMO dependencies should never be inherited the results are always fuzzy, consider Parent P with defines a dependency on A 1.1 and Parent P' that defines a dependency on A 2.1 And a war project W that depends on two projects one with parent P and the other parent P'... which version of A should you end up with? Even if you have an answer to this question does it actually make sense? OO teachs us to inherit functionally and compose dependencies. The simplest solution and most consistent is to define compositions As an aside every linux distribution uses ranges to define package relationships, because it works and really could not be done any other way. We are talking debian, ubuntu, gentoo, redhat, suse etc why should dependencies in java be any different? Michael On Tuesday 21 September 2010 16:35:16 Anders Hammar wrote: The user of the module can always control this through a dependencyManagemet section. That's how it should be done. Ranges have all sorts of strange impact, IMO. One would be that your (and the user's) builds are not necessarily reproducable; the outcome might change should a new version of clojure be released. I strongly argue that you should declare a dependency to a specific version (likely the latest available) and let the end user handle any change to this. /Anders On Tue, Sep 21, 2010 at 02:21, Stuart Sierra m...@stuartsierra.com wrote: Hello, Maveners, I'm managing the build for clojure-contrib, a diverse collection of libraries for the Clojure programming language. After several releases as a monolithic JAR, I nudged ;-) the community into a multi-module build. Now I have 61 sub-modules, all depending on a single parent module that defines the dependency on Clojure itself. Here's the catch: most modules will work with any version of Clojure; the user of the module should be able to choose. I want the parent module to have a dependency on Clojure with a range like [1.0.0,2.0.0). Aside from maven-release-plugin complaining about SNAPSHOT dependencies, are there any negative implications to doing this? Or am I doing it wrong, should I be using some other mechanism to manage this type of dependency? Thanks, -S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release version numbers in large multi-module project
Neat :) Is the plan here to have 61 individual releases/version numbers or a single release for the entire collection? I know people have wanted independent cycles for certain things but under git this isn't really workable ( a) the release plugin b) tagging over the entire repo ). Also, under Maven 3 you won't get the -SNAPSHOT complaints until the current snapshot issues are sorted, However - I would put the clojure version in the parents dependencyManagement section pointing at current clojure, and declare the dependency in each module. For those that have 1.1/1.2 differences, if you went the route of having -two- artifacts for the various versions, you could declare the dependency -and- the version of clojure. Or is the plan to support both versions from the same artifact? -- Pull me down under... On Tue, Sep 21, 2010 at 12:21 PM, Stuart Sierra m...@stuartsierra.comwrote: After several releases as a monolithic JAR, I nudged ;-) the community into a multi-module build. Now I have 61 sub-modules, all depending on a single parent module that defines the dependency on Clojure itself.
Re: Release version numbers in large multi-module project
Neat :) Is the plan here to have 61 individual releases/version numbers or a single release for the entire collection? This is up to you. Out of the end user's perspective, every artifact that you want to control has to be added to the dependencyManagement section. I know people have wanted independent cycles for certain things but under git this isn't really workable ( a) the release plugin b) tagging over the entire repo ). I don't use git, so I don't know. However, having independent release cycles will give you more flexibility at the cost of more complexity. I would suggest try keeping it simple if possible. However, having a separate release cycle for things that aren't related makes sense. Also, under Maven 3 you won't get the -SNAPSHOT complaints until the current snapshot issues are sorted, Not sure what you mean... However - I would put the clojure version in the parents dependencyManagement section pointing at current clojure, and declare the dependency in each module. Yes, that's the Maven way. For those that have 1.1/1.2 differences, if you went the route of having -two- artifacts for the various versions, you could declare the dependency -and- the version of clojure. Or is the plan to support both versions from the same artifact? Not sure I understand. But basically, the end user controls the transitive dependencies. Your artifacts can't do that. So if he wants to use version A of Clojure, he can do that regardless of the version of your artifacts he's using (it might not work though). Would it make sense to use an older version of your artifacts (the libs) together with a newer version of Clojure (for which you have released lib artifacts)? Most likely no, but the end user is free to do whatever he wants. And he will probably do it too...:-) /Anders -- Pull me down under... On Tue, Sep 21, 2010 at 12:21 PM, Stuart Sierra m...@stuartsierra.com wrote: After several releases as a monolithic JAR, I nudged ;-) the community into a multi-module build. Now I have 61 sub-modules, all depending on a single parent module that defines the dependency on Clojure itself.
Re: Release version numbers in large multi-module project
On Tue, Sep 21, 2010 at 7:32 AM, Mark Derricutt m...@talios.com wrote: Neat :) Is the plan here to have 61 individual releases/version numbers or a single release for the entire collection? 61 individual versions was my original plan, but now I'm balking at the complexity of that. I'm open to suggestions for a reasonable solution. :) -S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release version numbers in large multi-module project
On Wed, Sep 22, 2010 at 12:16 AM, Anders Hammar and...@hammar.net wrote: I don't use git, so I don't know. However, having independent release cycles will give you more flexibility at the cost of more complexity. I would suggest try keeping it simple if possible. However, having a separate release cycle for things that aren't related makes sense. The problem with git here is more a matter of purity and maintainence, unlike subversion which tags/branches at a directory level, git tags/branches the entire repository, and you can't checkout but a sub-tree of a repository in a manner similar to svn. Ideally you want to have ONLY tags for module-a in module-a's repository - which leads to a single artifact per repository pattern, which with 61 sub modules is rather. horrible ( and git submodules don't really help much here ). Also, under Maven 3 you won't get the -SNAPSHOT complaints until the current snapshot issues are sorted, Not sure what you mean... This reference is related to http://jira.codehaus.org/browse/MNG-3092 in which version range resolution removed -SNAPSHOTs from that resolution. I do see that the commit making this change has been reverted now until a better fix is worked out, so for now the problem is not really a problem anymore. For those that have 1.1/1.2 differences, if you went the route of having -two- artifacts for the various versions, you could declare the dependency -and- the version of clojure. Or is the plan to support both versions from the same artifact? Not sure I understand. But basically, the end user controls the transitive dependencies. Your artifacts can't do that. So if he wants to use version A of Clojure, he can do that regardless of the version of your artifacts he's using (it might not work though). Would it make sense to use an older From my understanding of the clojure-contrib library, there's currently two project trees for clojure 1.1.0 and 1.2.0 - which differ where there are incompatibles in clojure library versions. For these modules - the users choice is the 1.1.0 version or the 1.2.0 version, rather than which version of clojure to include. Given Stuarts mentioned 61 sub modules, I'd hate to thinking of duplicating all 61 for 1.1.0 and 1.2.0.
Re: Release version numbers in large multi-module project
On 21/09/2010 3:51 PM, Stuart Sierra wrote: On Tue, Sep 21, 2010 at 7:32 AM, Mark Derricuttm...@talios.com wrote: Neat :) Is the plan here to have 61 individual releases/version numbers or a single release for the entire collection? 61 individual versions was my original plan, but now I'm balking at the complexity of that. I'm open to suggestions for a reasonable solution. :) -S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org We started out with a single release but gave it up as being too much work since most of our modules did not change from release to release since we are releasing fairly often and the functional changes are reasonably confined. We have about 60 modules as well and a team of just 3 people. We made a control sheet with all of the modules and do a preliminary plan at the start of development of a new release to identify the modules that change and the ones that will not. This is never perfect but we keep it up to date as we go along and does give us a document of the versions of each module making up the release. We also have separated out the core and the API for the core into separate projects and they always change. If you aim for upward compatibility in your core libraries and APIs, then you tend to minimize the number of modules that have to change. We are also moving to a service oriented architecture using web services which also improves stability of the view parts of the application. In our current release that will go into production this week, only 8 of the 60 modules have new version numbers and require building. Three of the 8 are the core modules and the aggregation jar that includes the core and our utility libraries. Two are web services and the other 3 are WAR files that implement portlets. This is not a major release but does add 1 major new function, a new small portlet and fixes 4 or 5 bugs. I hope that this helps. Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release version numbers in large multi-module project
On Tue, Sep 21, 2010 at 4:12 PM, Mark Derricutt m...@talios.com wrote: From my understanding of the clojure-contrib library, there's currently two project trees for clojure 1.1.0 and 1.2.0 - which differ where there are incompatibles in clojure library versions. Not really. There are branches (pre-modularization) named 1.1.x and 1.2.x, but nobody develops on them. Current master is at 1.3.0-SNAPSHOT for all modules. I'm expecting that most modules will *not* have new releases after 1.3.0. In fact, I suspect many of them have been abandoned. -S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Release version numbers in large multi-module project
Hello, Maveners, I'm managing the build for clojure-contrib, a diverse collection of libraries for the Clojure programming language. After several releases as a monolithic JAR, I nudged ;-) the community into a multi-module build. Now I have 61 sub-modules, all depending on a single parent module that defines the dependency on Clojure itself. Here's the catch: most modules will work with any version of Clojure; the user of the module should be able to choose. I want the parent module to have a dependency on Clojure with a range like [1.0.0,2.0.0). Aside from maven-release-plugin complaining about SNAPSHOT dependencies, are there any negative implications to doing this? Or am I doing it wrong, should I be using some other mechanism to manage this type of dependency? Thanks, -S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release version numbers in large multi-module project
The user of the module can always control this through a dependencyManagemet section. That's how it should be done. Ranges have all sorts of strange impact, IMO. One would be that your (and the user's) builds are not necessarily reproducable; the outcome might change should a new version of clojure be released. I strongly argue that you should declare a dependency to a specific version (likely the latest available) and let the end user handle any change to this. /Anders On Tue, Sep 21, 2010 at 02:21, Stuart Sierra m...@stuartsierra.com wrote: Hello, Maveners, I'm managing the build for clojure-contrib, a diverse collection of libraries for the Clojure programming language. After several releases as a monolithic JAR, I nudged ;-) the community into a multi-module build. Now I have 61 sub-modules, all depending on a single parent module that defines the dependency on Clojure itself. Here's the catch: most modules will work with any version of Clojure; the user of the module should be able to choose. I want the parent module to have a dependency on Clojure with a range like [1.0.0,2.0.0). Aside from maven-release-plugin complaining about SNAPSHOT dependencies, are there any negative implications to doing this? Or am I doing it wrong, should I be using some other mechanism to manage this type of dependency? Thanks, -S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-release-plugin: Accessing version numbers from custom mojos during a preparationGoal/ run goal
Hey all, I'm wanting to write a mojo to run as part of my release process ( by declaring it in the preparationGoals/ element of the release plugin, but I want to know the release version, and the next-release version as used by the release plugin. Are these values stored in any system parameters at all? It doesn't look like they're stored in the release.properties file and even if they were, I don't like the idea of just assuming this file will exist. Any pointers? -- Pull me down under...
Re: maven-release-plugin: Accessing version numbers from custom mojos during a preparationGoal/ run goal
On 06/08/2010, at 9:12 PM, Mark Derricutt wrote:
Hey all,
I'm wanting to write a mojo to run as part of my release process ( by
declaring it in the preparationGoals/ element of the release plugin, but I
want to know the release version, and the next-release version as used by
the release plugin.
The release version will be ${project.version} at that point.
Are these values stored in any system parameters at all? It doesn't look
like they're stored in the release.properties file and even if they were, I
don't like the idea of just assuming this file will exist.
Not in sys properties, but I would have thought they were in release.properties
(probably several of them, per module). I'm not sure why you wouldn't be
comfortable reading that since it has to be there (it's certainly an
implementation leak, but not one that seems likely to change).
Other than that, I think you'd need to change the release plugin to pass them
to the preparation goals as a system property (though again there's the
difficulty of potentially not being the same for every module).
- Brett
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Version numbers and milestones
Hi, I am in doubt regarding what version numbers I should use for my product. There are two schemes I can think of right now: 1) 1.0-m1-SNAPSHOT - 1.0-m1 - 1.0-m2-SNAPSHOT - 1.0-m2 - 1.0-rc1-SNAPSHOT - 1.0-rc1 ... 2) 1.0-SNAPSHOT - 1.0-m1 - 1.0-SNAPSHOT - 1.0-m2 - 1.0-SNAPSHOT - 1.0-rc1 ... If I use the first solution, I can always tell by looking at even the SNAPSHOT version numbers what milestone we are getting towards. However, if I use the second version, my other products that depend on this product won't need to upgrade every time there is a new milestone release. This is a high maintenance, error-prone task that I would like to avoid. What do you suggest? -- Thanks, Lóránt - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version numbers and milestones
Hello. In my projects I use second variant. It's makes only one trouble for me, when I have to remember the name of the last milestone version I have released already and what will be the next :) By my logic, you always develop snapshot of version 1.0 (for example). Not 1.0-m1, not 1.0-m2. You don't know exactly how many milestones you will have. May be you will need to release 1.0-m1-2, or 1.0-m1-fix. As to me, this product won't need to upgrade every time there is a new milestone release. more important then, I can always tell by looking at even the SNAPSHOT version numbers what milestone we are getting towards. Best regards, Aleksey. 23.03.2010 13:21, Lóránt Pintér пишет: Hi, I am in doubt regarding what version numbers I should use for my product. There are two schemes I can think of right now: 1) 1.0-m1-SNAPSHOT - 1.0-m1 - 1.0-m2-SNAPSHOT - 1.0-m2 - 1.0-rc1-SNAPSHOT - 1.0-rc1 ... 2) 1.0-SNAPSHOT - 1.0-m1 - 1.0-SNAPSHOT - 1.0-m2 - 1.0-SNAPSHOT - 1.0-rc1 ... If I use the first solution, I can always tell by looking at even the SNAPSHOT version numbers what milestone we are getting towards. However, if I use the second version, my other products that depend on this product won't need to upgrade every time there is a new milestone release. This is a high maintenance, error-prone task that I would like to avoid. What do you suggest? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version numbers and milestones
Thanks, this is what I was thinking, too. Can I also get an official nod that this won't backfire at some point which I cannot think about right now, please? Lóránt On Tue, Mar 23, 2010 at 10:40, Aleksey Didik di...@magenta-technology.ru wrote: Hello. In my projects I use second variant. It's makes only one trouble for me, when I have to remember the name of the last milestone version I have released already and what will be the next :) By my logic, you always develop snapshot of version 1.0 (for example). Not 1.0-m1, not 1.0-m2. You don't know exactly how many milestones you will have. May be you will need to release 1.0-m1-2, or 1.0-m1-fix. As to me, this product won't need to upgrade every time there is a new milestone release. more important then, I can always tell by looking at even the SNAPSHOT version numbers what milestone we are getting towards. Best regards, Aleksey. 23.03.2010 13:21, Lóránt Pintér пишет: Hi, I am in doubt regarding what version numbers I should use for my product. There are two schemes I can think of right now: 1) 1.0-m1-SNAPSHOT - 1.0-m1 - 1.0-m2-SNAPSHOT - 1.0-m2 - 1.0-rc1-SNAPSHOT - 1.0-rc1 ... 2) 1.0-SNAPSHOT - 1.0-m1 - 1.0-SNAPSHOT - 1.0-m2 - 1.0-SNAPSHOT - 1.0-rc1 ... If I use the first solution, I can always tell by looking at even the SNAPSHOT version numbers what milestone we are getting towards. However, if I use the second version, my other products that depend on this product won't need to upgrade every time there is a new milestone release. This is a high maintenance, error-prone task that I would like to avoid. What do you suggest? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version numbers and milestones
Hi Lóránt, Lóránt Pintér wrote at Dienstag, 23. März 2010 10:21: Hi, I am in doubt regarding what version numbers I should use for my product. There are two schemes I can think of right now: 1) 1.0-m1-SNAPSHOT - 1.0-m1 - 1.0-m2-SNAPSHOT - 1.0-m2 - 1.0-rc1-SNAPSHOT - 1.0-rc1 ... 2) 1.0-SNAPSHOT - 1.0-m1 - 1.0-SNAPSHOT - 1.0-m2 - 1.0-SNAPSHOT - 1.0-rc1 ... If I use the first solution, I can always tell by looking at even the SNAPSHOT version numbers what milestone we are getting towards. However, if I use the second version, my other products that depend on this product won't need to upgrade every time there is a new milestone release. This is a high maintenance, error-prone task that I would like to avoid. What do you suggest? Definitely 1, because 1.0-SNAPSHOT is *always* the lowest version in this scenario: 1.0-SNAPSHOT 1.0-rc1 1.0-rc2 1.0 1.0.1 i.e. the dependency resolution of Maven will never pick the SNAPSHOT if you have the artifact in your transitive deps one time with the SNAPSHOT and one time with a released version. Background: http://jira.codehaus.org/browse/MNG-2323 - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version numbers and milestones
At this point I cannot see why I would mix SNAPSHOT and final versions of my artifacts as dependencies. (This is a standalone product, the only things depending on it are our tools that create test databases etc.) Apart from this, is there any danger in using the 2) scheme, i.e. always having 1.0-SNAPSHOT as the development version? Also, if I want to release my milestone versions, what is the best way to name them? Options that spring to mind: 1) 1.0-m1, 1.0-rc1 2) 1.0-M1, 1.0-RC1 3) 1.0.m1, 1.0.rc1 4) 1.0.M1, 1.0.RC1 And what shall I call the final version? 1.0? or 1.0.GA? How is Maven going to decide which is the never? Is it important? Lóránt On Tue, Mar 23, 2010 at 11:43, Jörg Schaible joerg.schai...@gmx.de wrote: Hi Lóránt, Lóránt Pintér wrote at Dienstag, 23. März 2010 10:21: Hi, I am in doubt regarding what version numbers I should use for my product. There are two schemes I can think of right now: 1) 1.0-m1-SNAPSHOT - 1.0-m1 - 1.0-m2-SNAPSHOT - 1.0-m2 - 1.0-rc1-SNAPSHOT - 1.0-rc1 ... 2) 1.0-SNAPSHOT - 1.0-m1 - 1.0-SNAPSHOT - 1.0-m2 - 1.0-SNAPSHOT - 1.0-rc1 ... If I use the first solution, I can always tell by looking at even the SNAPSHOT version numbers what milestone we are getting towards. However, if I use the second version, my other products that depend on this product won't need to upgrade every time there is a new milestone release. This is a high maintenance, error-prone task that I would like to avoid. What do you suggest? Definitely 1, because 1.0-SNAPSHOT is *always* the lowest version in this scenario: 1.0-SNAPSHOT 1.0-rc1 1.0-rc2 1.0 1.0.1 i.e. the dependency resolution of Maven will never pick the SNAPSHOT if you have the artifact in your transitive deps one time with the SNAPSHOT and one time with a released version. Background: http://jira.codehaus.org/browse/MNG-2323 - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version numbers and milestones
Another question: what should be service releases be called? 1.0.sr1? 1.0-sr1? 1.0.1? Lóránt 2010/3/23 Lóránt Pintér lorant.pin...@gmail.com: At this point I cannot see why I would mix SNAPSHOT and final versions of my artifacts as dependencies. (This is a standalone product, the only things depending on it are our tools that create test databases etc.) Apart from this, is there any danger in using the 2) scheme, i.e. always having 1.0-SNAPSHOT as the development version? Also, if I want to release my milestone versions, what is the best way to name them? Options that spring to mind: 1) 1.0-m1, 1.0-rc1 2) 1.0-M1, 1.0-RC1 3) 1.0.m1, 1.0.rc1 4) 1.0.M1, 1.0.RC1 And what shall I call the final version? 1.0? or 1.0.GA? How is Maven going to decide which is the never? Is it important? Lóránt On Tue, Mar 23, 2010 at 11:43, Jörg Schaible joerg.schai...@gmx.de wrote: Hi Lóránt, Lóránt Pintér wrote at Dienstag, 23. März 2010 10:21: Hi, I am in doubt regarding what version numbers I should use for my product. There are two schemes I can think of right now: 1) 1.0-m1-SNAPSHOT - 1.0-m1 - 1.0-m2-SNAPSHOT - 1.0-m2 - 1.0-rc1-SNAPSHOT - 1.0-rc1 ... 2) 1.0-SNAPSHOT - 1.0-m1 - 1.0-SNAPSHOT - 1.0-m2 - 1.0-SNAPSHOT - 1.0-rc1 ... If I use the first solution, I can always tell by looking at even the SNAPSHOT version numbers what milestone we are getting towards. However, if I use the second version, my other products that depend on this product won't need to upgrade every time there is a new milestone release. This is a high maintenance, error-prone task that I would like to avoid. What do you suggest? Definitely 1, because 1.0-SNAPSHOT is *always* the lowest version in this scenario: 1.0-SNAPSHOT 1.0-rc1 1.0-rc2 1.0 1.0.1 i.e. the dependency resolution of Maven will never pick the SNAPSHOT if you have the artifact in your transitive deps one time with the SNAPSHOT and one time with a released version. Background: http://jira.codehaus.org/browse/MNG-2323 - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Subject: Adding version numbers to artifacts
Thanks, Anders. I guess you could call it a nightly release. The version
numbering scheme is major.minor.patch.build, so while working on a given
version, the build component would increase each night.
I looked at the release plugin, but it appears to require some manual
involvement, and I'd like this process to be completely automated. Also, it
tags the sources in scm, but our build server already handles that part.
I will take a look a the plugin's source, though, to see if makes sense to
base a custom plugin off of it, or if I'm missing something in how it is
used.
Jeff
Anders Hammar wrote:
Looks to me that what you're doing is a release build, not a nightly build
(at least not what I associate with the nightly build expression. You
should take a look at the release plugin:
http://maven.apache.org/plugins/maven-release-plugin/
It will release your project including updating the version correctly and
set a label in your scm.
/Anders
On Wed, Nov 25, 2009 at 05:29, Jeff French j...@mdbconsulting.com wrote:
I'm trying to replicate our Maven-1 nightly build/deploy process with
Maven-2. Basically, a build server passes the current version to a maven
process that then produces artifacts with that version number appended.
Since the build occurs on the same machine as the repo, I'm guessing I
can
perform an 'install' instead of a 'deploy'. I've found that this:
mvn -Dversion=1.1.1 install
will produce numbered artifacts if the pom contains these snippets:
project
...
version${version}/version
properties
version1.1-SNAPSHOT/version
/properties
...
/project
The problem is the reposed .pom files contain the ${version} string
instead
of the defined version (1.1.1). Is there any way for the deployed pom to
be
the result of filtering the build pom with the defined system property?
Or
more importantly, is there a better way to go about what I'm trying to
achieve?
Thanks for any pointers.
Jeff
--
View this message in context:
http://old.nabble.com/Subject%3A-Adding-version-numbers-to-artifacts-tp26507407p26512100.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Subject: Adding version numbers to artifacts
Relase plugin batch mode:
http://maven.apache.org/plugins/maven-release-plugin/examples/non-interactive-release.html
/Anders
On Wed, Nov 25, 2009 at 13:52, Jeff French j...@mdbconsulting.com wrote:
Thanks, Anders. I guess you could call it a nightly release. The version
numbering scheme is major.minor.patch.build, so while working on a given
version, the build component would increase each night.
I looked at the release plugin, but it appears to require some manual
involvement, and I'd like this process to be completely automated. Also, it
tags the sources in scm, but our build server already handles that part.
I will take a look a the plugin's source, though, to see if makes sense to
base a custom plugin off of it, or if I'm missing something in how it is
used.
Jeff
Anders Hammar wrote:
Looks to me that what you're doing is a release build, not a nightly
build
(at least not what I associate with the nightly build expression. You
should take a look at the release plugin:
http://maven.apache.org/plugins/maven-release-plugin/
It will release your project including updating the version correctly and
set a label in your scm.
/Anders
On Wed, Nov 25, 2009 at 05:29, Jeff French j...@mdbconsulting.com
wrote:
I'm trying to replicate our Maven-1 nightly build/deploy process with
Maven-2. Basically, a build server passes the current version to a maven
process that then produces artifacts with that version number appended.
Since the build occurs on the same machine as the repo, I'm guessing I
can
perform an 'install' instead of a 'deploy'. I've found that this:
mvn -Dversion=1.1.1 install
will produce numbered artifacts if the pom contains these snippets:
project
...
version${version}/version
properties
version1.1-SNAPSHOT/version
/properties
...
/project
The problem is the reposed .pom files contain the ${version} string
instead
of the defined version (1.1.1). Is there any way for the deployed pom to
be
the result of filtering the build pom with the defined system property?
Or
more importantly, is there a better way to go about what I'm trying to
achieve?
Thanks for any pointers.
Jeff
--
View this message in context:
http://old.nabble.com/Subject%3A-Adding-version-numbers-to-artifacts-tp26507407p26512100.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Subject: Adding version numbers to artifacts
I'm trying to replicate our Maven-1 nightly build/deploy process with
Maven-2. Basically, a build server passes the current version to a maven
process that then produces artifacts with that version number appended.
Since the build occurs on the same machine as the repo, I'm guessing I can
perform an 'install' instead of a 'deploy'. I've found that this:
mvn -Dversion=1.1.1 install
will produce numbered artifacts if the pom contains these snippets:
project
...
version${version}/version
properties
version1.1-SNAPSHOT/version
/properties
...
/project
The problem is the reposed .pom files contain the ${version} string instead
of the defined version (1.1.1). Is there any way for the deployed pom to be
the result of filtering the build pom with the defined system property? Or
more importantly, is there a better way to go about what I'm trying to
achieve?
Thanks for any pointers.
Jeff
--
View this message in context:
http://old.nabble.com/Subject%3A-Adding-version-numbers-to-artifacts-tp26507407p26507407.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Subject: Adding version numbers to artifacts
Looks to me that what you're doing is a release build, not a nightly build
(at least not what I associate with the nightly build expression. You
should take a look at the release plugin:
http://maven.apache.org/plugins/maven-release-plugin/
It will release your project including updating the version correctly and
set a label in your scm.
/Anders
On Wed, Nov 25, 2009 at 05:29, Jeff French j...@mdbconsulting.com wrote:
I'm trying to replicate our Maven-1 nightly build/deploy process with
Maven-2. Basically, a build server passes the current version to a maven
process that then produces artifacts with that version number appended.
Since the build occurs on the same machine as the repo, I'm guessing I can
perform an 'install' instead of a 'deploy'. I've found that this:
mvn -Dversion=1.1.1 install
will produce numbered artifacts if the pom contains these snippets:
project
...
version${version}/version
properties
version1.1-SNAPSHOT/version
/properties
...
/project
The problem is the reposed .pom files contain the ${version} string instead
of the defined version (1.1.1). Is there any way for the deployed pom to be
the result of filtering the build pom with the defined system property? Or
more importantly, is there a better way to go about what I'm trying to
achieve?
Thanks for any pointers.
Jeff
--
View this message in context:
http://old.nabble.com/Subject%3A-Adding-version-numbers-to-artifacts-tp26507407p26507407.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: ejb manifest -- strip version numbers of dependencies
You could have a go with the 2.2-SNAPSHOT version of the plugin. That
version has an updated version of Maven Archiver, which is the component
that handles everything you put into the archive configuration.
Michael Hüttermann wrote:
Hello,
I create an EJB and want to cut off the version numbers of my dependencies
which are put into my manifest. I tried the following but it does not work
.. the message is Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-ejb-plugin:2.1. How can I cut off the
version numbers? Thank you !!
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ejb-plugin/artifactId
configuration
ejbVersion2.1/ejbVersion
generateClientfalse/generateClient
archive
manifest
addClasspathtrue/addClasspath
classpathLayoutTypecustom/classpathLayoutType
customClasspathLayout${artifact.artifactId}/customClasspathLayout
/manifest
/archive
/configuration
/plugin
Michael
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Dennis Lundberg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: ejb manifest -- strip version numbers of dependencies
You could have a go with the 2.2-SNAPSHOT version of the plugin. That
version has an updated version of Maven Archiver, which is the component
that handles everything you put into the archive configuration.
Michael Hüttermann wrote:
Hello,
I create an EJB and want to cut off the version numbers of my dependencies
which are put into my manifest. I tried the following but it does not work
.. the message is Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-ejb-plugin:2.1. How can I cut off the
version numbers? Thank you !!
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ejb-plugin/artifactId
configuration
ejbVersion2.1/ejbVersion
generateClientfalse/generateClient
archive
manifest
addClasspathtrue/addClasspath
classpathLayoutTypecustom/classpathLayoutType
customClasspathLayout${artifact.artifactId}/customClasspathLayout
/manifest
/archive
/configuration
/plugin
Michael
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Dennis Lundberg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
ejb manifest -- strip version numbers of dependencies
Hello,
I create an EJB and want to cut off the version numbers of my dependencies
which are put into my manifest. I tried the following but it does not work
.. the message is Failed to configure plugin parameters for:
org.apache.maven.plugins:maven-ejb-plugin:2.1. How can I cut off the
version numbers? Thank you !!
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ejb-plugin/artifactId
configuration
ejbVersion2.1/ejbVersion
generateClientfalse/generateClient
archive
manifest
addClasspathtrue/addClasspath
classpathLayoutTypecustom/classpathLayoutType
customClasspathLayout${artifact.artifactId}/customClasspathLayout
/manifest
/archive
/configuration
/plugin
Michael
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
Sure, you can do this by setting a version number to 'RELEASE' to get the latest non-snapshot, but IMHO it's a bad practice in general. In any dev You can also do similar things with version ranges eg [1,2) means version greater than 1 but less than 2. If you are making serious (breaking) changes to your library, you should bump the major version number. Then instead of simply using RELEASE, you use [1,2). Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
Dave Newton wrote: In other words, use the maven-release-plugin to publish formal releases of code, and make sure that project A never depends on a snapshot of project B if you can possibly avoid it. Use proper version numbers. Would it be reasonable to say that *released* versions of A shouldn't depend on B-snapshots? Yes - the release plugin will enforce this for you. The release plugin will refuse to continue with a release if any component of that release is a snapshot. This is because, by definition, if one of the components in a snapshot, then all bets are off for the entire release. A reminder of why this matters: It's 3am, your production server shows a bug. You want to rebuild the code on your dev environment so that you can recreate the bug, and fix it. But your build depends on a snapshot, so when you rebuild the code, you don't end up with the same code as the code in production. As a result, you cannot reproduce the bug, and your troubleshooter climbs the clock tower with a rifle. Then, after coaxing your troubleshooter down from the clock tower, they stumble on the fix, and they attempt to put a fixed version of the code back into production. But again, you could not repeat your build, so you cannot put your fix - and *only* your fix - into production, so you now have new bugs. Your troubleshooter goes back up the clock tower. If you get your developers to respect the release plugin, the side effect is that troubleshooting becomes an order of magnitude easier. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
Rick wrote: Here's what I'm confused at though. Project A builds a jar. It needs to be used in Project B. Ideally of course Project A should be tested in Project B locally, but in reality (unfortunately) the dev environment often becomes a more 'real' test. Typically the developers of Project A will have access to Project B, so can't they just set up the dev profile of Project B, to use the latest stable version? This way they won't have to constantly be changing the profile for Project B.. or is that a bad practice? Assuming some time goes by while they do more 'real life' stuff in dev and they like how things are. They could then change the version of the dependency of Project A to a set number and then check that updated pom/profile into version control. This is up to you. The core thing to understand is snapshots equals all bets are off. If project B wants to live on the bleeding edge of project A, and early on in development this is likely, project B is free to depend on snapshots of project A. But by doing this, project B is saying we accept that project A may break at any time, and we accept this. Over time, when development starts to settle down, project B will start wanting stability and a goalpost that doesn't move. At that point, project B will start depending on releases of project A. There is no right answer as to when this should happen, this is up to the development team. But it is down to a binary choice: be on the snapshot bleeding edge and access changes quickly and accept that it will break randomly and without warning, or depend on a release, and you get stability and controlled change. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
Graham Leggett wrote: But by doing this, project B is saying we accept that project A may break at any time, and we accept this. ... There is no right answer as to when this should happen, this is up to the development team. But it is down to a binary choice: be on the snapshot bleeding edge and access changes quickly and accept that it will break randomly and without warning, or depend on a release, and you get stability and controlled change. Our single organisational project has a large number of modules. While adding single features (during Agile sprints) we change stuff in multiple such modules. Having a snapshot dependency from A on B when making corresponding changes between the two, for a single feature, some would argue this to be true Continuous Integration (thus: a good thing). In our environment we're for the moment happy with that. B and A are released shortly after each other (in that order), no problem. In our environment the real problems occur when A has a dependency on C as well, and A and C are both involved in another, concurrent feature as well. We've not yet found a very satisfying procedure for that one... anyone? ;-) -- View this message in context: http://www.nabble.com/newbie%3A-understanding-how-teams-deal-with-version-numbers-on-dependencies-%28Best-practices%29--tp19473528p19480432.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
You might want to either have a look at the versions-maven-plugin or consider version ranges. With the versions-maven-plugin you can update a property that locks down the version you use automatically, which can be helpful in controlling when you get an update in your dependency. If you just always want the latest, you can use version ranges. If you make it a rule to never deploy -SNAPSHOT artifacts you can then limit the exposure to the bleeding edge by the very separation of developers. i.e. If I am working on A B and I do an mvn install of A 1.0.5-SNAPSHOT and B depends on A. versions-maven-plugin can be configured to see the 1.0.5-SNAPSHOT on my machine and thus I can see both dev versions. You are only working on B, so you will only see 1.0.4 until 1.0.5 is released. The same can be achieved with version ranges but I'm never quite sure how ranges work with -SNAPSHOT's being the latest i.e. is [1.0.0,) going to include 1.0.5-SNAPSHOT? -Stephen On Sun, Sep 14, 2008 at 2:41 PM, sverhagen [EMAIL PROTECTED] wrote: Graham Leggett wrote: But by doing this, project B is saying we accept that project A may break at any time, and we accept this. ... There is no right answer as to when this should happen, this is up to the development team. But it is down to a binary choice: be on the snapshot bleeding edge and access changes quickly and accept that it will break randomly and without warning, or depend on a release, and you get stability and controlled change. Our single organisational project has a large number of modules. While adding single features (during Agile sprints) we change stuff in multiple such modules. Having a snapshot dependency from A on B when making corresponding changes between the two, for a single feature, some would argue this to be true Continuous Integration (thus: a good thing). In our environment we're for the moment happy with that. B and A are released shortly after each other (in that order), no problem. In our environment the real problems occur when A has a dependency on C as well, and A and C are both involved in another, concurrent feature as well. We've not yet found a very satisfying procedure for that one... anyone? ;-) -- View this message in context: http://www.nabble.com/newbie%3A-understanding-how-teams-deal-with-version-numbers-on-dependencies-%28Best-practices%29--tp19473528p19480432.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
This isn't in reply to Stephen directly since so many people have made good points.. so thanks. I guess I'm still wonder what most people practice (or maybe not most but what's considered 'good'), in regard to the following situation... Project B will be putting out a new release based on features in Project A that Project B depends on. Project A works on their jar, runs some tests, runs things the best they can locally and then needs to have it deployed as part of the web app (Project B) so that some others in the company can look at it and examine the features etc. Later that day it's realized Project A jar needs to be modified again. So again a new version needs to go out to Project B in dev. This cycle sometimes happens quite rapidly towards the end of the development cycle. My question is Are these quick releases typically release versions or snapshots? To me, they seem to be snapshots, but I suppose in theory they could be considered releases with minor bug/enhancement features. It would be somewhat nice during this rapid development cycle that the version declaration in Project B would have to keep being changed. It seems like a decent(?) approach (possibly alluded to by what I've been piecing together in this thread), is that during this busy dev time it would be ok to change Project B's pom dependency on Project A to something like SNAPSHOT or latest release. THEN, after things settle down abit, someone makes the cool to clamp down on the dev version number dependency on Project B. I think this might be a safe approach during the time period when Project B is getting close to being 'ready' for its release to Test based on the work done by Project A. Like others have pointed out, it would then be a bad idea (I agree) to just leave the dev version of Project B to depend on snapshot of Project A. Thanks again for all the good comments so far. On Sun, Sep 14, 2008 at 10:07 AM, Stephen Connolly [EMAIL PROTECTED] wrote: You might want to either have a look at the versions-maven-plugin or consider version ranges. With the versions-maven-plugin you can update a property that locks down the version you use automatically, which can be helpful in controlling when you get an update in your dependency. If you just always want the latest, you can use version ranges. If you make it a rule to never deploy -SNAPSHOT artifacts you can then limit the exposure to the bleeding edge by the very separation of developers. i.e. If I am working on A B and I do an mvn install of A 1.0.5-SNAPSHOT and B depends on A. versions-maven-plugin can be configured to see the 1.0.5-SNAPSHOT on my machine and thus I can see both dev versions. You are only working on B, so you will only see 1.0.4 until 1.0.5 is released. The same can be achieved with version ranges but I'm never quite sure how ranges work with -SNAPSHOT's being the latest i.e. is [1.0.0,) going to include 1.0.5-SNAPSHOT? -Stephen On Sun, Sep 14, 2008 at 2:41 PM, sverhagen [EMAIL PROTECTED] wrote: Graham Leggett wrote: But by doing this, project B is saying we accept that project A may break at any time, and we accept this. ... There is no right answer as to when this should happen, this is up to the development team. But it is down to a binary choice: be on the snapshot bleeding edge and access changes quickly and accept that it will break randomly and without warning, or depend on a release, and you get stability and controlled change. Our single organisational project has a large number of modules. While adding single features (during Agile sprints) we change stuff in multiple such modules. Having a snapshot dependency from A on B when making corresponding changes between the two, for a single feature, some would argue this to be true Continuous Integration (thus: a good thing). In our environment we're for the moment happy with that. B and A are released shortly after each other (in that order), no problem. In our environment the real problems occur when A has a dependency on C as well, and A and C are both involved in another, concurrent feature as well. We've not yet found a very satisfying procedure for that one... anyone? ;-) -- View this message in context: http://www.nabble.com/newbie%3A-understanding-how-teams-deal-with-version-numbers-on-dependencies-%28Best-practices%29--tp19473528p19480432.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
Rick wrote: Is it common for the development environment to rely on company snapshot versions and only in test or later, to define specific version numbers? I seem weary though to have for example project B rely on the snapshot version of project A. Maybe project A is working on a release that won't break project B, but it's still a release that project B wouldn't necessarily want (especially if they haven't been communicating with each other. For example maybe project A is changing the way a calculation is done, but project B still wants the calc to stay the old way for now. If they are relying on snapshots, they might not be aware that the change was even made.) You are describing a recipe for disaster - use proper release management, and you will be fine. In other words, use the maven-release-plugin to publish formal releases of code, and make sure that project A never depends on a snapshot of project B if you can possibly avoid it. Use proper version numbers. snapshot is another way of saying all bets are off, and I cannot stress this enough: if project B depends on snapshots from project A, project B is saying we accept that our code will break with no warning and for no clear reason because of project A, and it will be our own fault. Get your projects to release often, and you will minimise the need for people to depend on snapshots. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
--- On Sat, 9/13/08, Graham Leggett wrote: In other words, use the maven-release-plugin to publish formal releases of code, and make sure that project A never depends on a snapshot of project B if you can possibly avoid it. Use proper version numbers. Would it be reasonable to say that *released* versions of A shouldn't depend on B-snapshots? In other words, an A-snapshot may use a B-snapshot, but an A-release should not. Every A-release should depend only on a B-release, even if it means releasing an B-n.n.n+1 tag to fix minor B-release issues. (We're revamping some of our build and release policies, and may be using Maven moving forward, so I'm definitely interested in hearing opinions, best practices, and how others deal with this.) Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
On Sat, Sep 13, 2008 at 4:39 PM, Graham Leggett [EMAIL PROTECTED] wrote: In other words, use the maven-release-plugin to publish formal releases of code, and make sure that project A never depends on a snapshot of project B if you can possibly avoid it. Use proper version numbers. Here's what I'm confused at though. Project A builds a jar. It needs to be used in Project B. Ideally of course Project A should be tested in Project B locally, but in reality (unfortunately) the dev environment often becomes a more 'real' test. Typically the developers of Project A will have access to Project B, so can't they just set up the dev profile of Project B, to use the latest stable version? This way they won't have to constantly be changing the profile for Project B.. or is that a bad practice? Assuming some time goes by while they do more 'real life' stuff in dev and they like how things are. They could then change the version of the dependency of Project A to a set number and then check that updated pom/profile into version control. Are they any documents out there that explain some of these common best practices in company environments? The two books I mentioned 'touch' upon it but don't see give a lot of detail. Understanding this 'process' of how things should be done to me seems critical to have nailed down (even if there are different ways to do it, I'd like to be aware of the typical scenarios corporations use.) Thanks to all for the replies so far. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
On Sat, Sep 13, 2008 at 9:03 PM, Rick [EMAIL PROTECTED] wrote: On Sat, Sep 13, 2008 at 4:39 PM, Graham Leggett [EMAIL PROTECTED] wrote: Here's what I'm confused at though. Project A builds a jar. It needs to be used in Project B. Ideally of course Project A should be tested in Project B locally, but in reality (unfortunately) the dev environment often becomes a more 'real' test. Typically the developers of Project A will have access to Project B, so can't they just set up the dev profile of Project B, to use the latest stable version? This way they won't have to constantly be changing the profile for Project B.. or is that a bad practice? Assuming some time goes by while they Sure, you can do this by setting a version number to 'RELEASE' to get the latest non-snapshot, but IMHO it's a bad practice in general. In any dev environment, there are lot of variables you are trying to control and the last thing you want to do is to slow down the devs by causing unexpected issues with some non-obvious change. About the only environment I could think of doing something like this is a specific continous integration profile where the system runs a test suite against the latest available dependencies *before* the devs move to it, to have a better idea whether it's safe to move to it or not. I think the old truth, if it ain't broken, don't fix it holds true in this case; or if the old version works, don't upgrade. Kalle
Re: Version Numbers with Scrum
I the past I've tried to separate the technical versions from the planning versions. Some projects do this with code names, but we did with release numbers. The CI system gave us build numbers, we didn't know in advance which build would become the release, esp weeks in advance. So when people ask which version is going to contain feature X, or bug fix Y, then we tell them the planned release number (or code name), and then we have a build and we release it, we bind the release number to the build number. Once the project had been running for a long time the separation between the two version numbers wasn't so tight, and it didn't matter as we were much better about planning releases as there was less change. David -- View this message in context: http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19250282.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Version Numbers with Scrum
We have recently switched to the scrum development process, and are forced to rethink our maven versioning scheme. There will be multiple scrum teams working with the same code-base. Each team will aim to have a release each sprint, but occasionally a release will be planned for one sprint but pushed back to the next. Can anyone reccomend a maven versioning scheme that fits the scrum development process well? The first scheme that comes to mind is Development Group Identifier.Sprint Number.Candidate Number. Development Group Identifier: Identifies which scrum team owns the version. Sprint number: Specifies which sprint the code is intended to be released in. This may change if a release gets postponed, for instance a project may be developed as 1.3.0-SNAPSHOT and end up being released in sprint 4 so the release version would be 1.4.0. Candidate number: Each release to QA has a distinct candidate number. If QA rejects the candidate then development works on the next candidate (incrementing number), and releases this candidate to QA when it is ready. This will give QA a permanent version number for each artifact they perform a test cycle on. Thanks for the input -- View this message in context: http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19182915.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Version Numbers with Scrum
We are doing something similar. I am guessing that you are putting the various sprint teams on separate branches and merging them in when you need to create a combined release. Or are you actually producing alternative versions of you product? If the former, then the first blush response might be to use classifiers but that did not work for us because we have several artifacts in each component and are already using classifiers for other purposes. Classifiers also do not allow for the isolation of POM changes. So we decided to use a versioning scheme where each branch had their own moniker added to the version number. Our project is currently at 4.12.0-SNAPSHOT. I am working on a project with the initials tc so my branch is on 4.12.0-tc-SNAPSHOT. When we merge the branches together they become 4.12.0-SNAPSHOT and then we release it as 4.12.0. This allows the development and QA for each project to proceed independently. When we release, we merge everything back to the trunk, deploy everything to an integration environment and smoke test the applications. Then we move the code to a nearly production like environment for final QA. I do not like the idea of using numbers to represent concepts. It makes the version numbers hard to understand and there is nothing in Maven that says your versions have to contain only numbers. -Original Message- From: kroe [mailto:[EMAIL PROTECTED] Sent: Wed 8/27/2008 11:02 AM To: users@maven.apache.org Subject: Version Numbers with Scrum We have recently switched to the scrum development process, and are forced to rethink our maven versioning scheme. There will be multiple scrum teams working with the same code-base. Each team will aim to have a release each sprint, but occasionally a release will be planned for one sprint but pushed back to the next. Can anyone reccomend a maven versioning scheme that fits the scrum development process well? The first scheme that comes to mind is Development Group Identifier.Sprint Number.Candidate Number. Development Group Identifier: Identifies which scrum team owns the version. Sprint number: Specifies which sprint the code is intended to be released in. This may change if a release gets postponed, for instance a project may be developed as 1.3.0-SNAPSHOT and end up being released in sprint 4 so the release version would be 1.4.0. Candidate number: Each release to QA has a distinct candidate number. If QA rejects the candidate then development works on the next candidate (incrementing number), and releases this candidate to QA when it is ready. This will give QA a permanent version number for each artifact they perform a test cycle on. Thanks for the input -- View this message in context: http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19182915.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Version Numbers with Scrum
We have separate working branches for each team. After a version is released it is merged into the trunk. There is only one current production version of each application. Our software is developed for internal use so no need to maintain previous versions. P'Simer, Dana (Matrix) wrote: We are doing something similar. I am guessing that you are putting the various sprint teams on separate branches and merging them in when you need to create a combined release. Or are you actually producing alternative versions of you product? If the former, then the first blush response might be to use classifiers but that did not work for us because we have several artifacts in each component and are already using classifiers for other purposes. Classifiers also do not allow for the isolation of POM changes. So we decided to use a versioning scheme where each branch had their own moniker added to the version number. Our project is currently at 4.12.0-SNAPSHOT. I am working on a project with the initials tc so my branch is on 4.12.0-tc-SNAPSHOT. When we merge the branches together they become 4.12.0-SNAPSHOT and then we release it as 4.12.0. This allows the development and QA for each project to proceed independently. When we release, we merge everything back to the trunk, deploy everything to an integration environment and smoke test the applications. Then we move the code to a nearly production like environment for final QA. I do not like the idea of using numbers to represent concepts. It makes the version numbers hard to understand and there is nothing in Maven that says your versions have to contain only numbers. -Original Message- From: kroe [mailto:[EMAIL PROTECTED] Sent: Wed 8/27/2008 11:02 AM To: users@maven.apache.org Subject: Version Numbers with Scrum We have recently switched to the scrum development process, and are forced to rethink our maven versioning scheme. There will be multiple scrum teams working with the same code-base. Each team will aim to have a release each sprint, but occasionally a release will be planned for one sprint but pushed back to the next. Can anyone reccomend a maven versioning scheme that fits the scrum development process well? The first scheme that comes to mind is Development Group Identifier.Sprint Number.Candidate Number. Development Group Identifier: Identifies which scrum team owns the version. Sprint number: Specifies which sprint the code is intended to be released in. This may change if a release gets postponed, for instance a project may be developed as 1.3.0-SNAPSHOT and end up being released in sprint 4 so the release version would be 1.4.0. Candidate number: Each release to QA has a distinct candidate number. If QA rejects the candidate then development works on the next candidate (incrementing number), and releases this candidate to QA when it is ready. This will give QA a permanent version number for each artifact they perform a test cycle on. Thanks for the input -- View this message in context: http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19182915.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Version-Numbers-with-Scrum-tp19182915p19183363.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using pluginManagement and overriding plugin version numbers
On Sun, Jul 13, 2008 at 2:33 PM, in the [ANN] Maven Site Plugin 2.0-beta-7 Released thread, Dennis Lundberg [EMAIL PROTECTED] wrote: Giovanni Azua wrote: Many thanks! Yes the mvn help:effective-pom shows it is picking up the 2.0-beta-6 under pluginManagement section ... Then you need to override this by putting 2.0-beta-7 under the pluginManagement section in *your* POM. If it's in pluginManagement somewhere up the pom hierarchy, shouldn't specifying a version in plugins work? I'm currently chasing down a similar problem... different plugin, but it seems that pluginManagement further up the hierarchy is picking a version that IMO should be overridden by specifying a version in the project's pom. Somewhat related... AIUI, pluginManagement is ignored by reporting plugins. Has that changed? -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice for handling multi-modules version numbers
Hello again, I am wondering whether my question is: 1. obvious 2. silly 3. too specific :-) Isn't this something that lot of people are coping with everyday ? Is there something I should know about version management in multi-modules build ? I did already some refactoring using dependencyManagement at toplevel to remove duplication of version in dependencies of submodules. But I am still stuck with the issue of having to define 25 times the same version number. Do people mostly use release plugin in those circumstances ? Any feedback greatly appreciated, -- Arnaud Bailly, PhD OQube - Software Engineering http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice for handling multi-modules version numbers
Are you referring to your module versions, or dependency versions?
I user properties spring.versionxyz
then add ${spring.version} to my dependencies in each of my modules.
For my modules, That is just manual labor for me.
On Tue, Jun 24, 2008 at 7:44 AM, Insitu [EMAIL PROTECTED] wrote:
Hello again,
I am wondering whether my question is:
1. obvious
2. silly
3. too specific
:-)
Isn't this something that lot of people are coping with everyday ? Is
there something I should know about version management in
multi-modules build ? I did already some refactoring using
dependencyManagement at toplevel to remove duplication of version in
dependencies of submodules. But I am still stuck with the issue of
having to define 25 times the same version number. Do people mostly
use release plugin in those circumstances ?
Any feedback greatly appreciated,
--
Arnaud Bailly, PhD
OQube - Software Engineering
http://www.oqube.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
---
Thank You…
Mick Knutson
BASE Logic, inc.
(415) 354-4215
Website: http://baselogic.com
Blog: http://baselogic.com/blog
BLiNC Magazine: http://blincmagazine.com
Linked IN: http://linkedin.com/in/mickknutson
DJ Mick: http://djmick.com
MySpace: http://myspace.com/mickknutson
Tahoe: http://tahoe.baselogic.com
RE: Best practice for handling multi-modules version numbers
Mick,
-Original Message-
From: Mick Knutson [mailto:[EMAIL PROTECTED]
Subject: Re: Best practice for handling multi-modules version numbers
Are you referring to your module versions, or dependency versions?
I user properties spring.versionxyz
then add ${spring.version} to my dependencies in each of my modules.
For my modules, That is just manual labor for me.
Why do you add the version property to each of your modules?
We use a parent pom like below, where all the information of a
dependency is added to the dependencyManagement tag:
?xml version=1.0 encoding=UTF-8?
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
groupIdbe.telenet/groupId
artifactIdmain/artifactId
packagingpom/packaging
version1.0-SNAPSHOT/version
nameMain Project/name
dependencyManagement
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version${ver-junit}/version
scopetest/scope
/dependency
/dependencies
/dependencyManagement
properties
ver-junit3.8.1/ver-junit
/properties
/project
In the project POM's, I only use the groupId and artifactId of the
dependency. The rest is resolved via the information in the
dependencyManagement tag of the parent pom:
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdbe.telenet/groupId
artifactIdsomeproject/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
namesomeproject/name
parent
groupIdbe.telenet/groupId
artifactIdmain/artifactId
version1.0-SNAPSHOT/version
/parent
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
/dependency
/dependencies
/project
Works like a charm!
Ringo
*
Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie
bevatten die vertrouwelijk is en/of beschermd door intellectuele
eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n).
Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of
gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen
dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft
ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te
verwijderen.
This e-mail and any attachment thereto may contain information which is
confidential and/or protected by intellectual property rights and are intended
for the sole use of the addressees. Any use of the information contained herein
(including but not limited to total or partial reproduction or distribution in
any form) by other persons than the addressees is prohibited. If you have
received this e-mail in error, please notify the sender and delete its contents.
Ce courriel et les annexes éventuelles peuvent contenir des informations
confidentielles et/ou protégées par des droits de propriété intellectuelle. Ce
message est adressé exclusivement à son (ses) destinataire(s). Toute
utilisation du contenu de ce message (y compris la reproduction ou diffusion
partielle ou complète sous toute forme) par une autre personne que le(s)
destinataire(s) est formellement interdite. Si vous avez reçu ce message par
erreur, veuillez prévenir l'expéditeur du message et en détruire le contenu.
*
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice for handling multi-modules version numbers
Hey Mick,
I have found that what you list under depedencyManagement in parent pom
has to match exactly was is in the module pom. For example if the module
pom contains a packaging tag you have to include that in the parent pom
with the type tag. I ran into this problem with ejbs.
Parent Pom
dependencyManagement
dependencies
dependency
groupIdmyejb/groupId
artifactIdmyejb/artifactId
version1.0/version
typeejb/type
/dependency
/dependencies
/dependencyManagement
Module Pom
dependencies
dependency
groupIdmyejb/groupId
artifactIdmyejb/artifactId
packagingejb/packaging
/dependency
/dependencies
David
On Tue, Jun 24, 2008 at 10:06 AM, Mick Knutson [EMAIL PROTECTED]
wrote:
I have tried that, but some strange unknown reason sometimes, I get version
not found errors on some jars. Random. So I just added it to each of them,
but the property in 1 place and I don't get the errors anymore
On Tue, Jun 24, 2008 at 7:57 AM, De Smet Ringo
[EMAIL PROTECTED] wrote:
Mick,
-Original Message-
From: Mick Knutson [mailto:[EMAIL PROTECTED]
Subject: Re: Best practice for handling multi-modules version numbers
Are you referring to your module versions, or dependency versions?
I user properties spring.versionxyz
then add ${spring.version} to my dependencies in each of my modules.
For my modules, That is just manual labor for me.
Why do you add the version property to each of your modules?
We use a parent pom like below, where all the information of a
dependency is added to the dependencyManagement tag:
?xml version=1.0 encoding=UTF-8?
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
groupIdbe.telenet/groupId
artifactIdmain/artifactId
packagingpom/packaging
version1.0-SNAPSHOT/version
nameMain Project/name
dependencyManagement
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version${ver-junit}/version
scopetest/scope
/dependency
/dependencies
/dependencyManagement
properties
ver-junit3.8.1/ver-junit
/properties
/project
In the project POM's, I only use the groupId and artifactId of the
dependency. The rest is resolved via the information in the
dependencyManagement tag of the parent pom:
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/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdbe.telenet/groupId
artifactIdsomeproject/artifactId
packagingjar/packaging
version1.0-SNAPSHOT/version
namesomeproject/name
parent
groupIdbe.telenet/groupId
artifactIdmain/artifactId
version1.0-SNAPSHOT/version
/parent
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
/dependency
/dependencies
/project
Works like a charm!
Ringo
*
Dit e-mail bericht inclusief eventuele ingesloten bestanden kan
informatie
bevatten die vertrouwelijk is en/of beschermd door intellectuele
eigendomsrechten. Dit bericht is uitsluitend bestemd voor de
geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht
(waaronder de volledige of gedeeltelijke reproductie of verspreiding
onder
elke vorm) door andere personen dan de geadresseerde(n) is verboden.
Indien
u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan
te
verwittigen en dit bericht te verwijderen.
This e-mail and any attachment thereto may contain information which is
confidential and/or protected by intellectual property rights and are
intended for the sole use of the addressees. Any use of the information
contained herein (including but not limited to total or partial
reproduction
or distribution in any form) by other persons than the addressees is
prohibited. If you have received this e-mail in error, please notify the
sender and delete its contents.
Ce courriel et les annexes éventuelles peuvent contenir des informations
confidentielles et/ou protégées par des droits de propriété
intellectuelle.
Ce message est adressé exclusivement à son (ses) destinataire
Best practice for handling multi-modules version numbers
Hello,
I vaguely remember reading a thread a few months ago on this topic, but
could not find it searching nabble.
The question is: how to minize duplication when setting project version
numbers in a multi-module project ? I assume at that time that the version
number should identical for a whole bunch of modules and sub-modules.
I was tempted to do the following:
In the top-level pom:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
parent
groupIdnet.courtanet/groupId
artifactIdBenefit/artifactId
version1.1-SNAPSHOT/version
/parent
groupIdnet.courtanet/groupId
artifactIdmyproject/artifactId
version${myproject.version}/version
properties
myproject.version1.1-SNAPSHOT/myproject.version
/properties
In the modules' poms:
?xml version=1.0 encoding=UTF-8?
project
modelVersion4.0.0/modelVersion
parent
groupIdnet.courtanet/groupId
artifactIdmyproject/artifactId
version${myproject.version}/version
/parent
groupIdnet.courtanet.myproject/groupId
artifactIdmyproject-presentation/artifactId
This works but I had to manually install intermediary pom artifacts. But
once this is done, I can install everything using standard reactor.
I do not feel very comfortable with this solution, because when I change my
version number, I change it in one place, but I need to do some manual
work for things to run smoothly. ANd I guess there may be some unforeseen
traps I may fall in.
I was wondering how other people are managing this ? Of course, when you
decouple version numebres between modules, this is not an issue as you need
to maintain links using concrete version numbers.
Best regards,
Arnaud Bailly
Courtanet
--
View this message in context:
http://www.nabble.com/Best-practice-for-handling-multi-modules-version-numbers-tp18031836p18031836.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Updating version numbers in multiple-POM hierarchy
We have our project constructed using multiple sub-components, each with their own POM, all of which inherit from a common parent POM. When we want to update to the next version, we change the parent POM, and inherit common info into the children. However, we seem to have to update all of the children, individually, to refer to the new version of the parent. Is there a best practices way to do this, other than making a script to do the update? -Marshall Schor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Updating version numbers in multiple-POM hierarchy
On Jan 3, 2008 2:48 PM, Marshall Schor [EMAIL PROTECTED] wrote: We have our project constructed using multiple sub-components, each with their own POM, all of which inherit from a common parent POM. When we want to update to the next version, we change the parent POM, and inherit common info into the children. However, we seem to have to update all of the children, individually, to refer to the new version of the parent. Is there a best practices way to do this, other than making a script to do the update? Hi, you should try using the release feature of Maven : http://maven.apache.org/plugins/maven-release-plugin HTH -- Olivier Jacob Consultant - OCTO Technology 50, avenue des Champs Elysées 75008 Paris
Re: how to change version numbers in multiple pom.xml?
One way is to declare a dependencyManagement [1] element in your parent pom. Another way is to use a property, see [2] for an example. [1] http://maven.apache.org/ref/current/maven-model/maven.html#class_dependencyManagement [2] https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-site-plugin/pom.xml Baz wrote: Joerg, Thanks for your reply. I know I can use release plug-in. What if i am changing dependency version numbers? On 11/12/07, Joerg Hohwiller [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Hi there, What is the recommended methods to change contents (version numbers) version within multiple pom.xml? Is there anything like REXML in RUBY? You can find an experimental approach that might or might not help you: http://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html Thanks. A. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOLYAmPuec2Dcv/8RAm9yAKCSDKnTYiY7erD5XGhRjiYlBYgz3ACfaXpT E2yDhyEM2MorwAO3Z5AaAT4= =BjE6 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
how to change version numbers in multiple pom.xml?
Hi, What is the recommended methods to change contents (version numbers) version within multiple pom.xml? Is there anything like REXML in RUBY? Thanks. A.
Re: how to change version numbers in multiple pom.xml?
Hi, Hi, What is the recommended methods to change contents (version numbers) version within multiple pom.xml? Is there anything like REXML in RUBY? Thanks. A. this is normally achieved using the maven-release-plugin. See the documentation on http://maven.apache.org/plugins/maven-release-plugin The release plugin will request the release version for each pom, create a tag in your scm repository and prepare the poms for the next development iteration. Francois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to change version numbers in multiple pom.xml?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Hi there, What is the recommended methods to change contents (version numbers) version within multiple pom.xml? Is there anything like REXML in RUBY? You can find an experimental approach that might or might not help you: http://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html Thanks. A. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOLYAmPuec2Dcv/8RAm9yAKCSDKnTYiY7erD5XGhRjiYlBYgz3ACfaXpT E2yDhyEM2MorwAO3Z5AaAT4= =BjE6 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to change version numbers in multiple pom.xml?
Joerg, Thanks for your reply. I know I can use release plug-in. What if i am changing dependency version numbers? On 11/12/07, Joerg Hohwiller [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Hi there, What is the recommended methods to change contents (version numbers) version within multiple pom.xml? Is there anything like REXML in RUBY? You can find an experimental approach that might or might not help you: http://maven.apache.org/plugins/maven-dependency-plugin/go-offline-mojo.html Thanks. A. Regards Jörg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOLYAmPuec2Dcv/8RAm9yAKCSDKnTYiY7erD5XGhRjiYlBYgz3ACfaXpT E2yDhyEM2MorwAO3Z5AaAT4= =BjE6 -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Parametrisizing artifact version numbers
Hi!
I tried the release plugin a few months ago and couldn't get it to work for
such a complex setup. If I remember correctly, when I did the
release:prepare stage with -DdryRun=true it worked fine, but when I did it
for real I got some exception... But still, even if I got that to work, I
would still have to manually replace all snapshot dependency versions that
was not part of the current project. Maybe I'll find the time to experiment
a bit today to find out what the error was...
And Yan, I tried your idea to put the properties in settings.xml (via a
profile), but that didn't work either.
/Anders,
- Message from Huang, Yan [EMAIL PROTECTED] on Wed, 12
Sep 2007 12:10:16 -0700 -
To:
Maven Users List users@maven.apache.org
Subject:
RE: Parametrisizing artifact version numbers
It always puzzles me that maven does not resolve the property when
building in the individual module vs. it's able to do so when building
from the parent level. The property is defined in the settings.xml,
should maven pick up and resolve it when building from inside of
individual modules?
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 8:59 AM
To: Maven Users List
Subject: Re: Parametrisizing artifact version numbers
Have you considered the release plugin?
Wayne
On 9/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi!
I'm working on a few different maven projects with several modules in
each.
Most of the modules have dependencies to other modules within the same
project and also to other projects. Since the development in most of
these
projects go in parallell, most of the dependencies are towards
snapshot
versions.
Now, my problem is that when I want to make a release, I have to go
through
30+ poms and replace snapshot versions with the new versions, check in
the
new poms, tag, and then I have to replace the versions to new snapshot
versions... A lot of work, and it's easy to make a mistake.
So, I'm trying to put the version numbers in properties instead, so I
only
have to update the properties of the parent pom in each project.
Here's a few sample poms of two projects, where myotherproject
depends on
myproject:
!-- parent pom for myproject --
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.
groupIdmy.project/groupId
version${my.project.version}/version
artifactIdmyparentpom/artifactId
packagingpom/packaging
modules
modulemyjar/module
/modules
properties
my.project.version1.2-SNAPSHOT/my.project.version
/properties
/project
!-- jar module pom for myproject --
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.
groupIdmy.project/groupId
version${my.project.version}/version
artifactIdmyjar/artifactId
packagingjar/packaging
parent
groupIdmy.project/groupId
artifactIdmyparentpom/artifactId
version${my.project.version}/version
/parent
/project
!-- parent pom for myotherproject --
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.
groupIdmy.other.project/groupId
version${my.other.project.version}/version.
artifactIdmyotherparentpom/artifactId
packagingpom/packaging
modules
modulemyotherjar/module
/modules
properties
my.project.version1.2-SNAPSHOT/my.project.version
my.other.project.version1.1-SNAPSHOT/my.other.project.version
/properties
/project
!-- jar module pom for myotherproject --
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.
groupIdmy.other.project/groupId
version${my.other.project.version}/version.
artifactIdmyotherjar/artifactId}
packagingjar/packaging
parent
groupIdmy.other.project/groupId
artifactIdmyotherparentpom/artifactId
version${my.other.project.version}/version
/parent
dependencies.
dependency.
groupIdmy.project/groupId
artifactIdmyjar/artifactId
Parametrisizing artifact version numbers
Hi!
I'm working on a few different maven projects with several modules in each.
Most of the modules have dependencies to other modules within the same
project and also to other projects. Since the development in most of these
projects go in parallell, most of the dependencies are towards snapshot
versions.
Now, my problem is that when I want to make a release, I have to go through
30+ poms and replace snapshot versions with the new versions, check in the
new poms, tag, and then I have to replace the versions to new snapshot
versions... A lot of work, and it's easy to make a mistake.
So, I'm trying to put the version numbers in properties instead, so I only
have to update the properties of the parent pom in each project.
Here's a few sample poms of two projects, where myotherproject depends on
myproject:
!-- parent pom for myproject --
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.
groupIdmy.project/groupId
version${my.project.version}/version
artifactIdmyparentpom/artifactId
packagingpom/packaging
modules
modulemyjar/module
/modules
properties
my.project.version1.2-SNAPSHOT/my.project.version
/properties
/project
!-- jar module pom for myproject --
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.
groupIdmy.project/groupId
version${my.project.version}/version
artifactIdmyjar/artifactId
packagingjar/packaging
parent
groupIdmy.project/groupId
artifactIdmyparentpom/artifactId
version${my.project.version}/version
/parent
/project
!-- parent pom for myotherproject --
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.
groupIdmy.other.project/groupId
version${my.other.project.version}/version.
artifactIdmyotherparentpom/artifactId
packagingpom/packaging
modules
modulemyotherjar/module
/modules
properties
my.project.version1.2-SNAPSHOT/my.project.version
my.other.project.version1.1-SNAPSHOT/my.other.project.version
/properties
/project
!-- jar module pom for myotherproject --
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.
groupIdmy.other.project/groupId
version${my.other.project.version}/version.
artifactIdmyotherjar/artifactId}
packagingjar/packaging
parent
groupIdmy.other.project/groupId
artifactIdmyotherparentpom/artifactId
version${my.other.project.version}/version
/parent
dependencies.
dependency.
groupIdmy.project/groupId
artifactIdmyjar/artifactId
version${my.project.version}/version
/dependency
/dependencies.
/project
Now, I can succesfully build myproject, but when I build myotherproject I
get this error:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: my.project
ArtifactId: myparentpom
Version: ${my.project.version}
Reason: Unable to download the artifact from any repository
my.project:myparentpom:pom:${my.project.version}
from the specified remote repositories:
central (http://repo1.maven.org/maven2).
When I look into my local repository I can see that the files and
directories of myproject correctly has the 1.2-SNAPSHOT version. But when I
look inside the saved poms in the repo I can see that they still contain
the ${my.project.version} variable, and it seems that maven is unable to
dereference that variable when resolving the dependency.
So, am I missing something here? Do you have any other suggestions on how
to parametrisize the version numbers?
Thanx in advance,
/Anders
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Parametrisizing artifact version numbers
It always puzzles me that maven does not resolve the property when
building in the individual module vs. it's able to do so when building
from the parent level. The property is defined in the settings.xml,
should maven pick up and resolve it when building from inside of
individual modules?
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 12, 2007 8:59 AM
To: Maven Users List
Subject: Re: Parametrisizing artifact version numbers
Have you considered the release plugin?
Wayne
On 9/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi!
I'm working on a few different maven projects with several modules in
each.
Most of the modules have dependencies to other modules within the same
project and also to other projects. Since the development in most of
these
projects go in parallell, most of the dependencies are towards
snapshot
versions.
Now, my problem is that when I want to make a release, I have to go
through
30+ poms and replace snapshot versions with the new versions, check in
the
new poms, tag, and then I have to replace the versions to new snapshot
versions... A lot of work, and it's easy to make a mistake.
So, I'm trying to put the version numbers in properties instead, so I
only
have to update the properties of the parent pom in each project.
Here's a few sample poms of two projects, where myotherproject
depends on
myproject:
!-- parent pom for myproject --
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.
groupIdmy.project/groupId
version${my.project.version}/version
artifactIdmyparentpom/artifactId
packagingpom/packaging
modules
modulemyjar/module
/modules
properties
my.project.version1.2-SNAPSHOT/my.project.version
/properties
/project
!-- jar module pom for myproject --
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.
groupIdmy.project/groupId
version${my.project.version}/version
artifactIdmyjar/artifactId
packagingjar/packaging
parent
groupIdmy.project/groupId
artifactIdmyparentpom/artifactId
version${my.project.version}/version
/parent
/project
!-- parent pom for myotherproject --
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.
groupIdmy.other.project/groupId
version${my.other.project.version}/version.
artifactIdmyotherparentpom/artifactId
packagingpom/packaging
modules
modulemyotherjar/module
/modules
properties
my.project.version1.2-SNAPSHOT/my.project.version
my.other.project.version1.1-SNAPSHOT/my.other.project.version
/properties
/project
!-- jar module pom for myotherproject --
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.
groupIdmy.other.project/groupId
version${my.other.project.version}/version.
artifactIdmyotherjar/artifactId}
packagingjar/packaging
parent
groupIdmy.other.project/groupId
artifactIdmyotherparentpom/artifactId
version${my.other.project.version}/version
/parent
dependencies.
dependency.
groupIdmy.project/groupId
artifactIdmyjar/artifactId
version${my.project.version}/version
/dependency
/dependencies.
/project
Now, I can succesfully build myproject, but when I build
myotherproject I
get this error:
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
GroupId: my.project
ArtifactId: myparentpom
Version: ${my.project.version}
Reason: Unable to download the artifact from any repository
my.project:myparentpom:pom:${my.project.version}
from the specified remote repositories:
central (http://repo1.maven.org/maven2).
When I look into my local repository I can see that the files and
directories of myproject correctly has the 1.2-SNAPSHOT version. But
when I
look inside the saved poms in the repo I can see that they still
contain
Getting manifest files generated without project version numbers
I'm trying to solve the problem where IBM RAD uses project names (and hence jar file references) without version numbers, but Maven creates its jars with version numbers. The main issue I have is with the automatic generation of the Manifest files. If I let Maven generate them, the resulting EAR doesn't work (because of other modules - I can solve the problem in the EAR). If I hardcode my manifest, I'm losing part of the reason I'm using maven in the first place! So I think there are two possible solutions: 1. Convince Maven when generating its Manifest files to exclude the version number from the name of the projects I specify (i.e my modules), or tell it to use the name I want rather than its own. 2. Merging a base manifest file with a generated one - the base one will contain my projects (with my names), and the generated one will have the other dependencies. 3. Hardcoding my Manifest file (yuck!) Anybody else come across this problem? If so, how did you solve it? Regards, Ian Rowlands Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from your computer. Privacy: If you are responding to this email or providing personal information to the SRO for the purposes of one of the Acts it administers, such information is used only for the purpose for which it was collected ( administration of SRO legislation ) and is protected by the Information Privacy Act 2000 and secrecy provisions contained in legislation administered by SRO. It is not disclosed otherwise than in accordance with the law. If you would like a copy of the SRO Privacy Policy please refer to SRO website (www.sro.vic.gov.au) or contact SRO on 9628 0556 and request a copy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extended build version numbers
It's the timestamp version of the snapshot. Maven generate always it when it is deployed to the repository. In your pom you use -SNAPSHOT and maven will find the latest snapshot available in the repo with timestamped version Emmanuel Wojtek Ciesielski a écrit : Hi there, I've noticed that artifacts deployed by continuum server do have extended version number... In the POM file the version specified is 1.0-SNAPSHOT but in the repository I'm getting artifacts like my-module-1.0-20070213.093006-5.jar. It causes that a module from repository handled by continuum is being loaded while a newer module (which is named 1.0-SNAPSHOT) is already deployed to my local repository by local mvn build... Could you suggest what would be a best practice to handle this? I would greatly appreciate any kind of help with this issue... Is this OK that while building project on my local workstation Maven is downloading artefacts from build server, because they have longer (ie. more precise) build id than just 1.0-SNAPSHOT we have locally defined? Give me something, please Wojtek -- Przedluz domene.PL za 75 zł http://link.interia.pl/f1a19
Re: extended build version numbers
Hi there, I've noticed that artifacts deployed by continuum server do have extended version number... In the POM file the version specified is 1.0-SNAPSHOT but in the repository I'm getting artifacts like my-module-1.0-20070213.093006-5.jar. It causes that a module from repository handled by continuum is being loaded while a newer module (which is named 1.0-SNAPSHOT) is already deployed to my local repository by local mvn build... Could you suggest what would be a best practice to handle this? I would greatly appreciate any kind of help with this issue... Is this OK that while building project on my local workstation Maven is downloading artefacts from build server, because they have longer (ie. more precise) build id than just 1.0-SNAPSHOT we have locally defined? Give me something, please Wojtek -- Przedluz domene.PL za 75 zł http://link.interia.pl/f1a19
extended build version numbers
Hi all, I've noticed that artifacts deployed by continuum server do have extended version number... In the POM file the version specified is 1.0-SNAPSHOT but in the repository I'm getting artifacts like my-module-1.0-20070213.093006-5.jar. It causes that a module from repository handled by continuum is being loaded while a newer module (which is named 1.0-SNAPSHOT) is already deployed to my local repository by local mvn build... Could you suggest what would be a best practice to handle this? Thanks in advance, Wojtek -- Posluchaj plyty i wyjedz do Paryza! kliknij http://link.interia.pl/f1a10
RE: integration builds and version numbers
Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: integration builds and version numbers
Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - 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: integration builds and version numbers
I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: integration builds and version numbers
In chapter 7 of the 'better builds with maven' book (downloadable from www.mergere.com) there is a description on how to use the release plugin. The plugin website can be found at http://maven.apache.org/plugins/maven-release-plugin/ Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:14 PM To: Maven Users List Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.4/363 - Release Date: 6/13/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.4/363 - Release Date: 6/13/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: integration builds and version numbers
Its 'release:prepare' and 'release:perform' This is the best guide I know of: http://apollo.ucalgary.ca/tlcprojectswiki/index.php/Public/Project_Versioning_-_Best_Practices - Original Message - From: EJ Ciramella [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Wednesday, June 14, 2006 3:14 PM Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: integration builds and version numbers
Ok - got the pdf, but I'm confused. Does this release plugin need to be configured at the parent or child pom level? What if our scm tool of choose (perforce) requires passwords? -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:26 AM To: Maven Users List Subject: RE: integration builds and version numbers In chapter 7 of the 'better builds with maven' book (downloadable from www.mergere.com) there is a description on how to use the release plugin. The plugin website can be found at http://maven.apache.org/plugins/maven-release-plugin/ Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:14 PM To: Maven Users List Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.4/363 - Release Date: 6/13/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.4/363 - Release Date: 6/13/2006 - 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: integration builds and version numbers
The website mentioned by Kieran Brady shows how you can store the scm passwords. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:40 PM To: Maven Users List Subject: RE: integration builds and version numbers Ok - got the pdf, but I'm confused. Does this release plugin need to be configured at the parent or child pom level? What if our scm tool of choose (perforce) requires passwords? -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:26 AM To: Maven Users List Subject: RE: integration builds and version numbers In chapter 7 of the 'better builds with maven' book (downloadable from www.mergere.com) there is a description on how to use the release plugin. The plugin website can be found at http://maven.apache.org/plugins/maven-release-plugin/ Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:14 PM To: Maven Users List Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.4/363 - Release Date: 6/13/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.4/363 - Release Date: 6/13/2006 - 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
RE: integration builds and version numbers
The only place on that page I see passwords mentioned is in regards to repositories: settings servers server idcommons.ucalgary.ca/id usernamewoodj/username privateKey~/.ssh/id_rsa/privateKey passphrase***/passphrase password***/password /server /servers /settings I'm talking about passwords to perforce -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:55 AM To: Maven Users List Subject: RE: integration builds and version numbers The website mentioned by Kieran Brady shows how you can store the scm passwords. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:40 PM To: Maven Users List Subject: RE: integration builds and version numbers Ok - got the pdf, but I'm confused. Does this release plugin need to be configured at the parent or child pom level? What if our scm tool of choose (perforce) requires passwords? -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:26 AM To: Maven Users List Subject: RE: integration builds and version numbers In chapter 7 of the 'better builds with maven' book (downloadable from www.mergere.com) there is a description on how to use the release plugin. The plugin website can be found at http://maven.apache.org/plugins/maven-release-plugin/ Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:14 PM To: Maven Users List Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition
RE: integration builds and version numbers
Also - where should this plugin be configured? Once in each child module or one time in the parent pom? We plan on branching just the modules needed for a particular change and then just releasing those into the wild. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:54 AM To: Maven Users List Subject: RE: integration builds and version numbers The only place on that page I see passwords mentioned is in regards to repositories: settings servers server idcommons.ucalgary.ca/id usernamewoodj/username privateKey~/.ssh/id_rsa/privateKey passphrase***/passphrase password***/password /server /servers /settings I'm talking about passwords to perforce -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:55 AM To: Maven Users List Subject: RE: integration builds and version numbers The website mentioned by Kieran Brady shows how you can store the scm passwords. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:40 PM To: Maven Users List Subject: RE: integration builds and version numbers Ok - got the pdf, but I'm confused. Does this release plugin need to be configured at the parent or child pom level? What if our scm tool of choose (perforce) requires passwords? -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:26 AM To: Maven Users List Subject: RE: integration builds and version numbers In chapter 7 of the 'better builds with maven' book (downloadable from www.mergere.com) there is a description on how to use the release plugin. The plugin website can be found at http://maven.apache.org/plugins/maven-release-plugin/ Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:14 PM To: Maven Users List Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: integration builds and version numbers
The perforce provider does not handle passwords; it is assumed that you are already logged in. We have a special build user who is only allowed to log in from the build server and whose login never expires. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:54 AM To: Maven Users List Subject: RE: integration builds and version numbers I'm talking about passwords to perforce -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:55 AM To: Maven Users List Subject: RE: integration builds and version numbers The website mentioned by Kieran Brady shows how you can store the scm passwords. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:40 PM To: Maven Users List Subject: RE: integration builds and version numbers Ok - got the pdf, but I'm confused. Does this release plugin need to be configured at the parent or child pom level? What if our scm tool of choose (perforce) requires passwords? -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:26 AM To: Maven Users List Subject: RE: integration builds and version numbers In chapter 7 of the 'better builds with maven' book (downloadable from www.mergere.com) there is a description on how to use the release plugin. The plugin website can be found at http://maven.apache.org/plugins/maven-release-plugin/ Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:14 PM To: Maven Users List Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/362 - Release Date: 6/12/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
RE: integration builds and version numbers
Does anyone know if mvn, when using the perforce scm config, will pull the users password from an environment variable? Mike, did you try that before you left this person logged in? -Original Message- From: Mike Perham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 12:12 PM To: Maven Users List Subject: RE: integration builds and version numbers The perforce provider does not handle passwords; it is assumed that you are already logged in. We have a special build user who is only allowed to log in from the build server and whose login never expires. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:54 AM To: Maven Users List Subject: RE: integration builds and version numbers I'm talking about passwords to perforce -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:55 AM To: Maven Users List Subject: RE: integration builds and version numbers The website mentioned by Kieran Brady shows how you can store the scm passwords. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:40 PM To: Maven Users List Subject: RE: integration builds and version numbers Ok - got the pdf, but I'm confused. Does this release plugin need to be configured at the parent or child pom level? What if our scm tool of choose (perforce) requires passwords? -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:26 AM To: Maven Users List Subject: RE: integration builds and version numbers In chapter 7 of the 'better builds with maven' book (downloadable from www.mergere.com) there is a description on how to use the release plugin. The plugin website can be found at http://maven.apache.org/plugins/maven-release-plugin/ Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:14 PM To: Maven Users List Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.8.3/361 - Release Date: 6/11/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus
RE: integration builds and version numbers
Ok, I need more detail on how to utilize the release plugin (there's no
fully documented example anywhere I've looked - including that pdf book)
Here's a snippet of my pom.xml (which results in a Missing required
setting: scm connection or developerConnection must be specified.
Error)
scm
connectionscm:perforce:[EMAIL PROTECTED]:1666://depot/up-svcs-t
est/${project.artifactId}/.../connection
developerConnectionscm:perforce:[EMAIL PROTECTED]:1666://depot/
up-svcs-test/${project.artifactId}/.../developerConnection
/scm
dependencies
dependency
groupIdlty/groupId
artifactIdcrypto/artifactId
version1.0-SNAPSHOT/version
/dependency
/dependencies
build
resources
resource
directorysrc/main/scripts/directory
targetPath../scripts/targetPath
filteringtrue/filtering
/resource
/resources
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptorsrc/main/assembly/dep.xml/descriptor
/configuration
/plugin
plugin
artifactIdmaven-jar-plugin/artifactId
configuration
jarNamelib/${project.artifactId}-${project.version}/jarName
/configuration
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
configuration
tagBase
file:///E:/work/up-svcs-test/rel/R1.5/cryptoServer
/tagBase
/configuration
/plugin
/plugins
/build
/project
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 2:48 PM
To: Maven Users List
Subject: RE: integration builds and version numbers
Does anyone know if mvn, when using the perforce scm config, will pull
the users password from an environment variable?
Mike, did you try that before you left this person logged in?
-Original Message-
From: Mike Perham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 12:12 PM
To: Maven Users List
Subject: RE: integration builds and version numbers
The perforce provider does not handle passwords; it is assumed that you
are already logged in. We have a special build user who is only allowed
to log in from the build server and whose login never expires.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 9:54 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
I'm talking about passwords to perforce
-Original Message-
From: Roald Bankras [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 10:55 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
The website mentioned by Kieran Brady shows how you can store
the scm passwords.
Roald Bankras
Software Engineer
JTeam b.v.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 4:40 PM
To: Maven Users List
Subject: RE: integration builds and version numbers
Ok - got the pdf, but I'm confused. Does this release plugin
need to be configured at the parent or child pom level? What
if our scm tool of choose (perforce) requires passwords?
-Original Message-
From: Roald Bankras [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 10:26 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
In chapter 7 of the 'better builds with maven' book (downloadable from
www.mergere.com) there is a description on how to use the
release plugin.
The plugin website can be found at
http://maven.apache.org/plugins/maven-release-plugin/
Roald Bankras
Software Engineer
JTeam b.v.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 4:14 PM
To: Maven Users List
Subject: RE: integration builds and version numbers
I tried both mvn release and mvn release:release - neither exists.
What is the correct goal?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 9:51 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
Where is this documented? I'd like to read more about this.
-Original Message-
From: Roald Bankras [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 14, 2006 3:16 AM
To: Maven Users List
Subject: RE: integration builds and version numbers
Updating the version numbers in the pom files can be done by
calling the release goal.
Roald Bankras
Software Engineer
JTeam b.v.
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Monday, June 12, 2006 11:30 PM
To: Maven Users List
Subject: RE: integration builds and version numbers
Someone must be using CC + M2, no?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Monday, June 12, 2006 8:01 AM
To: Maven Users List
Subject
RE: integration builds and version numbers
I wrote the Perforce integration for Maven 2.0 so I am the proverbial horse's mouth. It will not. It does not run 'p4 login' at all. You need to be logged in beforehand. You might be able to use a cron job with the P4PASSWD environment variable to automatically login the user every X hours but I've never tried that before. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 1:48 PM To: Maven Users List Subject: RE: integration builds and version numbers Does anyone know if mvn, when using the perforce scm config, will pull the users password from an environment variable? Mike, did you try that before you left this person logged in? -Original Message- From: Mike Perham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 12:12 PM To: Maven Users List Subject: RE: integration builds and version numbers The perforce provider does not handle passwords; it is assumed that you are already logged in. We have a special build user who is only allowed to log in from the build server and whose login never expires. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:54 AM To: Maven Users List Subject: RE: integration builds and version numbers I'm talking about passwords to perforce -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:55 AM To: Maven Users List Subject: RE: integration builds and version numbers The website mentioned by Kieran Brady shows how you can store the scm passwords. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:40 PM To: Maven Users List Subject: RE: integration builds and version numbers Ok - got the pdf, but I'm confused. Does this release plugin need to be configured at the parent or child pom level? What if our scm tool of choose (perforce) requires passwords? -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:26 AM To: Maven Users List Subject: RE: integration builds and version numbers In chapter 7 of the 'better builds with maven' book (downloadable from www.mergere.com) there is a description on how to use the release plugin. The plugin website can be found at http://maven.apache.org/plugins/maven-release-plugin/ Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:14 PM To: Maven Users List Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C
Re: integration builds and version numbers
Just pass it on the command line. You should check the plugin page. Tons of information like the goal names and their properties : http://maven.apache.org/plugins/maven-release-plugin/howto.html http://maven.apache.org/plugins/maven-release-plugin/plugin-info.html On 6/14/06, EJ Ciramella [EMAIL PROTECTED] wrote: Does anyone know if mvn, when using the perforce scm config, will pull the users password from an environment variable? Mike, did you try that before you left this person logged in? -Original Message- From: Mike Perham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 12:12 PM To: Maven Users List Subject: RE: integration builds and version numbers The perforce provider does not handle passwords; it is assumed that you are already logged in. We have a special build user who is only allowed to log in from the build server and whose login never expires. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:54 AM To: Maven Users List Subject: RE: integration builds and version numbers I'm talking about passwords to perforce -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:55 AM To: Maven Users List Subject: RE: integration builds and version numbers The website mentioned by Kieran Brady shows how you can store the scm passwords. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:40 PM To: Maven Users List Subject: RE: integration builds and version numbers Ok - got the pdf, but I'm confused. Does this release plugin need to be configured at the parent or child pom level? What if our scm tool of choose (perforce) requires passwords? -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 10:26 AM To: Maven Users List Subject: RE: integration builds and version numbers In chapter 7 of the 'better builds with maven' book (downloadable from www.mergere.com) there is a description on how to use the release plugin. The plugin website can be found at http://maven.apache.org/plugins/maven-release-plugin/ Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 4:14 PM To: Maven Users List Subject: RE: integration builds and version numbers I tried both mvn release and mvn release:release - neither exists. What is the correct goal? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 9:51 AM To: Maven Users List Subject: RE: integration builds and version numbers Where is this documented? I'd like to read more about this. -Original Message- From: Roald Bankras [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 3:16 AM To: Maven Users List Subject: RE: integration builds and version numbers Updating the version numbers in the pom files can be done by calling the release goal. Roald Bankras Software Engineer JTeam b.v. -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 11:30 PM To: Maven Users List Subject: RE: integration builds and version numbers Someone must be using CC + M2, no? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 8:01 AM To: Maven Users List Subject: integration builds and version numbers How are people updating their pom.xml files with version numbers from say cruisecontrol? We have two types of codelines (in perforce) here, project and release lines. Everything starts out life as a project then over time one (or more) projects can be integrated to a release line. I'm curious, we're forcefully editing (with the ant replace task) some templated version.html files to reflect what version was built. Do I need to be doing this to the pom.xml files also? When something is getting built from a project branch, the build number looks like this: X.projectbranchname.buildnumber So: 8.P01.1 In the maven world, all the project branches would look like this: versionX.X-SNAPSHOT/version So in the above case - version8.0-P01-SNAPSHOT/version And when that goes to release version8.0.X/version Where X is a build number. This has a problem though - I'll have to remember the dependency order to build and make sure that module C gets built before B which is built before A (or the replace at least happens in that order). So what are people doing for this? Manually updating before every build? I _really_ don't want to have to go back to that - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- No virus found
