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]
