AW: Specific version/dependency resolving in maven
Hello Stephen and everyboy,
your proposal looks very promising. I think we are facing the same problems
with Maven versioning.
By the way, how do you increment the version for the next development version?
The release Plugin increments by default only the last digit. We have different
interation phases and might want to increment the second last digit.
Thanks for sharing your plugin
Kuno
-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 30. Juli 2008 11:15
An: Maven Users List
Betreff: Re: Specific version/dependency resolving in maven
When we need to use a newer version we just run mvn versions:update-properties
On Wed, Jul 30, 2008 at 10:14 AM, Stephen Connolly < [EMAIL PROTECTED]> wrote:
>
>
> On Wed, Jul 30, 2008 at 9:52 AM, Baeriswyl Kuno - Extern (IT-BA-MV)
> <[EMAIL PROTECTED]> wrote:
>
>> Hello!
>>
>> I vote for 4 digit versioning scheme support as well. I'm currently
>> thinging about a release process with a 4 digit versioning scheme.
>> I'm not quite sure if I get that work without using version ranges.
>> Probably, I'll need to implementent some scripts that do the work for
>> changing versions in the poms. We've got about 20 cascaded
>> subsystems.
>>
>
> Please vote for MOJO-1178... you can use properties to lock down the
> versions and the update-properties goal will update them... (provided
> us use
> -DcomparisonMethod=numeric)
>
> We have 5 digit version numbers here and properties are the only way
> we can use version ranges as things stand at the moment... i.e.
>
>
> ...
>
> ...
>
> foo.bar
> foo-core
> [${foo-core.version}]
>
> ...
>
> ...
>
> ...
> 1.3.0.0.1
> ...
>
> ...
>
> ...
>
> ...
>
> org.codehaus.mojo
> versions-maven-plugin
>
> numeric
>
>
> foo.bar
> foo-core
> foo-core.version
> [1.3,1.4)
>
>
>
>
> ...
>
> ...
>
> ...
>
>
>
>>
>> You might move the forth digit to the qualifier. But this is getting
>> a bit error-prone..I was thinging about 1.2.3-beta-1.1.
>>
>> -Kuno
>>
>> -Ursprüngliche Nachricht-
>> Von: Stephen Connolly [mailto:[EMAIL PROTECTED]
>> Gesendet: Dienstag, 29. Juli 2008 16:38
>> An: Maven Users List
>> Betreff: Re: Specific version/dependency resolving in maven
>>
>>
>> However version ranges are borken with more than three digits!
>>
>> i.e. Maven thinks 1.0.0.22 < 1.0.0.3
>>
>> Which is no good...
>>
>> I'd like to get a patch to the DefaultArtifactVersion.compareTo
>> method so that if not in the Maven version number format it compares
>> . separated portions as numbers if they are both numeric
>>
>> But my understanding is that there is an overall fear of breaking
>> builds with such a change... I scream faul, as all Maven projects to
>> date are using the maven version number scheme, and everyone else
>> should want this fixed!
>>
>> -Stephen
>>
>> On Tue, Jul 29, 2008 at 10:26 AM, Stefan Seidel <[EMAIL PROTECTED]>
>> wrote:
>>
>> > You should use version ranges[0] and/or the release plugin[1].
>> >
>> > Stefan
>> > [0]
>> > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Con
>> > fli
>> >
>> ct+Resolution#DependencyMediationandConflictResolution-DependencyVers
>> ct+ionRanges
>> > [1] http://maven.apache.org/plugins/maven-release-plugin/
>> >
>> >
>> > Victor Tsoukanov wrote:
>> >
>> >> I would like to use versioning based on JSR-277. They use the
>> >> following
>> >> format: major[.minor[.micro[.update]]][-qualifier]. Some extraxt
>> >> from
>> spec
>> >> 1. Major version number should be incremented for making changes
>> >> that
>> are
>> >> not backward compatible.
>> >> 2. Minor version number should be incremented for making medium or
>> minor
>> >> changes that the software remains largely backward compatible,
>> >> although minor incompatibilities might be possible. For example I
>> >> have 3 modules: m1, m2 and m3 (m2 and m3 depends on m1).
>> But
>> >> m2 depends on m1 with version 1.0.0.0 and m3 depends on 1.1.0.0.
>> >> As
>> you
>> >> see the changes in m1 are "largely backward compatible" - it means
>> >> I
>> can
>> >> compile m2 and m3 wi
Re: Specific version/dependency resolving in maven
When we need to use a newer version we just run mvn
versions:update-properties
On Wed, Jul 30, 2008 at 10:14 AM, Stephen Connolly <
[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Jul 30, 2008 at 9:52 AM, Baeriswyl Kuno - Extern (IT-BA-MV)
> <[EMAIL PROTECTED]> wrote:
>
>> Hello!
>>
>> I vote for 4 digit versioning scheme support as well. I'm currently
>> thinging about a release process with a 4 digit versioning scheme. I'm not
>> quite sure if I get that work without using version ranges. Probably, I'll
>> need to implementent some scripts that do the work for changing versions in
>> the poms. We've got about 20 cascaded subsystems.
>>
>
> Please vote for MOJO-1178... you can use properties to lock down the
> versions and the update-properties goal will update them... (provided us use
> -DcomparisonMethod=numeric)
>
> We have 5 digit version numbers here and properties are the only way we can
> use version ranges as things stand at the moment... i.e.
>
>
> ...
>
> ...
>
> foo.bar
> foo-core
> [${foo-core.version}]
>
>
> ...
>
> ...
>
> ...
> 1.3.0.0.1
> ...
>
> ...
>
> ...
>
> ...
>
> org.codehaus.mojo
> versions-maven-plugin
>
> numeric
>
>
> foo.bar
> foo-core
> foo-core.version
> [1.3,1.4)
>
>
>
>
> ...
>
> ...
>
> ...
>
>
>
>>
>> You might move the forth digit to the qualifier. But this is getting a bit
>> error-prone..I was thinging about 1.2.3-beta-1.1.
>>
>> -Kuno
>>
>> -Ursprüngliche Nachricht-
>> Von: Stephen Connolly [mailto:[EMAIL PROTECTED]
>> Gesendet: Dienstag, 29. Juli 2008 16:38
>> An: Maven Users List
>> Betreff: Re: Specific version/dependency resolving in maven
>>
>>
>> However version ranges are borken with more than three digits!
>>
>> i.e. Maven thinks 1.0.0.22 < 1.0.0.3
>>
>> Which is no good...
>>
>> I'd like to get a patch to the DefaultArtifactVersion.compareTo method so
>> that if not in the Maven version number format it compares . separated
>> portions as numbers if they are both numeric
>>
>> But my understanding is that there is an overall fear of breaking builds
>> with such a change... I scream faul, as all Maven projects to date are
>> using the maven version number scheme, and everyone else should want this
>> fixed!
>>
>> -Stephen
>>
>> On Tue, Jul 29, 2008 at 10:26 AM, Stefan Seidel <[EMAIL PROTECTED]> wrote:
>>
>> > You should use version ranges[0] and/or the release plugin[1].
>> >
>> > Stefan
>> > [0]
>> > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Confli
>> >
>> ct+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
>> > [1] http://maven.apache.org/plugins/maven-release-plugin/
>> >
>> >
>> > Victor Tsoukanov wrote:
>> >
>> >> I would like to use versioning based on JSR-277. They use the
>> >> following
>> >> format: major[.minor[.micro[.update]]][-qualifier]. Some extraxt from
>> spec
>> >> 1. Major version number should be incremented for making changes that
>> are
>> >> not backward compatible.
>> >> 2. Minor version number should be incremented for making medium or
>> minor
>> >> changes that the software remains largely backward compatible, although
>> >> minor incompatibilities might be possible.
>> >> For example I have 3 modules: m1, m2 and m3 (m2 and m3 depends on m1).
>> But
>> >> m2 depends on m1 with version 1.0.0.0 and m3 depends on 1.1.0.0. As
>> you
>> >> see the changes in m1 are "largely backward compatible" - it means I
>> can
>> >> compile m2 and m3 with m1(1.1.0.0). When I try to compile it in maven
>> m3
>> >> was compiled with m1(1.1.0.0) and m2 was compiled with m1(1.0.0.0)
>> since
>> >> they declared such dependencies, but I would like that maven compile
>> both
>> >> modules with last version of m1(1.1.0.0). As I know for this cases
>> maven
>> >> suggests to use snapshot, but I would like to have version history in
>> my
>> >> repository.
>> >> Could somebody help me how could I implement such behavior in maven.
>> >> Thanks
>> >>
>> >> -
>> >> 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: Specific version/dependency resolving in maven
On Wed, Jul 30, 2008 at 9:52 AM, Baeriswyl Kuno - Extern (IT-BA-MV)
<[EMAIL PROTECTED]> wrote:
> Hello!
>
> I vote for 4 digit versioning scheme support as well. I'm currently
> thinging about a release process with a 4 digit versioning scheme. I'm not
> quite sure if I get that work without using version ranges. Probably, I'll
> need to implementent some scripts that do the work for changing versions in
> the poms. We've got about 20 cascaded subsystems.
>
Please vote for MOJO-1178... you can use properties to lock down the
versions and the update-properties goal will update them... (provided us use
-DcomparisonMethod=numeric)
We have 5 digit version numbers here and properties are the only way we can
use version ranges as things stand at the moment... i.e.
...
...
foo.bar
foo-core
[${foo-core.version}]
...
...
...
1.3.0.0.1
...
...
...
...
org.codehaus.mojo
versions-maven-plugin
numeric
foo.bar
foo-core
foo-core.version
[1.3,1.4)
...
...
...
>
> You might move the forth digit to the qualifier. But this is getting a bit
> error-prone..I was thinging about 1.2.3-beta-1.1.
>
> -Kuno
>
> -Ursprüngliche Nachricht-
> Von: Stephen Connolly [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 29. Juli 2008 16:38
> An: Maven Users List
> Betreff: Re: Specific version/dependency resolving in maven
>
>
> However version ranges are borken with more than three digits!
>
> i.e. Maven thinks 1.0.0.22 < 1.0.0.3
>
> Which is no good...
>
> I'd like to get a patch to the DefaultArtifactVersion.compareTo method so
> that if not in the Maven version number format it compares . separated
> portions as numbers if they are both numeric
>
> But my understanding is that there is an overall fear of breaking builds
> with such a change... I scream faul, as all Maven projects to date are
> using the maven version number scheme, and everyone else should want this
> fixed!
>
> -Stephen
>
> On Tue, Jul 29, 2008 at 10:26 AM, Stefan Seidel <[EMAIL PROTECTED]> wrote:
>
> > You should use version ranges[0] and/or the release plugin[1].
> >
> > Stefan
> > [0]
> > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Confli
> >
> ct+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
> > [1] http://maven.apache.org/plugins/maven-release-plugin/
> >
> >
> > Victor Tsoukanov wrote:
> >
> >> I would like to use versioning based on JSR-277. They use the
> >> following
> >> format: major[.minor[.micro[.update]]][-qualifier]. Some extraxt from
> spec
> >> 1. Major version number should be incremented for making changes that
> are
> >> not backward compatible.
> >> 2. Minor version number should be incremented for making medium or minor
> >> changes that the software remains largely backward compatible, although
> >> minor incompatibilities might be possible.
> >> For example I have 3 modules: m1, m2 and m3 (m2 and m3 depends on m1).
> But
> >> m2 depends on m1 with version 1.0.0.0 and m3 depends on 1.1.0.0. As you
> >> see the changes in m1 are "largely backward compatible" - it means I can
> >> compile m2 and m3 with m1(1.1.0.0). When I try to compile it in maven
> m3
> >> was compiled with m1(1.1.0.0) and m2 was compiled with m1(1.0.0.0)
> since
> >> they declared such dependencies, but I would like that maven compile
> both
> >> modules with last version of m1(1.1.0.0). As I know for this cases
> maven
> >> suggests to use snapshot, but I would like to have version history in my
> >> repository.
> >> Could somebody help me how could I implement such behavior in maven.
> >> Thanks
> >>
> >> -
> >> 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]
>
>
AW: Specific version/dependency resolving in maven
Hello! I vote for 4 digit versioning scheme support as well. I'm currently thinging about a release process with a 4 digit versioning scheme. I'm not quite sure if I get that work without using version ranges. Probably, I'll need to implementent some scripts that do the work for changing versions in the poms. We've got about 20 cascaded subsystems. You might move the forth digit to the qualifier. But this is getting a bit error-prone..I was thinging about 1.2.3-beta-1.1. -Kuno -Ursprüngliche Nachricht- Von: Stephen Connolly [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2008 16:38 An: Maven Users List Betreff: Re: Specific version/dependency resolving in maven However version ranges are borken with more than three digits! i.e. Maven thinks 1.0.0.22 < 1.0.0.3 Which is no good... I'd like to get a patch to the DefaultArtifactVersion.compareTo method so that if not in the Maven version number format it compares . separated portions as numbers if they are both numeric But my understanding is that there is an overall fear of breaking builds with such a change... I scream faul, as all Maven projects to date are using the maven version number scheme, and everyone else should want this fixed! -Stephen On Tue, Jul 29, 2008 at 10:26 AM, Stefan Seidel <[EMAIL PROTECTED]> wrote: > You should use version ranges[0] and/or the release plugin[1]. > > Stefan > [0] > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Confli > ct+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges > [1] http://maven.apache.org/plugins/maven-release-plugin/ > > > Victor Tsoukanov wrote: > >> I would like to use versioning based on JSR-277. They use the >> following >> format: major[.minor[.micro[.update]]][-qualifier]. Some extraxt from spec >> 1. Major version number should be incremented for making changes that are >> not backward compatible. >> 2. Minor version number should be incremented for making medium or minor >> changes that the software remains largely backward compatible, although >> minor incompatibilities might be possible. >> For example I have 3 modules: m1, m2 and m3 (m2 and m3 depends on m1). But >> m2 depends on m1 with version 1.0.0.0 and m3 depends on 1.1.0.0. As you >> see the changes in m1 are "largely backward compatible" - it means I can >> compile m2 and m3 with m1(1.1.0.0). When I try to compile it in maven m3 >> was compiled with m1(1.1.0.0) and m2 was compiled with m1(1.0.0.0) since >> they declared such dependencies, but I would like that maven compile both >> modules with last version of m1(1.1.0.0). As I know for this cases maven >> suggests to use snapshot, but I would like to have version history in my >> repository. >> Could somebody help me how could I implement such behavior in maven. >> Thanks >> >> - >> 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: Specific version/dependency resolving in maven
I used version ranges and it is enough for me, ues it does not support more than 3 digits, but it's ok, thanks. I set version of m1 as "1.1.0" and used ranges in m2 and m3 as .. [1.0,2.0) But now I have additional question :) How could I force maven to use specified version of modules instead of the last ones (if I use ranges in module dependencies maven will choose last version of module). For example I would like to build m2 with specific version of m1 to reproduce a bug which is not reproduced with last version of modules. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Specific version/dependency resolving in maven
However version ranges are borken with more than three digits! i.e. Maven thinks 1.0.0.22 < 1.0.0.3 Which is no good... I'd like to get a patch to the DefaultArtifactVersion.compareTo method so that if not in the Maven version number format it compares . separated portions as numbers if they are both numeric But my understanding is that there is an overall fear of breaking builds with such a change... I scream faul, as all Maven projects to date are using the maven version number scheme, and everyone else should want this fixed! -Stephen On Tue, Jul 29, 2008 at 10:26 AM, Stefan Seidel <[EMAIL PROTECTED]> wrote: > You should use version ranges[0] and/or the release plugin[1]. > > Stefan > [0] > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges > [1] http://maven.apache.org/plugins/maven-release-plugin/ > > > Victor Tsoukanov wrote: > >> I would like to use versioning based on JSR-277. They use the following >> format: major[.minor[.micro[.update]]][-qualifier]. Some extraxt from spec >> 1. Major version number should be incremented for making changes that are >> not backward compatible. >> 2. Minor version number should be incremented for making medium or minor >> changes that the software remains largely backward compatible, although >> minor incompatibilities might be possible. >> For example I have 3 modules: m1, m2 and m3 (m2 and m3 depends on m1). But >> m2 depends on m1 with version 1.0.0.0 and m3 depends on 1.1.0.0. As you >> see the changes in m1 are "largely backward compatible" - it means I can >> compile m2 and m3 with m1(1.1.0.0). When I try to compile it in maven m3 >> was compiled with m1(1.1.0.0) and m2 was compiled with m1(1.0.0.0) since >> they declared such dependencies, but I would like that maven compile both >> modules with last version of m1(1.1.0.0). As I know for this cases maven >> suggests to use snapshot, but I would like to have version history in my >> repository. >> Could somebody help me how could I implement such behavior in maven. >> Thanks >> >> - >> 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: Specific version/dependency resolving in maven
You should use version ranges[0] and/or the release plugin[1]. Stefan [0] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges [1] http://maven.apache.org/plugins/maven-release-plugin/ Victor Tsoukanov wrote: I would like to use versioning based on JSR-277. They use the following format: major[.minor[.micro[.update]]][-qualifier]. Some extraxt from spec 1. Major version number should be incremented for making changes that are not backward compatible. 2. Minor version number should be incremented for making medium or minor changes that the software remains largely backward compatible, although minor incompatibilities might be possible. For example I have 3 modules: m1, m2 and m3 (m2 and m3 depends on m1). But m2 depends on m1 with version 1.0.0.0 and m3 depends on 1.1.0.0. As you see the changes in m1 are "largely backward compatible" - it means I can compile m2 and m3 with m1(1.1.0.0). When I try to compile it in maven m3 was compiled with m1(1.1.0.0) and m2 was compiled with m1(1.0.0.0) since they declared such dependencies, but I would like that maven compile both modules with last version of m1(1.1.0.0). As I know for this cases maven suggests to use snapshot, but I would like to have version history in my repository. Could somebody help me how could I implement such behavior in maven. Thanks - 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]
Specific version/dependency resolving in maven
I would like to use versioning based on JSR-277. They use the following format: major[.minor[.micro[.update]]][-qualifier]. Some extraxt from spec 1. Major version number should be incremented for making changes that are not backward compatible. 2. Minor version number should be incremented for making medium or minor changes that the software remains largely backward compatible, although minor incompatibilities might be possible. For example I have 3 modules: m1, m2 and m3 (m2 and m3 depends on m1). But m2 depends on m1 with version 1.0.0.0 and m3 depends on 1.1.0.0. As you see the changes in m1 are "largely backward compatible" - it means I can compile m2 and m3 with m1(1.1.0.0). When I try to compile it in maven m3 was compiled with m1(1.1.0.0) and m2 was compiled with m1(1.0.0.0) since they declared such dependencies, but I would like that maven compile both modules with last version of m1(1.1.0.0). As I know for this cases maven suggests to use snapshot, but I would like to have version history in my repository. Could somebody help me how could I implement such behavior in maven. Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
