Re: MRELEASE-431
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 simonetrip...@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 rfscho...@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 simonetrip...@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 rfscho...@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 simonetrip...@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 rfscho...@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 simonetrip...@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
Welcome Mirko Friedenhagen to the Apache Maven Team
Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Welcome Mirko! /Anders On Mon, Mar 17, 2014 at 8:53 PM, Robert Scholte rfscho...@apache.orgwrote: Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Welcome on board! On Monday, 17 March 2014, Robert Scholte rfscho...@apache.org wrote: Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Sent from my phone
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Hi Mirko, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Cool...welcome on board... Happy hacking... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MRELEASE-431
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 simonetrip...@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 simonetrip...@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 rfscho...@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 simonetrip...@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 rfscho...@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 simonetrip...@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 rfscho...@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 simonetrip...@apache.org: Hi
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Welcome! -- Olivier On Mar 18, 2014 6:53 AM, Robert Scholte rfscho...@apache.org wrote: Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Good to have you with us, Mirko! Wayne On Mon, Mar 17, 2014 at 2:53 PM, Robert Scholte rfscho...@apache.org wrote: Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Welcome Mirko Regards, Hervé Le lundi 17 mars 2014 20:53:30 Robert Scholte a écrit : Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MRELEASE-431
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 simonetrip...@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 simonetrip...@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 rfscho...@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 simonetrip...@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 rfscho...@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 simonetrip...@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 rfscho...@apache.org wrote: Hi Simone, for that reason I've added the Metadata, from which you can get the latest released artifact. I really
RE: Welcome Mirko Friedenhagen to the Apache Maven Team
Willkommen Mirko! Martin -- Date: Mon, 17 Mar 2014 21:06:17 +0100 From: khmarba...@gmx.de To: dev@maven.apache.org Subject: Re: Welcome Mirko Friedenhagen to the Apache Maven Team Hi Mirko, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Cool...welcome on board... Happy hacking... Kind regards Karl-Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Welcome! S. On Mon, Mar 17, 2014 at 8:53 PM, Robert Scholte rfscho...@apache.orgwrote: Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Welcome Mirko Friedenhagen to the Apache Maven Team
Welcome! Domi On 17.03.2014, at 20:53, Robert Scholte rfscho...@apache.org wrote: Hi, On behalf of the Apache Maven PMC I am pleased to announce that Mirko Friedenhagen (mfriedenhagen) has been voted in as a new Apache Maven committer. Mirko, welcome on board and have a lot of fun! thanks, Robert - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
