v-m-p has become, while not a critical plugin, at least an essential plugin for a large number of people.
At the moment v-m-p's integration tests are creaking under the issues of reproducibility. I have one build environment where all the tests pass as written (my Acer Aspire One netbook), but numerous attempts to replicate that environment result in sporadic integration test failures. I am very much reluctant to go extending v-m-p until I sort out the mock-repository-maven-plugin which will allow me to refactor the tests to be truly portable (as well as speed them up). Until I have a truly portable reproducible set of integration tests I do not want to accept new patches as regressions could hamper existing users and rubbish the reputation of v-m-p. I am also warey of adding yet more version comparators. the only one I am considering is an OSGi one, because I view the version comparators as currently implemented by v-m-p as a hack to work around deficiencies in the maven repo layout -Stephen On 21 October 2010 18:06, Vincent Latombe <[email protected]> wrote: > Hello, > > About version comparator themselves, I couldn't find one that fit my use > case which is, multiple development branches evolving in parallel, with > pseudo releases. > > For example, I can have versions like 1.0-1234-01, 1.0-1234-02, 1.0-5678-01, > and I want to match with a version range only versions produced by a > specific branch. > > To implement this, I made a modified version of v-m-p in order to make > VersionComparator a plexus component. > > This way, I can inject a custom VersionComparator implementation in order to > compute the versions order as I wish. > > If you're interested, I can submit the patch. > > Cheers, > > Vincent > 2010/10/21 Stephen Connolly <[email protected]> > >> I have not tested a file: based URL, only http: (because if you are >> using these rules you really need to publish them to your entire team) >> >> On 21 October 2010 15:13, Moser, Christian <[email protected]> wrote: >> > Yes I did, I tried to call the plugin with: >> > 'D:\MNet\Tools\maven\bin\mvn.bat >> -Dmaven.version.rules=file:///C:/Users/cmo/Desktop/rules.xml >> -Dmaven.repo.local=C:\Java\.m2\repository --update-snapshots >> org.codehaus.mojo:versions-maven-plugin:1.2:display-dependency-updates' >> > >> > rules.xml content: >> > <ruleset comparisonMethod="maven"> >> > <rules> >> > <rule groupId="mnet" comparisonMethod="mercury"/> (also tried numeric) >> > </rules> >> > </ruleset> >> > >> > But it didn't work. Is there any possibility to configure version number >> rules in more detail? >> > >> > -----Ursprüngliche Nachricht----- >> > Von: Stephen Connolly [mailto:[email protected]] >> > Gesendet: Donnerstag, 21. Oktober 2010 13:14 >> > An: Maven Users List >> > Betreff: Re: maven-versions-plugin version comparism >> > >> > Did you read the FAQ? >> > >> > http://mojo.codehaus.org/versions-maven-plugin/faq.html#comparisonMethod >> > >> > On 21 October 2010 11:56, Moser, Christian <[email protected]> wrote: >> >> I've got following effect with the maven versions plugin 1.2. >> >> >> >> >> >> >> >> If we release a milestone of our software, we declare the components >> >> which are included in the milestone with [version]-[unrel]-[revision]. >> >> When the software is in the release process, we remove the additional >> >> declaration. For example: Version 1.1.0-unrel-0038381 will be >> >> transformed to 1.1.0, so in fact, 1.1.0 is newer than >> >> 1.1.0-unrel-0038381. >> >> >> >> >> >> >> >> I don't know why the plugin acts like this: >> >> >> >> >> >> >> >> org.codehaus.mojo:versions-maven-plugin:1.2:display-dependency-updates >> >> will >> >> >> >> ... >> >> >> >> The following dependencies in Dependency Management have newer versions: >> >> >> >> SnakeYAML:SnakeYAML ....................................... 1.2 -> 1.3 >> >> >> >> mnet:comp-accessoriesconfig ............. 1.1.0 -> 1.1.0-unrel-0038381 >> >> >> >> mnet:comp-accessoriesconfig-if .......... 1.1.0 -> 1.1.0-unrel-0038381 >> >> >> >> mnet:comp-accessoriesconfigview ......... 1.1.0 -> 1.2.0-unrel-0039226 >> >> >> >> mnet:comp-accessoriesconfigview-if ...... 1.0.0 -> 1.0.0-unrel-0027036 >> >> >> >> ... >> >> >> >> >> >> >> >> Do you know why? >> >> >> >> >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > 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] >> >> > > > -- > Vincent > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
