Hello Robert, thanks a lot for your help, much more than appreciated!
> > I've added the projectVersionPolicyId to the releaseDescriptor. We might > need to add dependencyVersionPolicyId, parentVersionPolicyId and > pluginVersionPolicyId in the future as well. > So the manager is ready to switch from implementation, which should be > enough for unittesting. > We still need to make it available for the plugin. > do you already have an idea how? I may can provide a patch for that... > I think most version policies should have their own project+release-cycle, > but it seems like the odd-even is a common policy, so I don't mind making it > a separate module which will be part of the maven-release project. > We can probably do something like enforcer: make a standard-policies module > with common implementation. I am by your side! > Although for now I wouldn't make it add it as dependency to the manager, > users can do that themselves if they want. > +1, I didn't touch indeed anything else than the new module and the reactor indeed, the odd-even policy impl has not to be part of the > Robert All the best, -Simo -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi > > > Op Fri, 21 Mar 2014 12:56:02 +0100 schreef Simone Tripodi > <[email protected]>: > > >> Hi again Robert, >> >> IIUC the VersionPolicy resolution in `Map<String, VersionPolicy> >> versionPolicies` is strict to "default" only, moreover I didn't >> understand where/how to specify, in the plugin configuration, the >> `hint` of my VersionPolicy implementation... >> >> As a side note, I already have, in my local copy of the source code, a >> separated module with the odd-even policy implementation, included in >> the build - if there are not objections, I'd commit it, just let me >> know! >> >> All the best! >> -Simo >> http://people.apache.org/~simonetripodi/ >> http://twitter.com/simonetripodi >> >> >> On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte <[email protected]> >> wrote: >>> >>> Hi Simone, >>> >>> http://svn.apache.org/r1578613 contains the default implementation for >>> the >>> maven-release-manager. >>> Now it should be quite easy to test other policies. >>> >>> thanks, >>> >>> Robert >>> >>> ps. Alles Gute? Ja, alles goed ;) (my name looks too German, I guess) >>> >>> Op Mon, 17 Mar 2014 09:30:15 +0100 schreef Simone Tripodi >>> <[email protected]>: >>> >>> >>>> Hi Robert, >>>> >>>> after an internal discussion with my colleagues, we are ATM fine with >>>> just implementing the odd-even policy, so let's forget my prototype >>>> ATM, we are fine with current new APIs. >>>> >>>> Is there anything I can help you in order to have them integrated in >>>> the release-plugin? >>>> >>>> TIA, Alles Gute! >>>> -Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://twitter.com/simonetripodi >>>> >>>> >>>> On Fri, Mar 14, 2014 at 3:03 PM, Simone Tripodi >>>> <[email protected]> wrote: >>>>> >>>>> >>>>> Hi Robert, >>>>> >>>>> yes I agree, while making my prototype - it will be opensourced, by >>>>> the way - I also realised that my Policy implementation is the wrong >>>>> Maven phase: when asking for the next release version, it is supposed >>>>> that current doesn't exist yet (unless someone publishes the SNAPSHOT, >>>>> even locally) so artifact diff cannot be executed. >>>>> That would force users configuring the release plugin in order to >>>>> invoke the `package` first... >>>>> >>>>> I don't have strong opinions ATM on how the new interface should look >>>>> alike... >>>>> >>>>> Thanks a lot for you efforts! >>>>> -Simo >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://twitter.com/simonetripodi >>>>> >>>>> >>>>> On Fri, Mar 14, 2014 at 12:58 PM, Robert Scholte <[email protected]> >>>>> wrote: >>>>>> >>>>>> >>>>>> Hi Simone, >>>>>> >>>>>> I think what you want is a way to make clear what kind of release it >>>>>> will >>>>>> be: major, minor, bugfix/micro. >>>>>> That's something which can be added to the request and looks >>>>>> reasonable >>>>>> for >>>>>> all policies. I'm not sure if an enum is correct here, any founded >>>>>> suggestion is welcome. >>>>>> However, the calculation what kind of of release it should be, belongs >>>>>> in >>>>>> another class in my opinion. >>>>>> So let's think of another interface :) >>>>>> >>>>>> Robert >>>>>> >>>>>> >>>>>> Op Fri, 14 Mar 2014 10:10:55 +0100 schreef Simone Tripodi >>>>>> <[email protected]>: >>>>>> >>>>>> >>>>>>> Hi Rob, >>>>>>> >>>>>>> thanks a lot for the detailed feedback, very appreciated :) >>>>>>> >>>>>>> I just realise I didn't pass you enough informations to better >>>>>>> understand the new context we are working on: in the OSGi world, >>>>>>> aside >>>>>>> the odd-even policy, we would like to wrap BND[1] APis which allow >>>>>>> compare two bundles and understand, via bytecode analysis[2], which >>>>>>> should be the suggested version; that is why I need the >>>>>>> ArtifactResolver, in order to get the latest released artifact (or >>>>>>> specify the version, somehow) and compare it to the one is going to >>>>>>> be >>>>>>> released, in order let BND calculate the suggested version. >>>>>>> >>>>>>> I hope that scenario makes more clear why I asked how to inject other >>>>>>> components! >>>>>>> >>>>>>> All the best! >>>>>>> -Simo >>>>>>> >>>>>>> [1] http://www.aqute.biz/Bnd/ >>>>>>> [2] http://www.aqute.biz/Bnd/Versioning >>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>> http://twitter.com/simonetripodi >>>>>>> >>>>>>> >>>>>>> On Thu, Mar 13, 2014 at 7:19 PM, 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] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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]
