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 wr
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
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.
W
Hi again Robert,
IIUC the VersionPolicy resolution in `Map
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
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
separate
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 S
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
:
Hi Robert,
after an internal discussion with my colleagues, we are ATM fine with
just implementing the odd-even policy,
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!
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" wrote:
> I've been using the 4 digit versions with the release plugin for the last
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
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
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
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 wrote:
> 2014-03-13 19:19 GMT+01:00 Robert Scholte :
>
> > To say it in your own words: IMHO I think you're wrong here ;)
> >
> > Version policy is about calculat
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
Op Fri, 14 Mar 2014 10:25:59 +0100 schreef Baptiste Mathus
:
2014-03-13 19:19 GMT+01:00 Robert Scholte :
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:
g
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 loca
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,
2014-03-13 19:19 GMT+01:00 Robert Scholte :
> 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
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 unde
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
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 t
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.
Ma
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
:
Hi again Robert,
in one of my VersionPolicy implementations, I
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 wrote:
> Out of curiosity,
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 loca
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://
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 = VersionPoli
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
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 wrote:
> Hi Simone,
>
> I've added a new module for Maven r
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
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
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
:
Hi all mates,
I am in a phase whe
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 AP
34 matches
Mail list logo
