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]
