Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
Although the PMC has not approved a policy yet, it has been making good progress and I am confident that we will have a policy in very short order. As a consequence I am now rescinding my veto. Note though that this change may be subject to review by the PMC when that policy is formalized - but that doesn't necessarily mean this change won't be approved. I am aware that a few other PMC members expressed support for my veto. It wasn't clear to me if they meant to imply that they also were vetoing the change, in which case they would also need to rescind theirs. Ralph On Jan 22, 2011, at 9:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. Ralph On Jan 22, 2011, at 9:22 AM, bentm...@apache.org wrote: Author: bentmann Date: Sat Jan 22 17:22:15 2011 New Revision: 1062210 URL: http://svn.apache.org/viewvc?rev=1062210view=rev Log: [MNG-4992] Allow to configure plugin parameters of type java.util.Properties just like a map Modified: maven/maven-3/trunk/pom.xml Modified: maven/maven-3/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/pom.xml?rev=1062210r1=1062209r2=1062210view=diff == --- maven/maven-3/trunk/pom.xml (original) +++ maven/maven-3/trunk/pom.xml Sat Jan 22 17:22:15 2011 @@ -44,7 +44,7 @@ plexusVersion1.5.5/plexusVersion plexusInterpolationVersion1.14/plexusInterpolationVersion plexusUtilsVersion2.0.4/plexusUtilsVersion -sisuInjectVersion1.4.3.1/sisuInjectVersion +sisuInjectVersion2.0.0/sisuInjectVersion wagonVersion1.0-beta-7/wagonVersion securityDispatcherVersion1.3/securityDispatcherVersion cipherVersion1.4/cipherVersion - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
Just to be clear, I was expressing my support that the veto was valid. I didn't see the point in adding to the pile of -1's, each of which would have to be rescinded individually. Like Ralph, I think now we've got some momentum started where we can resolve this without such confrontational means. -john On 1/26/11 7:31 AM, Ralph Goers wrote: Although the PMC has not approved a policy yet, it has been making good progress and I am confident that we will have a policy in very short order. As a consequence I am now rescinding my veto. Note though that this change may be subject to review by the PMC when that policy is formalized - but that doesn't necessarily mean this change won't be approved. I am aware that a few other PMC members expressed support for my veto. It wasn't clear to me if they meant to imply that they also were vetoing the change, in which case they would also need to rescind theirs. Ralph On Jan 22, 2011, at 9:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. Ralph On Jan 22, 2011, at 9:22 AM, bentm...@apache.org wrote: Author: bentmann Date: Sat Jan 22 17:22:15 2011 New Revision: 1062210 URL: http://svn.apache.org/viewvc?rev=1062210view=rev Log: [MNG-4992] Allow to configure plugin parameters of type java.util.Properties just like a map Modified: maven/maven-3/trunk/pom.xml Modified: maven/maven-3/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/pom.xml?rev=1062210r1=1062209r2=1062210view=diff == --- maven/maven-3/trunk/pom.xml (original) +++ maven/maven-3/trunk/pom.xml Sat Jan 22 17:22:15 2011 @@ -44,7 +44,7 @@ plexusVersion1.5.5/plexusVersion plexusInterpolationVersion1.14/plexusInterpolationVersion plexusUtilsVersion2.0.4/plexusUtilsVersion -sisuInjectVersion1.4.3.1/sisuInjectVersion +sisuInjectVersion2.0.0/sisuInjectVersion wagonVersion1.0-beta-7/wagonVersion securityDispatcherVersion1.3/securityDispatcherVersion cipherVersion1.4/cipherVersion - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Jan 24, 2011, at 9:16 PM, Brett Porter wrote: On 23/01/2011, at 4:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. So, normally a veto is worked through until consensus is reached rather than just dropping the change. It's a harsh step, but only applies to a single change and not a block on all changes. There's no need for overreactions, let's just try and resolve it. Is the only way to move forward to determine how to handle third-party dependencies, and how to apply it to current ones? Or is there another suggestion someone would like to make? - Brett All I asked for was for the PMC to define a policy - any policy - and then I'd remove the veto. Even a policy of we don't care as long as it meets licensing requirements would suffice. I am just requesting that the PMC formally state what it wants to do for the record. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
If you will all excuse a voice from the peanut gallery: Many PMCs take a very relaxed attitude toward external dependencies that are self-evidently qualified under the 'previously answered questions' list from Apache Legal. At CXF, for example, no one even raises an eyebrow about adding a 'category A' dependency to a non-ASF / non-ASL component. If some folks would like the maven PMC to hold a vote to adopt that attitude, might I suggest that you hold a vote for that idea and thus reduce the collective blood-pressure? On Tue, Jan 25, 2011 at 3:37 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 24, 2011, at 9:16 PM, Brett Porter wrote: On 23/01/2011, at 4:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. So, normally a veto is worked through until consensus is reached rather than just dropping the change. It's a harsh step, but only applies to a single change and not a block on all changes. There's no need for overreactions, let's just try and resolve it. Is the only way to move forward to determine how to handle third-party dependencies, and how to apply it to current ones? Or is there another suggestion someone would like to make? - Brett All I asked for was for the PMC to define a policy - any policy - and then I'd remove the veto. Even a policy of we don't care as long as it meets licensing requirements would suffice. I am just requesting that the PMC formally state what it wants to do for the record. Ralph - 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: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
The problem here is that fundamental maven functionality got moved over to external jars. And now those jars got changed from ALv2 to EPL. Don't get me wrong, EPL is not a bad thing, but we cannot contribute to this library anymore without going all the (very stony) route of contributing patches to the Eclipse foundation. If they refuse the patches then maven is doomed to fail... As someone already mentioned: In the worst case maven3 will get nothing more than a plugin processor for aether. From a project perspective this is a no-go, so I strongly support the veto. LieGrue, strub --- On Tue, 1/25/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml To: Maven Developers List dev@maven.apache.org Date: Tuesday, January 25, 2011, 2:17 PM If you will all excuse a voice from the peanut gallery: Many PMCs take a very relaxed attitude toward external dependencies that are self-evidently qualified under the 'previously answered questions' list from Apache Legal. At CXF, for example, no one even raises an eyebrow about adding a 'category A' dependency to a non-ASF / non-ASL component. If some folks would like the maven PMC to hold a vote to adopt that attitude, might I suggest that you hold a vote for that idea and thus reduce the collective blood-pressure? On Tue, Jan 25, 2011 at 3:37 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 24, 2011, at 9:16 PM, Brett Porter wrote: On 23/01/2011, at 4:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. So, normally a veto is worked through until consensus is reached rather than just dropping the change. It's a harsh step, but only applies to a single change and not a block on all changes. There's no need for overreactions, let's just try and resolve it. Is the only way to move forward to determine how to handle third-party dependencies, and how to apply it to current ones? Or is there another suggestion someone would like to make? - Brett All I asked for was for the PMC to define a policy - any policy - and then I'd remove the veto. Even a policy of we don't care as long as it meets licensing requirements would suffice. I am just requesting that the PMC formally state what it wants to do for the record. Ralph - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Jan 25, 2011, at 10:33 AM, Mark Struberg wrote: The problem here is that fundamental maven functionality got moved over to external jars. And now those jars got changed from ALv2 to EPL. Don't get me wrong, EPL is not a bad thing, but we cannot contribute to this library anymore without going all the (very stony) route of contributing patches to the Eclipse foundation. If they refuse the patches then maven is doomed to fail... As someone already mentioned: In the worst case maven3 will get nothing more than a plugin processor for aether. From a project perspective this is a no-go, so I strongly support the veto. Yet, on the other hand the Eclipse Foundation consumes many ASL licensed artifacts from the ASF. You don't see their projects spouting this nonsense. That a project at the Eclipse Foundation is doomed because it has to consume dependencies from Apache? Contributing at Eclipse is no more thorny then trying to contribute at the ASF. If an Apache project can only consume dependencies from within Apache and nothing else is acceptable then that project is going to fail anyway. LieGrue, strub --- On Tue, 1/25/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml To: Maven Developers List dev@maven.apache.org Date: Tuesday, January 25, 2011, 2:17 PM If you will all excuse a voice from the peanut gallery: Many PMCs take a very relaxed attitude toward external dependencies that are self-evidently qualified under the 'previously answered questions' list from Apache Legal. At CXF, for example, no one even raises an eyebrow about adding a 'category A' dependency to a non-ASF / non-ASL component. If some folks would like the maven PMC to hold a vote to adopt that attitude, might I suggest that you hold a vote for that idea and thus reduce the collective blood-pressure? On Tue, Jan 25, 2011 at 3:37 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 24, 2011, at 9:16 PM, Brett Porter wrote: On 23/01/2011, at 4:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. So, normally a veto is worked through until consensus is reached rather than just dropping the change. It's a harsh step, but only applies to a single change and not a block on all changes. There's no need for overreactions, let's just try and resolve it. Is the only way to move forward to determine how to handle third-party dependencies, and how to apply it to current ones? Or is there another suggestion someone would like to make? - Brett All I asked for was for the PMC to define a policy - any policy - and then I'd remove the veto. Even a policy of we don't care as long as it meets licensing requirements would suffice. I am just requesting that the PMC formally state what it wants to do for the record. Ralph - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Tue, Jan 25, 2011 at 9:47 AM, Jason van Zyl ja...@maven.org wrote: On Jan 25, 2011, at 10:33 AM, Mark Struberg wrote: The problem here is that fundamental maven functionality got moved over to external jars. And now those jars got changed from ALv2 to EPL. Don't get me wrong, EPL is not a bad thing, but we cannot contribute to this library anymore without going all the (very stony) route of contributing patches to the Eclipse foundation. If they refuse the patches then maven is doomed to fail... As someone already mentioned: In the worst case maven3 will get nothing more than a plugin processor for aether. From a project perspective this is a no-go, so I strongly support the veto. Yet, on the other hand the Eclipse Foundation consumes many ASL licensed artifacts from the ASF. You don't see their projects spouting this nonsense. That a project at the Eclipse Foundation is doomed because it has to consume dependencies from Apache? Contributing at Eclipse is no more thorny then trying to contribute at the ASF. If an Apache project can only consume dependencies from within Apache and nothing else is acceptable then that project is going to fail anyway. I've only been watching from the sidelines, but what Mark said resonated with me: The problem here is that fundamental maven functionality got moved over to external jars. I interpret his words to mean if very important parts of Maven are outside Apache, and PMC members can't control those external releases, how does Maven's core continue to progress inside of Apache? I certainly see some hand tying here. I believe it's all about fundamental maven functionality being divided between two organizations -- I just don't see how that can be efficient no matter who the organizations are. Paul
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On 25 January 2011 15:33, Mark Struberg strub...@yahoo.de wrote: The problem here is that fundamental maven functionality got moved over to external jars. umm, this particular update was to sisu which provides the replacement plexus container built on top of guice - it doesn't contain any maven functionality at all And now those jars got changed from ALv2 to EPL. Don't get me wrong, EPL is not a bad thing, but we cannot contribute to this library anymore without going all the (very stony) route of contributing patches to the Eclipse foundation. IANAL, but where does the EPL state that patches must be submitted to the Eclipse Foundation? It depends where the project is hosted. Personally I look forward to receiving contributions to sisu ( https://github.com/sonatype/sisu for those interested in getting involved) If they refuse the patches then maven is doomed to fail... As someone already mentioned: In the worst case maven3 will get nothing more than a plugin processor for aether. From a project perspective this is a no-go, so I strongly support the veto. again, this commit was to do with sisu not aether - imho it seems a bit odd to veto inclusion of one dependency based on views about a separate dependency... -- Cheers, Stuart LieGrue, strub --- On Tue, 1/25/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml To: Maven Developers List dev@maven.apache.org Date: Tuesday, January 25, 2011, 2:17 PM If you will all excuse a voice from the peanut gallery: Many PMCs take a very relaxed attitude toward external dependencies that are self-evidently qualified under the 'previously answered questions' list from Apache Legal. At CXF, for example, no one even raises an eyebrow about adding a 'category A' dependency to a non-ASF / non-ASL component. If some folks would like the maven PMC to hold a vote to adopt that attitude, might I suggest that you hold a vote for that idea and thus reduce the collective blood-pressure? On Tue, Jan 25, 2011 at 3:37 AM, Ralph Goers ralph.go...@dslextreme.com wrote: On Jan 24, 2011, at 9:16 PM, Brett Porter wrote: On 23/01/2011, at 4:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. So, normally a veto is worked through until consensus is reached rather than just dropping the change. It's a harsh step, but only applies to a single change and not a block on all changes. There's no need for overreactions, let's just try and resolve it. Is the only way to move forward to determine how to handle third-party dependencies, and how to apply it to current ones? Or is there another suggestion someone would like to make? - Brett All I asked for was for the PMC to define a policy - any policy - and then I'd remove the veto. Even a policy of we don't care as long as it meets licensing requirements would suffice. I am just requesting that the PMC formally state what it wants to do for the record. Ralph - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On 25 January 2011 15:47, Jason van Zyl ja...@maven.org wrote: On Jan 25, 2011, at 10:33 AM, Mark Struberg wrote: The problem here is that fundamental maven functionality got moved over to external jars. And now those jars got changed from ALv2 to EPL. Don't get me wrong, EPL is not a bad thing, but we cannot contribute to this library anymore without going all the (very stony) route of contributing patches to the Eclipse foundation. If they refuse the patches then maven is doomed to fail... As someone already mentioned: In the worst case maven3 will get nothing more than a plugin processor for aether. From a project perspective this is a no-go, so I strongly support the veto. Yet, on the other hand the Eclipse Foundation consumes many ASL licensed artifacts from the ASF. You don't see their projects spouting this nonsense. That a project at the Eclipse Foundation is doomed because it has to consume dependencies from Apache? Contributing at Eclipse is no more thorny then trying to contribute at the ASF. If an Apache project can only consume dependencies from within Apache and nothing else is acceptable then that project is going to fail anyway. See: www.apache.org/legal/resolved.html There are a number of issues with how the various dependencies can get consumed. The PMC has yet to issue a ploicy on what kinds of dependencies are permitted for maven-core. When the PMC has decided the policy that will be communicated to the committers of Maven. EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed projects to consume ASLv2 code... on the other hand it is not so acceptible for ASLv2 licensed projects to consume EPL licensed projects. There are ways for an Apache project to consume and distribute EPL licensed code, however given that the PMC is currently working on the policy for Maven's core dependencies, Ralph has decided to temporarily veto any change of a dependency in maven-core to a non-Category A license. My understanding is that once the policy has been approved the veto will either be removed, or the policy will make clear what is to be done. I can appreciate that for somebody who has resigned from the PMC and the Apache foundation it may appear that the veto has come out of thin air. -Stephen
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Jan 25, 2011, at 11:03 AM, Stephen Connolly wrote: On 25 January 2011 15:47, Jason van Zyl ja...@maven.org wrote: On Jan 25, 2011, at 10:33 AM, Mark Struberg wrote: The problem here is that fundamental maven functionality got moved over to external jars. And now those jars got changed from ALv2 to EPL. Don't get me wrong, EPL is not a bad thing, but we cannot contribute to this library anymore without going all the (very stony) route of contributing patches to the Eclipse foundation. If they refuse the patches then maven is doomed to fail... As someone already mentioned: In the worst case maven3 will get nothing more than a plugin processor for aether. From a project perspective this is a no-go, so I strongly support the veto. Yet, on the other hand the Eclipse Foundation consumes many ASL licensed artifacts from the ASF. You don't see their projects spouting this nonsense. That a project at the Eclipse Foundation is doomed because it has to consume dependencies from Apache? Contributing at Eclipse is no more thorny then trying to contribute at the ASF. If an Apache project can only consume dependencies from within Apache and nothing else is acceptable then that project is going to fail anyway. See: www.apache.org/legal/resolved.html There are a number of issues with how the various dependencies can get consumed. The PMC has yet to issue a ploicy on what kinds of dependencies are permitted for maven-core. When the PMC has decided the policy that will be communicated to the committers of Maven. EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed projects to consume ASLv2 code... on the other hand it is not so acceptible for ASLv2 licensed projects to consume EPL licensed projects. That is completely not true. Read the actual document you linked to. An Apache project can consume EPL binaries. There are ways for an Apache project to consume and distribute EPL licensed code, Yes, it's documented in the link you provided. however given that the PMC is currently working on the policy for Maven's core dependencies, Ralph has decided to temporarily veto any change of a dependency in maven-core to a non-Category A license. My understanding is that once the policy has been approved the veto will either be removed, or the policy will make clear what is to be done. I can appreciate that for somebody who has resigned from the PMC and the Apache foundation it may appear that the veto has come out of thin air. -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C.
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
2011/1/25 Jason van Zyl ja...@maven.org: EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed projects to consume ASLv2 code... on the other hand it is not so acceptible for ASLv2 licensed projects to consume EPL licensed projects. That is completely not true. Read the actual document you linked to. An Apache project can consume EPL binaries. For more info about accepted licenses: http://www.apache.org/legal/3party.html#criteriaandcategories IOW, you can link to any A and B licensed software without any problem. A particular case is LGPL. The license allows you to link to a LGPL-licensed software, however you cannot redistribute it in an Apache Licensed package. Antonio - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
Can I suggest that such debate moves to the PMC list ? Not sure discussion about licensing and in/out hosting of core components should occur here 2011/1/25 Jason van Zyl ja...@maven.org On Jan 25, 2011, at 11:03 AM, Stephen Connolly wrote: On 25 January 2011 15:47, Jason van Zyl ja...@maven.org wrote: On Jan 25, 2011, at 10:33 AM, Mark Struberg wrote: The problem here is that fundamental maven functionality got moved over to external jars. And now those jars got changed from ALv2 to EPL. Don't get me wrong, EPL is not a bad thing, but we cannot contribute to this library anymore without going all the (very stony) route of contributing patches to the Eclipse foundation. If they refuse the patches then maven is doomed to fail... As someone already mentioned: In the worst case maven3 will get nothing more than a plugin processor for aether. From a project perspective this is a no-go, so I strongly support the veto. Yet, on the other hand the Eclipse Foundation consumes many ASL licensed artifacts from the ASF. You don't see their projects spouting this nonsense. That a project at the Eclipse Foundation is doomed because it has to consume dependencies from Apache? Contributing at Eclipse is no more thorny then trying to contribute at the ASF. If an Apache project can only consume dependencies from within Apache and nothing else is acceptable then that project is going to fail anyway. See: www.apache.org/legal/resolved.html There are a number of issues with how the various dependencies can get consumed. The PMC has yet to issue a ploicy on what kinds of dependencies are permitted for maven-core. When the PMC has decided the policy that will be communicated to the committers of Maven. EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed projects to consume ASLv2 code... on the other hand it is not so acceptible for ASLv2 licensed projects to consume EPL licensed projects. That is completely not true. Read the actual document you linked to. An Apache project can consume EPL binaries. There are ways for an Apache project to consume and distribute EPL licensed code, Yes, it's documented in the link you provided. however given that the PMC is currently working on the policy for Maven's core dependencies, Ralph has decided to temporarily veto any change of a dependency in maven-core to a non-Category A license. My understanding is that once the policy has been approved the veto will either be removed, or the policy will make clear what is to be done. I can appreciate that for somebody who has resigned from the PMC and the Apache foundation it may appear that the veto has come out of thin air. -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C.
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
Lets end the debate on this pending the ongoing PMC discussions. There isn't a release pending that I'm aware of that needs this change to be committed urgently, so there's no need to rush to judgement on anything, or to further debate what can and can't be done with licenses at Apache. The policy is documented and available for anyone to read: http://www.apache.org/legal/3party.html On Tue, Jan 25, 2011 at 11:16 AM, Antonio Petrelli antonio.petre...@gmail.com wrote: 2011/1/25 Jason van Zyl ja...@maven.org: EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed projects to consume ASLv2 code... on the other hand it is not so acceptible for ASLv2 licensed projects to consume EPL licensed projects. That is completely not true. Read the actual document you linked to. An Apache project can consume EPL binaries. For more info about accepted licenses: http://www.apache.org/legal/3party.html#criteriaandcategories IOW, you can link to any A and B licensed software without any problem. A particular case is LGPL. The license allows you to link to a LGPL-licensed software, however you cannot redistribute it in an Apache Licensed package. Antonio - 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: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
2011/1/25 Jason van Zyl ja...@maven.org On Jan 25, 2011, at 11:03 AM, Stephen Connolly wrote: EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed projects to consume ASLv2 code... on the other hand it is not so acceptible for ASLv2 licensed projects to consume EPL licensed projects. That is completely not true. Read the actual document you linked to. An Apache project can consume EPL binaries. Yes and my next sentence hints at that. I was not saying that we cannot consume EPL licensed code, I was putting Ralph's veto into context. There are ways for an Apache project to consume and distribute EPL licensed code, Yes, it's documented in the link you provided. Correct. The PMC is tasked with ensuring that the project complies with the linked document. The change was only in the dependency and there is a need to assess whether changing the dependency version puts the project in breach of the distribution rules for Apache projects. Also there is the policy that the PMC is working on. All I am doing is putting things into context. If you don't like the context, then you don't like it! however given that the PMC is currently working on the policy for Maven's core dependencies, Ralph has decided to temporarily veto any change of a dependency in maven-core to a non-Category A license. My understanding is that once the policy has been approved the veto will either be removed, or the policy will make clear what is to be done. I can appreciate that for somebody who has resigned from the PMC and the Apache foundation it may appear that the veto has come out of thin air. -Stephen Thanks, Jason - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On 25 January 2011 16:16, Antonio Petrelli antonio.petre...@gmail.com wrote: 2011/1/25 Jason van Zyl ja...@maven.org: EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed projects to consume ASLv2 code... on the other hand it is not so acceptible for ASLv2 licensed projects to consume EPL licensed projects. That is completely not true. Read the actual document you linked to. An Apache project can consume EPL binaries. For more info about accepted licenses: http://www.apache.org/legal/3party.html#criteriaandcategories IOW, you can link to any A and B licensed software without any problem. A particular case is LGPL. The license allows you to link to a LGPL-licensed software, however you cannot redistribute it in an Apache Licensed package. Also you cannot bundle the source of an EPL licensed project within an Apache distribution. Whereas you can bundle the source of an ASL licensed project within an Apache distribution. Antonio - 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: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
moving this over to private@m.a.o Oki, for the Category B licenses Software under this license may be included in BINARY form. further: For small amounts of source that is directly consumed by the ASF product at runtime in source form, and for which that source is unmodified and unlikely to be changed anyway (say, by virtue of being specified by a standard), inclusion of appropriately labeled source is also permitted. BUT it is not possible for maven to just take e.g. the now EPLed sisu, fork it back and maintain it inside the ASF, whereas for EPLed software it is pretty easy to fork an ALv2 licensed project and incorporate it privately. Correct? I know Sonatype contributed lots of stuff, but please take your company hat off for a moment. The Apache Maven project now can decide to just take the last ALv2ed sisu code and maintain it itself before any huge differences find its way into the codebase. Or to decide to do nothing and have not much impact on core maven parts anymore. This discussion is not about any 3rd party tool one going to use or replace it with another tool - it's really about the core thingy of maven. LieGrue, strub --- On Tue, 1/25/11, Jason van Zyl ja...@maven.org wrote: From: Jason van Zyl ja...@maven.org Subject: Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml To: Maven Developers List dev@maven.apache.org Date: Tuesday, January 25, 2011, 4:11 PM On Jan 25, 2011, at 11:03 AM, Stephen Connolly wrote: On 25 January 2011 15:47, Jason van Zyl ja...@maven.org wrote: On Jan 25, 2011, at 10:33 AM, Mark Struberg wrote: The problem here is that fundamental maven functionality got moved over to external jars. And now those jars got changed from ALv2 to EPL. Don't get me wrong, EPL is not a bad thing, but we cannot contribute to this library anymore without going all the (very stony) route of contributing patches to the Eclipse foundation. If they refuse the patches then maven is doomed to fail... As someone already mentioned: In the worst case maven3 will get nothing more than a plugin processor for aether. From a project perspective this is a no-go, so I strongly support the veto. Yet, on the other hand the Eclipse Foundation consumes many ASL licensed artifacts from the ASF. You don't see their projects spouting this nonsense. That a project at the Eclipse Foundation is doomed because it has to consume dependencies from Apache? Contributing at Eclipse is no more thorny then trying to contribute at the ASF. If an Apache project can only consume dependencies from within Apache and nothing else is acceptable then that project is going to fail anyway. See: www.apache.org/legal/resolved.html There are a number of issues with how the various dependencies can get consumed. The PMC has yet to issue a ploicy on what kinds of dependencies are permitted for maven-core. When the PMC has decided the policy that will be communicated to the committers of Maven. EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed projects to consume ASLv2 code... on the other hand it is not so acceptible for ASLv2 licensed projects to consume EPL licensed projects. That is completely not true. Read the actual document you linked to. An Apache project can consume EPL binaries. There are ways for an Apache project to consume and distribute EPL licensed code, Yes, it's documented in the link you provided. however given that the PMC is currently working on the policy for Maven's core dependencies, Ralph has decided to temporarily veto any change of a dependency in maven-core to a non-Category A license. My understanding is that once the policy has been approved the veto will either be removed, or the policy will make clear what is to be done. I can appreciate that for somebody who has resigned from the PMC and the Apache foundation it may appear that the veto has come out of thin air. -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
No, don't move this to the PMC list. I'm not on that list and I believe this discussion should be held in public view. On Jan 25, 2011, at 11:17 AM, nicolas de loof wrote: Can I suggest that such debate moves to the PMC list ? Not sure discussion about licensing and in/out hosting of core components should occur here 2011/1/25 Jason van Zyl ja...@maven.org On Jan 25, 2011, at 11:03 AM, Stephen Connolly wrote: On 25 January 2011 15:47, Jason van Zyl ja...@maven.org wrote: On Jan 25, 2011, at 10:33 AM, Mark Struberg wrote: The problem here is that fundamental maven functionality got moved over to external jars. And now those jars got changed from ALv2 to EPL. Don't get me wrong, EPL is not a bad thing, but we cannot contribute to this library anymore without going all the (very stony) route of contributing patches to the Eclipse foundation. If they refuse the patches then maven is doomed to fail... As someone already mentioned: In the worst case maven3 will get nothing more than a plugin processor for aether. From a project perspective this is a no-go, so I strongly support the veto. Yet, on the other hand the Eclipse Foundation consumes many ASL licensed artifacts from the ASF. You don't see their projects spouting this nonsense. That a project at the Eclipse Foundation is doomed because it has to consume dependencies from Apache? Contributing at Eclipse is no more thorny then trying to contribute at the ASF. If an Apache project can only consume dependencies from within Apache and nothing else is acceptable then that project is going to fail anyway. See: www.apache.org/legal/resolved.html There are a number of issues with how the various dependencies can get consumed. The PMC has yet to issue a ploicy on what kinds of dependencies are permitted for maven-core. When the PMC has decided the policy that will be communicated to the committers of Maven. EPL is more restrictive than ASLv2, therefore it is OK for EPL licensed projects to consume ASLv2 code... on the other hand it is not so acceptible for ASLv2 licensed projects to consume EPL licensed projects. That is completely not true. Read the actual document you linked to. An Apache project can consume EPL binaries. There are ways for an Apache project to consume and distribute EPL licensed code, Yes, it's documented in the link you provided. however given that the PMC is currently working on the policy for Maven's core dependencies, Ralph has decided to temporarily veto any change of a dependency in maven-core to a non-Category A license. My understanding is that once the policy has been approved the veto will either be removed, or the policy will make clear what is to be done. I can appreciate that for somebody who has resigned from the PMC and the Apache foundation it may appear that the veto has come out of thin air. -Stephen Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Jan 25, 2011, at 11:30 AM, Stephen Connolly wrote: Also you cannot bundle the source of an EPL licensed project within an Apache distribution. Whereas you can bundle the source of an ASL licensed project within an Apache distribution. We don't do that with anything anyway? We don't include sources of our 3rd party dependencies so who cares? This is Apache's policy as well, not a generally followed policy. So in this context it doesn't matter. This is just another red herring. Antonio - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A language that doesn’t affect the way you think about programming is not worth knowing. -— Alan Perlis
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Jan 25, 2011, at 11:03 AM, Stephen Connolly wrote: My understanding is that once the policy has been approved the veto will either be removed, or the policy will make clear what is to be done. The PMCs choice is to accept EPL licensed artifacts that don't come from Apache, or you can re-implement them all. No one is going to strong-arm me into bringing any of those dependencies here and Ralph's Ursula Move[1] was pretty much the final nail in the coffin. I resigned from the Maven PMC specifically because of Ralph Goers. When some guy who done virtually nothing for two years vetoes someone like Benjamin then it's not a meritocracy, it's ridiculous is what it is. After 10 years of working on this stuff, if the Maven PMC feels I'm going to do something that's not in the best interest of Maven users then I'm not going to try and convince anyone. Say no to the dependencies that Sonatype has created and works on, re-implement them and good luck with that. You will completely cripple the project. Ralph just guaranteed those dependencies are never coming back here. He just totally abused his unjustified position on the Maven PMC. Someone will have to run me over with a truck to change that now. What Ralph did is irreversible even if the veto is. I have always done what is in the best interest of users, and I always will. Sonatype, my investors, and anyone else have no control over me when it comes to Maven. Brett and John have first hand experience about what happens when I believe there is a transgression and what I will do to try and course correct. I can appreciate that for somebody who has resigned from the PMC and the Apache foundation it may appear that the veto has come out of thin air. -Stephen [1]: http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Unknown
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On 1/25/11 11:39 AM, Jason van Zyl wrote: On Jan 25, 2011, at 11:03 AM, Stephen Connolly wrote: My understanding is that once the policy has been approved the veto will either be removed, or the policy will make clear what is to be done. The PMCs choice is to accept EPL licensed artifacts that don't come from Apache, or you can re-implement them all. No one is going to strong-arm me into bringing any of those dependencies here and Ralph's Ursula Move[1] was pretty much the final nail in the coffin. I resigned from the Maven PMC specifically because of Ralph Goers. When some guy who done virtually nothing for two years vetoes someone like Benjamin then it's not a meritocracy, it's ridiculous is what it is. After 10 years of working on this stuff, if the Maven PMC feels I'm going to do something that's not in the best interest of Maven users then I'm not going to try and convince anyone. Say no to the dependencies that Sonatype has created and works on, re-implement them and good luck with that. You will completely cripple the project. Ralph just guaranteed those dependencies are never coming back here. He just totally abused his unjustified position on the Maven PMC. Someone will have to run me over with a truck to change that now. What Ralph did is irreversible even if the veto is. I have always done what is in the best interest of users, and I always will. Sonatype, my investors, and anyone else have no control over me when it comes to Maven. Brett and John have first hand experience about what happens when I believe there is a transgression and what I will do to try and course correct. IMO, this is exactly why we can't consider these projects (sisu, aether, modello?) as being just another EPL dependency, governed by Eclipse Foundation practices. There is a lot of history here, and obviously a lot of high emotion...not to mention personal agendas. To say that, because Eclipse offers a reasonable environment contribution, and because sisu has a github project, everything is just fine as far as using these dependencies...well, that kind of misses the nuance that Jason has just provided. I can appreciate that for somebody who has resigned from the PMC and the Apache foundation it may appear that the veto has come out of thin air. -Stephen [1]: http://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Unknown -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Tue, Jan 25, 2011 at 11:39 AM, Jason van Zyl ja...@maven.org wrote: When some guy who done virtually nothing for two years vetoes someone [else] then it's not a meritocracy, it's ridiculous is what it is. That was out of line. There is no contribution threshold before you are allowed to have an opinion. We are all concerned about this community and should feel comfortable speaking out if we think something isn't right. I've been on the receiving end of the same thing in the past and it has definitely affected my participation here. I don't want that to happen to anyone else. -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Jan 25, 2011, at 1:28 PM, Wendy Smoak wrote: On Tue, Jan 25, 2011 at 11:39 AM, Jason van Zyl ja...@maven.org wrote: When some guy who done virtually nothing for two years vetoes someone [else] then it's not a meritocracy, it's ridiculous is what it is. That was out of line. There is no contribution threshold before you are allowed to have an opinion. We are all concerned about this community and should feel comfortable speaking out if we think something isn't right. You are entitled to your point of view, Ralph is entitled to his opinion, I am entitled to my reaction. I've been on the receiving end of the same thing in the past and it has definitely affected my participation here. I don't want that to happen to anyone else. -- Wendy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Tue, Jan 25, 2011 at 10:28 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 25, 2011 at 11:39 AM, Jason van Zyl ja...@maven.org wrote: When some guy who done virtually nothing for two years vetoes someone [else] then it's not a meritocracy, it's ridiculous is what it is. That was out of line. There is no contribution threshold before you are allowed to have an opinion. We are all concerned about this community and should feel comfortable speaking out if we think something isn't right. I've been on the receiving end of the same thing in the past and it has definitely affected my participation here. I don't want that to happen to anyone else. I have to agree and I support Ralph's veto, there's an issue being discussed on the PMC that needs to be resolved and ignoring it and continue with these changes won't help move forward. -- Wendy - 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: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
+1 sent from my phone On Jan 25, 2011 5:12 PM, Carlos Sanchez car...@apache.org wrote: On Tue, Jan 25, 2011 at 10:28 AM, Wendy Smoak wsm...@gmail.com wrote: On Tue, Jan 25, 2011 at 11:39 AM, Jason van Zyl ja...@maven.org wrote: When some guy who done virtually nothing for two years vetoes someone [else] then it's not a meritocracy, it's ridiculous is what it is. That was out of line. There is no contribution threshold before you are allowed to have an opinion. We are all concerned about this community and should feel comfortable speaking out if we think something isn't right. I've been on the receiving end of the same thing in the past and it has definitely affected my participation here. I don't want that to happen to anyone else. I have to agree and I support Ralph's veto, there's an issue being discussed on the PMC that needs to be resolved and ignoring it and continue with these changes won't help move forward. -- Wendy - 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: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Jan 22, 2011, at 11:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. Folks at Sonatype will continue helping users like we always do: http://www.simpligility.com/2011/01/more-guice-for-android-and-maven-central/ I will open our maven-3 Github repository later today where we will be making all our changes, to continue helping users. Ralph On Jan 22, 2011, at 9:22 AM, bentm...@apache.org wrote: Author: bentmann Date: Sat Jan 22 17:22:15 2011 New Revision: 1062210 URL: http://svn.apache.org/viewvc?rev=1062210view=rev Log: [MNG-4992] Allow to configure plugin parameters of type java.util.Properties just like a map Modified: maven/maven-3/trunk/pom.xml Modified: maven/maven-3/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/pom.xml?rev=1062210r1=1062209r2=1062210view=diff == --- maven/maven-3/trunk/pom.xml (original) +++ maven/maven-3/trunk/pom.xml Sat Jan 22 17:22:15 2011 @@ -44,7 +44,7 @@ plexusVersion1.5.5/plexusVersion plexusInterpolationVersion1.14/plexusInterpolationVersion plexusUtilsVersion2.0.4/plexusUtilsVersion -sisuInjectVersion1.4.3.1/sisuInjectVersion +sisuInjectVersion2.0.0/sisuInjectVersion wagonVersion1.0-beta-7/wagonVersion securityDispatcherVersion1.3/securityDispatcherVersion cipherVersion1.4/cipherVersion - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On Jan 22, 2011, at 11:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. This change we have made to our tracking repository, but in general we will track all our changes to Maven 3.x here: https://github.com/sonatype/maven-3 The integration tests to track those changes are here: https://github.com/sonatype/maven-integration-testing In the face of essentially being attacked at an organizational level, Sonatype folks are not going to hide what we're doing. We have a policy of not making forked cores, because we feel it's just wrong on top of being a maintenance problem. There's not much we can do to adhere to that when you veto our changes. So all of our changes will be publicly visible at Github and hopefully the Maven PMC will come to a decision which is actually in the best interest of users. Ralph On Jan 22, 2011, at 9:22 AM, bentm...@apache.org wrote: Author: bentmann Date: Sat Jan 22 17:22:15 2011 New Revision: 1062210 URL: http://svn.apache.org/viewvc?rev=1062210view=rev Log: [MNG-4992] Allow to configure plugin parameters of type java.util.Properties just like a map Modified: maven/maven-3/trunk/pom.xml Modified: maven/maven-3/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/pom.xml?rev=1062210r1=1062209r2=1062210view=diff == --- maven/maven-3/trunk/pom.xml (original) +++ maven/maven-3/trunk/pom.xml Sat Jan 22 17:22:15 2011 @@ -44,7 +44,7 @@ plexusVersion1.5.5/plexusVersion plexusInterpolationVersion1.14/plexusInterpolationVersion plexusUtilsVersion2.0.4/plexusUtilsVersion -sisuInjectVersion1.4.3.1/sisuInjectVersion +sisuInjectVersion2.0.0/sisuInjectVersion wagonVersion1.0-beta-7/wagonVersion securityDispatcherVersion1.3/securityDispatcherVersion cipherVersion1.4/cipherVersion - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
On 23/01/2011, at 4:34 AM, Ralph Goers wrote: From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. So, normally a veto is worked through until consensus is reached rather than just dropping the change. It's a harsh step, but only applies to a single change and not a block on all changes. There's no need for overreactions, let's just try and resolve it. Is the only way to move forward to determine how to handle third-party dependencies, and how to apply it to current ones? Or is there another suggestion someone would like to make? - Brett Ralph On Jan 22, 2011, at 9:22 AM, bentm...@apache.org wrote: Author: bentmann Date: Sat Jan 22 17:22:15 2011 New Revision: 1062210 URL: http://svn.apache.org/viewvc?rev=1062210view=rev Log: [MNG-4992] Allow to configure plugin parameters of type java.util.Properties just like a map Modified: maven/maven-3/trunk/pom.xml Modified: maven/maven-3/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/pom.xml?rev=1062210r1=1062209r2=1062210view=diff == --- maven/maven-3/trunk/pom.xml (original) +++ maven/maven-3/trunk/pom.xml Sat Jan 22 17:22:15 2011 @@ -44,7 +44,7 @@ plexusVersion1.5.5/plexusVersion plexusInterpolationVersion1.14/plexusInterpolationVersion plexusUtilsVersion2.0.4/plexusUtilsVersion -sisuInjectVersion1.4.3.1/sisuInjectVersion +sisuInjectVersion2.0.0/sisuInjectVersion wagonVersion1.0-beta-7/wagonVersion securityDispatcherVersion1.3/securityDispatcherVersion cipherVersion1.4/cipherVersion - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1062210 - /maven/maven-3/trunk/pom.xml
From what I can tell Sisu was previously under the Apache license but now also seems to have the EPL attached to it. Until the PMC makes a decision on how it is going to handle dependencies being managed by Sonatype I must veto any version changes on these artifacts. Please revert this change. Ralph On Jan 22, 2011, at 9:22 AM, bentm...@apache.org wrote: Author: bentmann Date: Sat Jan 22 17:22:15 2011 New Revision: 1062210 URL: http://svn.apache.org/viewvc?rev=1062210view=rev Log: [MNG-4992] Allow to configure plugin parameters of type java.util.Properties just like a map Modified: maven/maven-3/trunk/pom.xml Modified: maven/maven-3/trunk/pom.xml URL: http://svn.apache.org/viewvc/maven/maven-3/trunk/pom.xml?rev=1062210r1=1062209r2=1062210view=diff == --- maven/maven-3/trunk/pom.xml (original) +++ maven/maven-3/trunk/pom.xml Sat Jan 22 17:22:15 2011 @@ -44,7 +44,7 @@ plexusVersion1.5.5/plexusVersion plexusInterpolationVersion1.14/plexusInterpolationVersion plexusUtilsVersion2.0.4/plexusUtilsVersion -sisuInjectVersion1.4.3.1/sisuInjectVersion +sisuInjectVersion2.0.0/sisuInjectVersion wagonVersion1.0-beta-7/wagonVersion securityDispatcherVersion1.3/securityDispatcherVersion cipherVersion1.4/cipherVersion - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
