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
<[email protected]>:
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
<[email protected]>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 <
[email protected]>:
Hi again Robert,
sorry for bugging - I hope I don't :P - but I notice Metadata also has
a very limited subset of informations about the ongoing released
artifact.
IMHO informations such us packaging and classifier should be part of
that data set - maybe I am wrong and work around that?
TIA, All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Wed, Mar 12, 2014 at 7:08 PM, Robert Scholte <[email protected]>
wrote:
Hi Simone,
for that reason I've added the Metadata, from which you can get the
latest
released artifact.
I really hope you don't need the ArtifactResolver.
Robert
Op Wed, 12 Mar 2014 13:30:12 +0100 schreef Simone Tripodi
<[email protected]>:
Hi again Robert,
in one of my VersionPolicy implementations, I need to resolve the
latest release artifact - then I have a tool to compare the bytecodes
and automatically understand which is the release number.
Question is: while I need an ArtifactResolver, I also need
ArtifactRepository for local/remotes that, inside a MOJO, would be
get
via the code below... what are the related Plexus annotations, in
order to obtain the same components?
TIA, all the best!
-Simo
@Parameter(required = true, defaultValue = "${localRepository}",
readonly = true)
private ArtifactRepository localRepository;
@Parameter(required = true, defaultValue =
"${project.remoteArtifactRepositories}", readonly = true)
private List<ArtifactRepository> remoteRepositories;
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Mon, Mar 10, 2014 at 7:09 PM, Robert Scholte
<[email protected]>
wrote:
Hi Simone,
I still have to find a solution for the VersionParseException which
can
be
thrown with the current implementation of DefaultVersionInfo. I
probably
have to add it to both methods of VersionPolicy
Your custom implementation will look something like:
@Component( role = VersionPolicy.class, hint = "tripodi" )
public class TripodiVersionPolicy implements VersionPolicy {
// your stuff
}
The plugin will get parameters like projectVersionPolicyId and/or
dependencyVersionPolicyId.
At least, that's my idea right now to split it up per type. This way
implementations can stay as clean as possible.
Robert
Op Mon, 10 Mar 2014 14:17:43 +0100 schreef Simone Tripodi
<[email protected]>:
Hi again Robert,
new APIs look reasonable and easily extensible to me, thanks for
putting
effort on that!
I maybe missed something but I didn't notice how they are
integrated
in
the
core module...
TIA all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Sat, Mar 8, 2014 at 3:17 PM, Robert Scholte
<[email protected]>
wrote:
Hi Simone,
I've added a new module for Maven release policies including my
idea
of
how the API should look like.
Although one of my suggestions to specify this as an
implementation
in
the
plugin configuration, I now prefer to use it as a component.
Downside
is
that you can't use a pojo, you'll need to add Plexus annotations
and
generate the descriptor. However, now you can inject other
components
a.k.a
requirements. Since this might become quite complicated,
injection is
probably the preferred way.
I probably need more info in the PolicyRequest to support the
current
behavior, but this is just a start.
This should be a good start for you too. Let me know if this will
work
with your requirements.
best,
Robert
Op Fri, 28 Feb 2014 17:06:05 +0100 schreef Simone Tripodi <
[email protected]>:
Hi Rob! :)
indeed it has been a very long while, so sorry for that :(
OK I understand your PoV, count on me if you want to co-operate
- I
need
that feature as well in order to make the release-plugin able to
generate
that version using a tool, but without exposing such APIs that
allow
me
plugging different versioning systems, I cannot do it :)
Many thanks in advance and have a nice weekend!
All the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
On Fri, Feb 28, 2014 at 4:17 PM, Robert Scholte <
[email protected]
>wrote:
Hi Simone,
It's been a while, so I'll need to have another look at this.
At first glance I'm not yet happy with the suggested API.
I'd need to make some time so come with a final solution.
Robert
Op Fri, 28 Feb 2014 14:56:35 +0100 schreef Simone Tripodi <
[email protected]>:
Hi all mates,
I am in a phase where I could get benefit of that feature as
well
(and,
since I am still in the committer list, I can provide some help
here)
so I
would like to push it :P
@Robert: before merging the contribution we received in JIRA,
I'd
kindly
ask if you had a better idea if new API has to be in
the maven-release-manager or in a separate module.
Many thanks in advance, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://twitter.com/simonetripodi
------------------------------------------------------------
---------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
------------------------------------------------------------
---------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
