Hi Robert! sorry to come back so late, got busy with other stuff at work :(
Thanks *a lot* for providing APIs change - I am going to test them in the afternoon! Since I have karma on Mvn repo... would it make sense I contribute directly there the odd-even policy implementation? Maybe in a separated module? It costs 0 to me... just let me know! :) Have a nice day! -Simo PS apologise, but since I joined Adobe CH, I write "Alles Gute" automatically without even thinking who's the receiver I am writing :D 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]
