Hi Robert, +1 - given my current experimental implementation, I am convinced that declaring the VersionPolicy as component is the way to go, so I can even inject whatever I need in order to implement my policy to increase versions :)
Thanks, -Simo 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]
