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.
>
> <project>
> ...
> <dependencies>
> ...
> <dependency>
> <groupId>foo.bar</groupId>
> <artifactId>foo-core</artifactId>
> <version>[${foo-core.version}]</version>
> <!-- wrapping the property in a hard range forces maven to use the exact
> version specified -->
> </dependency>
> ...
> </dependencies>
> ...
> <properties>
> ...
> <foo-core.version>1.3.0.0.1</foo-core.version>
> ...
> </properties>
> ...
> <build>
> ...
> <plugins>
> ...
> <plugin>
> <groupId><!-- will hopefully be -->org.codehaus.mojo</groupId>
> <artifactId>versions-maven-plugin</artifactId>
> <configuration>
> <comparisonMethod>numeric</comparisonMethod> <!-- this forces link item
> versions to be compared numerically and not the maven rule -->
> <linkItems>
> <linkItem>
> <groupId>foo.bar</groupId>
> <artifactId>foo-core</artifactId>
> <property>foo-core.version</property>
> <version>[1.3,1.4)</version>
> <!-- this will update the pom to set the foo-core.version property
> to the latest version of foo-core as defined using the numeric comparison
> method -->
> </linkItem>
> </linkItems>
> </configuration>
> ...
> </plugins>
> ...
> </build>
> ...
> </project>
>
>
>>
>> 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]
>>
>>
>
