I think everything after the third digit becomes a lexographic compare. That is why three behavior is unexpected to you. This is not an issue with the standard three numbers. On Mar 16, 2014 7:39 PM, "Chris Graham" <[email protected]> wrote:
> I've been using the 4 digit versions with the release plugin for the last 6 > years or so. > I've never used ranges, as I either thought there was a problem with them > and the release plugin. > So if 1.0.0.10 comes before 1.0.0.9, wouldn't 1.0.10 therefor come before > 1.0.9? > > -Chris > > > On Sun, Mar 16, 2014 at 8:55 PM, Robert Scholte <[email protected] > >wrote: > > > Hi Chris, > > > > the input is a String, so it's possible to support as many digits as you > > can. > > However, an ArtifactVersion [1] doesn't support that much digits, so I'll > > lock it to 3 to keep the current Maven versioning style. When working > with > > ranges 1.0.0.10 comes before 1.0.0.9 because the part after the second > dot > > can't be handled as an Integer, so it is handled as a String. For that > > reason the Maven Release plugin shouldn't be able to generate such > > versions. If you are aware of this and never use ranges, you are safe > (but > > not your consumers ;) ) > > > > Robert > > > > [1] http://maven.apache.org/ref/3.2.1/maven-artifact/apidocs/ > > org/apache/maven/artifact/versioning/ArtifactVersion.html > > > > Op Sun, 16 Mar 2014 05:30:12 +0100 schreef Chris Graham < > > [email protected]>: > > > > > > Hi Robert. > >> > >> Just a request, can you please test to 4 (that I always use) and 5 > digits, > >> that sometimes I have to use? > >> > >> Ie > >> 1.0.0.1-SNAPSHOT > >> and > >> 1.0.0.1.1-SNAPSHOT > >> > >> If you can, it might save me quite a bit of work later on. The release > >> plugin copes with 4 digits, but not 5 (from what I can see in the code). > >> > >> Ta. > >> > >> -Chris > >> > >> > >> > >> On Fri, Mar 14, 2014 at 5:19 AM, Robert Scholte <[email protected] > >> >wrote: > >> > >> To say it in your own words: IMHO I think you're wrong here ;) > >>> > >>> Version policy is about calculating the next version based on an input > >>> version. > >>> These are valid examples: > >>> default policy: > >>> getReleaseVersion("1-SNAPSHOT") = 1 > >>> getReleaseVersion("1.0-SNAPSHOT") = 1.0 > >>> getReleaseVersion("1.0.0-SNAPSHOT") = 1.0.0 > >>> getDevelopmentVersion("1") = 2-SNAPSHOT > >>> getDevelopmentVersion("1.0") = 1.1-SNAPSHOT > >>> getDevelopmentVersion("1.0.0") = 1.0.1-SNAPSHOT > >>> > >>> odd-even > >>> getReleaseVersion("1.0-SNAPSHOT") = 1.1 > >>> getDevelopmentVersion("1.1") = 1.2-SNAPSHOT > >>> > >>> the metadata gives the following opportunity: > >>> suppose you're on 3.2-SNAPSHOT but want to release a bugfix. In that > case > >>> you'd like to return to the latest SNAPSHOT. So instead of 3.1.4 -> > >>> 3.1.5-SNAPSHOT it'll be 3.1.4 -> 3.2-SNAPSHOT > >>> > >>> I think it's weird to depend the policy on the GAV. Just choose a > proper > >>> policy for your project. > >>> > >>> I also think that the ArtifactResolver is not required here. > >>> It's like instead of passing a string-based version, you'd like to pass > >>> an > >>> artifact and extract it's version. > >>> My idea is the other way around: extract the version from the artifact > >>> first and pass that to the policy. > >>> I would expect it to be the version in the pom.xml. If you want to > check > >>> it, use an enforcer rule or something like that. > >>> > >>> We should try to keep the task of this class as simple as possible. > >>> > >>> Robert > >>> > >>> Op Thu, 13 Mar 2014 13:55:43 +0100 schreef Simone Tripodi < > >>> [email protected]>: > >>> > >>> > >>> Hi again Robert, > >>> > >>>> > >>>> sorry for bugging - I hope I don't :P - but I notice Metadata also has > >>>> a very limited subset of informations about the ongoing released > >>>> artifact. > >>>> IMHO informations such us packaging and classifier should be part of > >>>> that data set - maybe I am wrong and work around that? > >>>> > >>>> TIA, All the best! > >>>> -Simo > >>>> > >>>> http://people.apache.org/~simonetripodi/ > >>>> http://twitter.com/simonetripodi > >>>> > >>>> > >>>> On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte <[email protected] > > > >>>> wrote: > >>>> > >>>> Hi Simone, > >>>>> > >>>>> for that reason I've added the Metadata, from which you can get the > >>>>> latest > >>>>> released artifact. > >>>>> I really hope you don't need the ArtifactResolver. > >>>>> > >>>>> Robert > >>>>> > >>>>> Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi > >>>>> <[email protected]>: > >>>>> > >>>>> > >>>>> Hi again Robert, > >>>>> > >>>>>> > >>>>>> in one of my VersionPolicy implementations, I need to resolve the > >>>>>> latest release artifact - then I have a tool to compare the > bytecodes > >>>>>> and automatically understand which is the release number. > >>>>>> > >>>>>> Question is: while I need an ArtifactResolver, I also need > >>>>>> ArtifactRepository for local/remotes that, inside a MOJO, would be > get > >>>>>> via the code below... what are the related Plexus annotations, in > >>>>>> order to obtain the same components? > >>>>>> > >>>>>> TIA, all the best! > >>>>>> -Simo > >>>>>> > >>>>>> @Parameter(required = true, defaultValue = "${localRepository}", > >>>>>> readonly = true) > >>>>>> private ArtifactRepository localRepository; > >>>>>> > >>>>>> @Parameter(required = true, defaultValue = > >>>>>> "${project.remoteArtifactRepositories}", readonly = true) > >>>>>> private List<ArtifactRepository> remoteRepositories; > >>>>>> http://people.apache.org/~simonetripodi/ > >>>>>> http://twitter.com/simonetripodi > >>>>>> > >>>>>> > >>>>>> On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte < > [email protected] > >>>>>> > > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>>> Hi Simone, > >>>>>>> > >>>>>>> I still have to find a solution for the VersionParseException which > >>>>>>> can > >>>>>>> be > >>>>>>> thrown with the current implementation of DefaultVersionInfo. I > >>>>>>> probably > >>>>>>> have to add it to both methods of VersionPolicy > >>>>>>> > >>>>>>> Your custom implementation will look something like: > >>>>>>> > >>>>>>> @Component( role = VersionPolicy.class, hint = "tripodi" ) > >>>>>>> public class TripodiVersionPolicy implements VersionPolicy { > >>>>>>> // your stuff > >>>>>>> } > >>>>>>> > >>>>>>> The plugin will get parameters like projectVersionPolicyId and/or > >>>>>>> dependencyVersionPolicyId. > >>>>>>> At least, that's my idea right now to split it up per type. This > way > >>>>>>> implementations can stay as clean as possible. > >>>>>>> > >>>>>>> Robert > >>>>>>> > >>>>>>> Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi > >>>>>>> <[email protected]>: > >>>>>>> > >>>>>>> > >>>>>>> Hi again Robert, > >>>>>>> > >>>>>>>> > >>>>>>>> new APIs look reasonable and easily extensible to me, thanks for > >>>>>>>> putting > >>>>>>>> effort on that! > >>>>>>>> I maybe missed something but I didn't notice how they are > integrated > >>>>>>>> in > >>>>>>>> the > >>>>>>>> core module... > >>>>>>>> TIA all the best! > >>>>>>>> -Simo > >>>>>>>> > >>>>>>>> > >>>>>>>> http://people.apache.org/~simonetripodi/ > >>>>>>>> http://twitter.com/simonetripodi > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte < > >>>>>>>> [email protected]> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> Hi Simone, > >>>>>>>> > >>>>>>>>> > >>>>>>>>> I've added a new module for Maven release policies including my > >>>>>>>>> idea > >>>>>>>>> of > >>>>>>>>> how the API should look like. > >>>>>>>>> Although one of my suggestions to specify this as an > implementation > >>>>>>>>> in > >>>>>>>>> the > >>>>>>>>> plugin configuration, I now prefer to use it as a component. > >>>>>>>>> Downside > >>>>>>>>> is > >>>>>>>>> that you can't use a pojo, you'll need to add Plexus annotations > >>>>>>>>> and > >>>>>>>>> generate the descriptor. However, now you can inject other > >>>>>>>>> components > >>>>>>>>> a.k.a > >>>>>>>>> requirements. Since this might become quite complicated, > injection > >>>>>>>>> is > >>>>>>>>> probably the preferred way. > >>>>>>>>> I probably need more info in the PolicyRequest to support the > >>>>>>>>> current > >>>>>>>>> behavior, but this is just a start. > >>>>>>>>> This should be a good start for you too. Let me know if this will > >>>>>>>>> work > >>>>>>>>> with your requirements. > >>>>>>>>> > >>>>>>>>> best, > >>>>>>>>> Robert > >>>>>>>>> > >>>>>>>>> Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi < > >>>>>>>>> [email protected]>: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hi Rob! :) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> indeed it has been a very long while, so sorry for that :( > >>>>>>>>>> > >>>>>>>>>> OK I understand your PoV, count on me if you want to co-operate > - > >>>>>>>>>> I > >>>>>>>>>> need > >>>>>>>>>> that feature as well in order to make the release-plugin able to > >>>>>>>>>> generate > >>>>>>>>>> that version using a tool, but without exposing such APIs that > >>>>>>>>>> allow > >>>>>>>>>> me > >>>>>>>>>> plugging different versioning systems, I cannot do it :) > >>>>>>>>>> > >>>>>>>>>> Many thanks in advance and have a nice weekend! > >>>>>>>>>> All the best! > >>>>>>>>>> -Simo > >>>>>>>>>> > >>>>>>>>>> http://people.apache.org/~simonetripodi/ > >>>>>>>>>> http://twitter.com/simonetripodi > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte < > >>>>>>>>>> [email protected] > >>>>>>>>>> >wrote: > >>>>>>>>>> > >>>>>>>>>> Hi Simone, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> It's been a while, so I'll need to have another look at this. > >>>>>>>>>>> At first glance I'm not yet happy with the suggested API. > >>>>>>>>>>> I'd need to make some time so come with a final solution. > >>>>>>>>>>> > >>>>>>>>>>> Robert > >>>>>>>>>>> > >>>>>>>>>>> Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi < > >>>>>>>>>>> [email protected]>: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Hi all mates, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> I am in a phase where I could get benefit of that feature as > >>>>>>>>>>>> well > >>>>>>>>>>>> (and, > >>>>>>>>>>>> since I am still in the committer list, I can provide some > help > >>>>>>>>>>>> here) > >>>>>>>>>>>> so I > >>>>>>>>>>>> would like to push it :P > >>>>>>>>>>>> > >>>>>>>>>>>> @Robert: before merging the contribution we received in JIRA, > >>>>>>>>>>>> I'd > >>>>>>>>>>>> kindly > >>>>>>>>>>>> ask if you had a better idea if new API has to be in > >>>>>>>>>>>> the maven-release-manager or in a separate module. > >>>>>>>>>>>> > >>>>>>>>>>>> Many thanks in advance, all the best! > >>>>>>>>>>>> -Simo > >>>>>>>>>>>> > >>>>>>>>>>>> http://people.apache.org/~simonetripodi/ > >>>>>>>>>>>> http://twitter.com/simonetripodi > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> ------------------------------------------------------------ > >>>>>>>>>>>> > >>>>>>>>>>> --------- > >>>>>>>>>>> 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] > >>>>>> > >>>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> 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] > > > > >
