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] > >
