Hi Rob! I honestly need to access to latest released physical artifact, because I need to wrap a tool which is able to detect bytecode differences between the latest released artifact and the current ongoing "to be released", then gives an estimation on which version number should be released.
Many thanks in advance, 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]
