maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte" <rfscho...@apache.org>
Subject Re: MRELEASE-431
Date Sun, 16 Mar 2014 09:55:56 GMT
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
>>>> <simonetripodi@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
>>>>>> <simonetripodi@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


Mime
View raw message