You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Simone Tripodi <si...@apache.org> on 2014/02/28 14:56:35 UTC
MRELEASE-431
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
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
Hi Robert!
amazing, I am having a look at it ASAP - anyway, DI sounds to be the way to
go :)
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte <rf...@apache.org> 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 <
> simonetripodi@apache.org>:
>
>
> 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 <rfscholte@apache.org
>> >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 <
>>> simonetripodi@apache.org>:
>>>
>>>
>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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 <rf...@apache.org> 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
> <si...@apache.org>:
>
>
>> 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 <rf...@apache.org>
>> 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 <
>>> simonetripodi@apache.org>:
>>>
>>>
>>> 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 <rfscholte@apache.org
>>>> >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 <
>>>>> simonetripodi@apache.org>:
>>>>>
>>>>>
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
Hi Igor,
There will be an option to specify the specific release version to
handle such situations, but let's do one step at a time :)
best,
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 2:05 PM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> Out of curiosity, how do you plan to deal with multiple development
> streams with different "latest version" depending on the stream? If, for
> example, somebody decided to release maven 3.0.6, it'd need to be
> compared to 3.0.5, not 3.2.1.
>
> --
> Regards,
> Igor
>
>
> On 2014-03-12, 8:30, Simone Tripodi wrote:
>>
>> 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 <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>>> 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 <rf...@apache.org>
>>>> 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 <
>>>>> simonetripodi@apache.org>:
>>>>>
>>>>>
>>>>> 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 <rfscholte@apache.org
>>>>>>>
>>>>>>> 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 <
>>>>>>> simonetripodi@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
Out of curiosity, how do you plan to deal with multiple development
streams with different "latest version" depending on the stream? If, for
example, somebody decided to release maven 3.0.6, it'd need to be
compared to 3.0.5, not 3.2.1.
--
Regards,
Igor
On 2014-03-12, 8:30, Simone Tripodi wrote:
> 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 <rf...@apache.org> 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
>> <si...@apache.org>:
>>
>>
>>> 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 <rf...@apache.org>
>>> 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 <
>>>> simonetripodi@apache.org>:
>>>>
>>>>
>>>> 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 <rfscholte@apache.org
>>>>>> 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 <
>>>>>> simonetripodi@apache.org>:
>>>>>>
>>>>>>
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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 <rf...@apache.org> 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
> <si...@apache.org>:
>
>
>> 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
>> <si...@apache.org> 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 <rf...@apache.org>
>>> 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
>>>> <si...@apache.org>:
>>>>
>>>>
>>>>> 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 <rf...@apache.org>
>>>>> 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
>>>>>> <si...@apache.org>:
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>> <rf...@apache.org>
>>>>>>> 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
>>>>>>>> <si...@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> <rf...@apache.org>
>>>>>>>>> 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
>>>>>>>>>> <si...@apache.org>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>>> 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 <
>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>>>>> >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 <
>>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
Hello Robert,
thanks a lot for your help, much more than appreciated!
>
> I've added the projectVersionPolicyId to the releaseDescriptor. We might
> need to add dependencyVersionPolicyId, parentVersionPolicyId and
> pluginVersionPolicyId in the future as well.
> So the manager is ready to switch from implementation, which should be
> enough for unittesting.
> We still need to make it available for the plugin.
>
do you already have an idea how? I may can provide a patch for that...
> I think most version policies should have their own project+release-cycle,
> but it seems like the odd-even is a common policy, so I don't mind making it
> a separate module which will be part of the maven-release project.
> We can probably do something like enforcer: make a standard-policies module
> with common implementation.
I am by your side!
> Although for now I wouldn't make it add it as dependency to the manager,
> users can do that themselves if they want.
>
+1, I didn't touch indeed anything else than the new module and the
reactor indeed, the odd-even policy impl has not to be part of the
> Robert
All the best,
-Simo
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
>
>
> Op Fri, 21 Mar 2014 12:56:02 +0100 schreef Simone Tripodi
> <si...@apache.org>:
>
>
>> Hi again Robert,
>>
>> IIUC the VersionPolicy resolution in `Map<String, VersionPolicy>
>> versionPolicies` is strict to "default" only, moreover I didn't
>> understand where/how to specify, in the plugin configuration, the
>> `hint` of my VersionPolicy implementation...
>>
>> As a side note, I already have, in my local copy of the source code, a
>> separated module with the odd-even policy implementation, included in
>> the build - if there are not objections, I'd commit it, just let me
>> know!
>>
>> All the best!
>> -Simo
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>>
>> On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>>> 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
>>>> <si...@apache.org> 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 <rf...@apache.org>
>>>>> 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
>>>>>> <si...@apache.org>:
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>> <rf...@apache.org>
>>>>>>> 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
>>>>>>>> <si...@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> <rf...@apache.org>
>>>>>>>>> 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
>>>>>>>>>> <si...@apache.org>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>>> 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
>>>>>>>>>>>> <si...@apache.org>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>>>>>>> >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 <
>>>>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
Hi again Robert,
I checked in the odd-even module in r1580793 - every
feedback/suggestion/... is, as usual, much more than welcome and
appreciated :)
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 22, 2014 at 1:10 PM, Robert Scholte <rf...@apache.org> wrote:
> Hi Simone,
>
> I've added the projectVersionPolicyId to the releaseDescriptor. We might
> need to add dependencyVersionPolicyId, parentVersionPolicyId and
> pluginVersionPolicyId in the future as well.
> So the manager is ready to switch from implementation, which should be
> enough for unittesting.
> We still need to make it available for the plugin.
>
> I think most version policies should have their own project+release-cycle,
> but it seems like the odd-even is a common policy, so I don't mind making it
> a separate module which will be part of the maven-release project.
> We can probably do something like enforcer: make a standard-policies module
> with common implementation.
> Although for now I wouldn't make it add it as dependency to the manager,
> users can do that themselves if they want.
>
> Robert
>
>
> Op Fri, 21 Mar 2014 12:56:02 +0100 schreef Simone Tripodi
> <si...@apache.org>:
>
>
>> Hi again Robert,
>>
>> IIUC the VersionPolicy resolution in `Map<String, VersionPolicy>
>> versionPolicies` is strict to "default" only, moreover I didn't
>> understand where/how to specify, in the plugin configuration, the
>> `hint` of my VersionPolicy implementation...
>>
>> As a side note, I already have, in my local copy of the source code, a
>> separated module with the odd-even policy implementation, included in
>> the build - if there are not objections, I'd commit it, just let me
>> know!
>>
>> All the best!
>> -Simo
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>>
>>
>> On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>>> 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
>>>> <si...@apache.org> 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 <rf...@apache.org>
>>>>> 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
>>>>>> <si...@apache.org>:
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>> <rf...@apache.org>
>>>>>>> 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
>>>>>>>> <si...@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> <rf...@apache.org>
>>>>>>>>> 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
>>>>>>>>>> <si...@apache.org>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>>> 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
>>>>>>>>>>>> <si...@apache.org>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>>>>>>> >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 <
>>>>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
Hi Simone,
I've added the projectVersionPolicyId to the releaseDescriptor. We might
need to add dependencyVersionPolicyId, parentVersionPolicyId and
pluginVersionPolicyId in the future as well.
So the manager is ready to switch from implementation, which should be
enough for unittesting.
We still need to make it available for the plugin.
I think most version policies should have their own project+release-cycle,
but it seems like the odd-even is a common policy, so I don't mind making
it a separate module which will be part of the maven-release project.
We can probably do something like enforcer: make a standard-policies
module with common implementation.
Although for now I wouldn't make it add it as dependency to the manager,
users can do that themselves if they want.
Robert
Op Fri, 21 Mar 2014 12:56:02 +0100 schreef Simone Tripodi
<si...@apache.org>:
> Hi again Robert,
>
> IIUC the VersionPolicy resolution in `Map<String, VersionPolicy>
> versionPolicies` is strict to "default" only, moreover I didn't
> understand where/how to specify, in the plugin configuration, the
> `hint` of my VersionPolicy implementation...
>
> As a side note, I already have, in my local copy of the source code, a
> separated module with the odd-even policy implementation, included in
> the build - if there are not objections, I'd commit it, just let me
> know!
>
> All the best!
> -Simo
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi
>
>
> On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte <rf...@apache.org>
> 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
>> <si...@apache.org>:
>>
>>
>>> 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
>>> <si...@apache.org> 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
>>>> <rf...@apache.org>
>>>> 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
>>>>> <si...@apache.org>:
>>>>>
>>>>>
>>>>>> 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
>>>>>> <rf...@apache.org>
>>>>>> 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
>>>>>>> <si...@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>>>>>> <rf...@apache.org>
>>>>>>>> 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
>>>>>>>>> <si...@apache.org>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>> 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
>>>>>>>>>>> <si...@apache.org>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>>>>>> >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 <
>>>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
Hi again Robert,
IIUC the VersionPolicy resolution in `Map<String, VersionPolicy>
versionPolicies` is strict to "default" only, moreover I didn't
understand where/how to specify, in the plugin configuration, the
`hint` of my VersionPolicy implementation...
As a side note, I already have, in my local copy of the source code, a
separated module with the odd-even policy implementation, included in
the build - if there are not objections, I'd commit it, just let me
know!
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 17, 2014 at 10:51 PM, Robert Scholte <rf...@apache.org> 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
> <si...@apache.org>:
>
>
>> 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
>> <si...@apache.org> 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 <rf...@apache.org>
>>> 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
>>>> <si...@apache.org>:
>>>>
>>>>
>>>>> 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 <rf...@apache.org>
>>>>> 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
>>>>>> <si...@apache.org>:
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>> <rf...@apache.org>
>>>>>>> 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
>>>>>>>> <si...@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> <rf...@apache.org>
>>>>>>>>> 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
>>>>>>>>>> <si...@apache.org>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>>> 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 <
>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>>>>> >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 <
>>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
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
<si...@apache.org>:
> 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
> <si...@apache.org> 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 <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>>> 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 <rf...@apache.org>
>>>> 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
>>>>> <si...@apache.org>:
>>>>>
>>>>>
>>>>>> 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
>>>>>> <rf...@apache.org>
>>>>>> 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
>>>>>>> <si...@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>>>>>> <rf...@apache.org>
>>>>>>>> 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
>>>>>>>>> <si...@apache.org>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>> 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 <
>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>>>> >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 <
>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
I'm struggling with some plexus configuration issues. I could send you my
current patch if you like.
Robert
Op Mon, 17 Mar 2014 09:30:15 +0100 schreef Simone Tripodi
<si...@apache.org>:
> 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
> <si...@apache.org> 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 <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>>> 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 <rf...@apache.org>
>>>> 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
>>>>> <si...@apache.org>:
>>>>>
>>>>>
>>>>>> 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
>>>>>> <rf...@apache.org>
>>>>>> 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
>>>>>>> <si...@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>>>>>> <rf...@apache.org>
>>>>>>>> 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
>>>>>>>>> <si...@apache.org>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> <rf...@apache.org>
>>>>>>>>>> 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 <
>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>>>> >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 <
>>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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
<si...@apache.org> 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 <rf...@apache.org> 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
>> <si...@apache.org>:
>>
>>
>>> 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 <rf...@apache.org>
>>> 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
>>>> <si...@apache.org>:
>>>>
>>>>
>>>>> 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 <rf...@apache.org>
>>>>> 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
>>>>>> <si...@apache.org>:
>>>>>>
>>>>>>
>>>>>>> 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 <rf...@apache.org>
>>>>>>> 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
>>>>>>>> <si...@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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
>>>>>>>>> <rf...@apache.org>
>>>>>>>>> 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 <
>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>>> >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 <
>>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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 <rf...@apache.org> 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
> <si...@apache.org>:
>
>
>> 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 <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>>> 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 <rf...@apache.org>
>>>> 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
>>>>> <si...@apache.org>:
>>>>>
>>>>>
>>>>>> 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 <rf...@apache.org>
>>>>>> 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
>>>>>>> <si...@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>>> 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
>>>>>>>> <rf...@apache.org>
>>>>>>>> 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 <
>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>> <rfscholte@apache.org
>>>>>>>>>> >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 <
>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
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
<si...@apache.org>:
> 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 <rf...@apache.org>
> 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
>> <si...@apache.org>:
>>
>>
>>> 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 <rf...@apache.org>
>>> 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
>>>> <si...@apache.org>:
>>>>
>>>>
>>>>> 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
>>>>> <rf...@apache.org>
>>>>> 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
>>>>>> <si...@apache.org>:
>>>>>>
>>>>>>
>>>>>>> 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
>>>>>>> <rf...@apache.org>
>>>>>>> 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 <
>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>> <rfscholte@apache.org
>>>>>>>>> >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 <
>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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 <rf...@apache.org> 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
> <si...@apache.org>:
>
>
>> 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 <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>>> 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 <rf...@apache.org>
>>>> 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
>>>>> <si...@apache.org>:
>>>>>
>>>>>
>>>>>> 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 <rf...@apache.org>
>>>>>> 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 <
>>>>>>> simonetripodi@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>> <rfscholte@apache.org
>>>>>>>> >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 <
>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
Op Fri, 14 Mar 2014 10:25:59 +0100 schreef Baptiste Mathus
<bm...@batmat.net>:
> 2014-03-13 19:19 GMT+01:00 Robert Scholte <rf...@apache.org>:
>
>> 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.
>>
>
> FWIW, I'm also interested by this feature to further standardize our
> release process. And we'd ideally need at least the artifactId to be able
> to calculate the next developmentVersion. To make it short, the suffix of
> our artifactIds describe if it's an internal implementation project, or
> if
> it's an globally visible interface.
>
> In the second case, since this is a publicly published/used, the
> versioning
> is not the same and kind of more agressively checked (which seems similar
> to what Simone is describing in their bytecode analysis approach).
>
> HTH
>
> -- Baptiste
Looks to me that the suffix has no influence on the calculation of dev and
rel versions, it's something which can be added later in the process as
well.
But correct me if I'm wrong :)
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
Hi Chris,
This is already the default behavior[1]. No reason to change it, just have
to move it to the DefaultVersionPolicy.
Robert
[1]
http://maven.apache.org/maven-release/maven-release-manager/xref/org/apache/maven/shared/release/versions/DefaultVersionInfo.html
Op Sun, 16 Mar 2014 05:31:10 +0100 schreef Chris Graham
<ch...@gmail.com>:
> Is that going to deal with versions such as 2.6-beta-9? As currently
> exist?
>
> -Chris
>
>
> On Fri, Mar 14, 2014 at 8:25 PM, Baptiste Mathus <bm...@batmat.net>
> wrote:
>
>> 2014-03-13 19:19 GMT+01:00 Robert Scholte <rf...@apache.org>:
>>
>> > 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.
>> >
>>
>> FWIW, I'm also interested by this feature to further standardize our
>> release process. And we'd ideally need at least the artifactId to be
>> able
>> to calculate the next developmentVersion. To make it short, the suffix
>> of
>> our artifactIds describe if it's an internal implementation project, or
>> if
>> it's an globally visible interface.
>>
>> In the second case, since this is a publicly published/used, the
>> versioning
>> is not the same and kind of more agressively checked (which seems
>> similar
>> to what Simone is describing in their bytecode analysis approach).
>>
>> HTH
>>
>> -- Baptiste
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Chris Graham <ch...@gmail.com>.
Is that going to deal with versions such as 2.6-beta-9? As currently exist?
-Chris
On Fri, Mar 14, 2014 at 8:25 PM, Baptiste Mathus <bm...@batmat.net> wrote:
> 2014-03-13 19:19 GMT+01:00 Robert Scholte <rf...@apache.org>:
>
> > 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.
> >
>
> FWIW, I'm also interested by this feature to further standardize our
> release process. And we'd ideally need at least the artifactId to be able
> to calculate the next developmentVersion. To make it short, the suffix of
> our artifactIds describe if it's an internal implementation project, or if
> it's an globally visible interface.
>
> In the second case, since this is a publicly published/used, the versioning
> is not the same and kind of more agressively checked (which seems similar
> to what Simone is describing in their bytecode analysis approach).
>
> HTH
>
> -- Baptiste
>
Re: MRELEASE-431
Posted by Baptiste Mathus <bm...@batmat.net>.
2014-03-13 19:19 GMT+01:00 Robert Scholte <rf...@apache.org>:
> 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.
>
FWIW, I'm also interested by this feature to further standardize our
release process. And we'd ideally need at least the artifactId to be able
to calculate the next developmentVersion. To make it short, the suffix of
our artifactIds describe if it's an internal implementation project, or if
it's an globally visible interface.
In the second case, since this is a publicly published/used, the versioning
is not the same and kind of more agressively checked (which seems similar
to what Simone is describing in their bytecode analysis approach).
HTH
-- Baptiste
Re: MRELEASE-431
Posted by Paul Benedict <pb...@apache.org>.
I think everything after the third digit becomes a lexographic compare.
That is why three behavior is unexpected to you. This is not an issue with
the standard three numbers.
On Mar 16, 2014 7:39 PM, "Chris Graham" <ch...@gmail.com> wrote:
> I've been using the 4 digit versions with the release plugin for the last 6
> years or so.
> I've never used ranges, as I either thought there was a problem with them
> and the release plugin.
> So if 1.0.0.10 comes before 1.0.0.9, wouldn't 1.0.10 therefor come before
> 1.0.9?
>
> -Chris
>
>
> On Sun, Mar 16, 2014 at 8:55 PM, Robert Scholte <rfscholte@apache.org
> >wrote:
>
> > Hi Chris,
> >
> > the input is a String, so it's possible to support as many digits as you
> > can.
> > However, an ArtifactVersion [1] doesn't support that much digits, so I'll
> > lock it to 3 to keep the current Maven versioning style. When working
> with
> > ranges 1.0.0.10 comes before 1.0.0.9 because the part after the second
> dot
> > can't be handled as an Integer, so it is handled as a String. For that
> > reason the Maven Release plugin shouldn't be able to generate such
> > versions. If you are aware of this and never use ranges, you are safe
> (but
> > not your consumers ;) )
> >
> > Robert
> >
> > [1] http://maven.apache.org/ref/3.2.1/maven-artifact/apidocs/
> > org/apache/maven/artifact/versioning/ArtifactVersion.html
> >
> > Op Sun, 16 Mar 2014 05:30:12 +0100 schreef Chris Graham <
> > chrisgwarp@gmail.com>:
> >
> >
> > Hi Robert.
> >>
> >> Just a request, can you please test to 4 (that I always use) and 5
> digits,
> >> that sometimes I have to use?
> >>
> >> Ie
> >> 1.0.0.1-SNAPSHOT
> >> and
> >> 1.0.0.1.1-SNAPSHOT
> >>
> >> If you can, it might save me quite a bit of work later on. The release
> >> plugin copes with 4 digits, but not 5 (from what I can see in the code).
> >>
> >> Ta.
> >>
> >> -Chris
> >>
> >>
> >>
> >> On Fri, Mar 14, 2014 at 5:19 AM, Robert Scholte <rfscholte@apache.org
> >> >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 <
> >>> simonetripodi@apache.org>:
> >>>
> >>>
> >>> 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 <rfscholte@apache.org
> >
> >>>> 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
> >>>>> <si...@apache.org>:
> >>>>>
> >>>>>
> >>>>> 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 <
> rfscholte@apache.org
> >>>>>> >
> >>>>>> 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
> >>>>>>> <si...@apache.org>:
> >>>>>>>
> >>>>>>>
> >>>>>>> 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 <
> >>>>>>>> rfscholte@apache.org>
> >>>>>>>> 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 <
> >>>>>>>>> simonetripodi@apache.org>:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 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 <
> >>>>>>>>>> rfscholte@apache.org
> >>>>>>>>>> >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 <
> >>>>>>>>>>> simonetripodi@apache.org>:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> ------------------------------------------------------------
> >>>>>>>>>>>
> >>>>>>>>>> ---------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ------------------------------------------------------------
> >>>>>>> ---------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>> ------------------------------------------------------------
> >>>>>> ---------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>>
> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: MRELEASE-431
Posted by Chris Graham <ch...@gmail.com>.
I've been using the 4 digit versions with the release plugin for the last 6
years or so.
I've never used ranges, as I either thought there was a problem with them
and the release plugin.
So if 1.0.0.10 comes before 1.0.0.9, wouldn't 1.0.10 therefor come before
1.0.9?
-Chris
On Sun, Mar 16, 2014 at 8:55 PM, Robert Scholte <rf...@apache.org>wrote:
> Hi Chris,
>
> the input is a String, so it's possible to support as many digits as you
> can.
> However, an ArtifactVersion [1] doesn't support that much digits, so I'll
> lock it to 3 to keep the current Maven versioning style. When working with
> ranges 1.0.0.10 comes before 1.0.0.9 because the part after the second dot
> can't be handled as an Integer, so it is handled as a String. For that
> reason the Maven Release plugin shouldn't be able to generate such
> versions. If you are aware of this and never use ranges, you are safe (but
> not your consumers ;) )
>
> Robert
>
> [1] http://maven.apache.org/ref/3.2.1/maven-artifact/apidocs/
> org/apache/maven/artifact/versioning/ArtifactVersion.html
>
> Op Sun, 16 Mar 2014 05:30:12 +0100 schreef Chris Graham <
> chrisgwarp@gmail.com>:
>
>
> Hi Robert.
>>
>> Just a request, can you please test to 4 (that I always use) and 5 digits,
>> that sometimes I have to use?
>>
>> Ie
>> 1.0.0.1-SNAPSHOT
>> and
>> 1.0.0.1.1-SNAPSHOT
>>
>> If you can, it might save me quite a bit of work later on. The release
>> plugin copes with 4 digits, but not 5 (from what I can see in the code).
>>
>> Ta.
>>
>> -Chris
>>
>>
>>
>> On Fri, Mar 14, 2014 at 5:19 AM, Robert Scholte <rfscholte@apache.org
>> >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 <
>>> simonetripodi@apache.org>:
>>>
>>>
>>> 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 <rf...@apache.org>
>>>> 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
>>>>> <si...@apache.org>:
>>>>>
>>>>>
>>>>> 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 <rfscholte@apache.org
>>>>>> >
>>>>>> 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
>>>>>>> <si...@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>> 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 <
>>>>>>>> rfscholte@apache.org>
>>>>>>>> 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 <
>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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 <
>>>>>>>>>> rfscholte@apache.org
>>>>>>>>>> >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 <
>>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>> ---------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>> ---------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
Hi Chris,
the input is a String, so it's possible to support as many digits as you
can.
However, an ArtifactVersion [1] doesn't support that much digits, so I'll
lock it to 3 to keep the current Maven versioning style. When working with
ranges 1.0.0.10 comes before 1.0.0.9 because the part after the second dot
can't be handled as an Integer, so it is handled as a String. For that
reason the Maven Release plugin shouldn't be able to generate such
versions. If you are aware of this and never use ranges, you are safe (but
not your consumers ;) )
Robert
[1]
http://maven.apache.org/ref/3.2.1/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ArtifactVersion.html
Op Sun, 16 Mar 2014 05:30:12 +0100 schreef Chris Graham
<ch...@gmail.com>:
> Hi Robert.
>
> Just a request, can you please test to 4 (that I always use) and 5
> digits,
> that sometimes I have to use?
>
> Ie
> 1.0.0.1-SNAPSHOT
> and
> 1.0.0.1.1-SNAPSHOT
>
> If you can, it might save me quite a bit of work later on. The release
> plugin copes with 4 digits, but not 5 (from what I can see in the code).
>
> Ta.
>
> -Chris
>
>
>
> On Fri, Mar 14, 2014 at 5:19 AM, Robert Scholte
> <rf...@apache.org>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 <
>> simonetripodi@apache.org>:
>>
>>
>> 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 <rf...@apache.org>
>>> 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
>>>> <si...@apache.org>:
>>>>
>>>>
>>>> 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
>>>>> <rf...@apache.org>
>>>>> 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
>>>>>> <si...@apache.org>:
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>> <rf...@apache.org>
>>>>>>> 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 <
>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>> 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 <
>>>>>>>>> rfscholte@apache.org
>>>>>>>>> >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 <
>>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------
>>>>>>>> ---------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Chris Graham <ch...@gmail.com>.
Hi Robert.
Just a request, can you please test to 4 (that I always use) and 5 digits,
that sometimes I have to use?
Ie
1.0.0.1-SNAPSHOT
and
1.0.0.1.1-SNAPSHOT
If you can, it might save me quite a bit of work later on. The release
plugin copes with 4 digits, but not 5 (from what I can see in the code).
Ta.
-Chris
On Fri, Mar 14, 2014 at 5:19 AM, Robert Scholte <rf...@apache.org>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 <
> simonetripodi@apache.org>:
>
>
> 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 <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>> 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 <rf...@apache.org>
>>>> 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
>>>>> <si...@apache.org>:
>>>>>
>>>>>
>>>>> 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 <rf...@apache.org>
>>>>>> 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 <
>>>>>>> simonetripodi@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>> 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 <
>>>>>>>> rfscholte@apache.org
>>>>>>>> >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 <
>>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
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
<si...@apache.org>:
> 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 <rf...@apache.org>
> 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
>> <si...@apache.org>:
>>
>>
>>> 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 <rf...@apache.org>
>>> 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
>>>> <si...@apache.org>:
>>>>
>>>>
>>>>> 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 <rf...@apache.org>
>>>>> 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 <
>>>>>> simonetripodi@apache.org>:
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>> <rfscholte@apache.org
>>>>>>> >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 <
>>>>>>>> simonetripodi@apache.org>:
>>>>>>>>
>>>>>>>>
>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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 <rf...@apache.org> 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
> <si...@apache.org>:
>
>
>> 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 <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>>> 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 <rf...@apache.org>
>>>> 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 <
>>>>> simonetripodi@apache.org>:
>>>>>
>>>>>
>>>>> 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 <rfscholte@apache.org
>>>>>> >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 <
>>>>>>> simonetripodi@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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 <rf...@apache.org> 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
> <si...@apache.org>:
>
>
>> 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 <rf...@apache.org>
>> 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
>>> <si...@apache.org>:
>>>
>>>
>>>> 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 <rf...@apache.org>
>>>> 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 <
>>>>> simonetripodi@apache.org>:
>>>>>
>>>>>
>>>>> 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 <rfscholte@apache.org
>>>>>> >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 <
>>>>>>> simonetripodi@apache.org>:
>>>>>>>
>>>>>>>
>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
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
<si...@apache.org>:
> 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 <rf...@apache.org>
> 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
>> <si...@apache.org>:
>>
>>
>>> 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 <rf...@apache.org>
>>> 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 <
>>>> simonetripodi@apache.org>:
>>>>
>>>>
>>>> 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 <rfscholte@apache.org
>>>>> >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 <
>>>>>> simonetripodi@apache.org>:
>>>>>>
>>>>>>
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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 <rf...@apache.org> 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
> <si...@apache.org>:
>
>
>> 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 <rf...@apache.org>
>> 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 <
>>> simonetripodi@apache.org>:
>>>
>>>
>>> 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 <rfscholte@apache.org
>>>> >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 <
>>>>> simonetripodi@apache.org>:
>>>>>
>>>>>
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
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
<si...@apache.org>:
> 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 <rf...@apache.org>
> 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 <
>> simonetripodi@apache.org>:
>>
>>
>> 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 <rfscholte@apache.org
>>> >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 <
>>>> simonetripodi@apache.org>:
>>>>
>>>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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 <rf...@apache.org> 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 <
> simonetripodi@apache.org>:
>
>
> 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 <rfscholte@apache.org
>> >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 <
>>> simonetripodi@apache.org>:
>>>
>>>
>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
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
<si...@apache.org>:
> 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
> <rf...@apache.org>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 <
>> simonetripodi@apache.org>:
>>
>>
>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: MRELEASE-431
Posted by Simone Tripodi <si...@apache.org>.
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 <rf...@apache.org>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 <
> simonetripodi@apache.org>:
>
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: MRELEASE-431
Posted by Robert Scholte <rf...@apache.org>.
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
<si...@apache.org>:
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org