[DISCUSS] incorporate EPL Aether
After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff. Aether and likes are core maven parts which are utterly important if we like to maintain maven itself. Just check how deep aether is anchored in DefaultMaven.java! The original decision was to introduce a 'pluggable repository layer' which in my opinion would have meant to introduce a series of interfaces and data holder classes in form of a SPI. But this very part has not been implemented this way. Instead lots of internal details needs to be addressed/controlled directly from inside Maven. I tried to introduce such an interface layer for a few days but failed due to the deep integration... So I'd definitely -1 a EPL core dependency which once was part of maven core as long as there is no ALv2 alternative which we can bugfix ourselfs! LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 1:26 PM After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - 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: [DISCUSS] incorporate EPL Aether
http://maven.apache.org/developers/dependency-policies On 17 July 2011 15:02, Mark Struberg strub...@yahoo.de wrote: Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff. Aether and likes are core maven parts which are utterly important if we like to maintain maven itself. Just check how deep aether is anchored in DefaultMaven.java! The original decision was to introduce a 'pluggable repository layer' which in my opinion would have meant to introduce a series of interfaces and data holder classes in form of a SPI. But this very part has not been implemented this way. Instead lots of internal details needs to be addressed/controlled directly from inside Maven. I tried to introduce such an interface layer for a few days but failed due to the deep integration... So I'd definitely -1 a EPL core dependency which once was part of maven core as long as there is no ALv2 alternative which we can bugfix ourselfs! LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 1:26 PM After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - 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: [DISCUSS] incorporate EPL Aether
as an option, eclipse has allowed dual licensed code before, namely jetty so there is precedent for aether to be dual licensed if they so desire.. http://www.eclipse.org/jetty/licenses.php cheers, jesse -- jesse mcconnell jesse.mcconn...@gmail.com On Sun, Jul 17, 2011 at 09:15, Stephen Connolly stephen.alan.conno...@gmail.com wrote: http://maven.apache.org/developers/dependency-policies On 17 July 2011 15:02, Mark Struberg strub...@yahoo.de wrote: Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff. Aether and likes are core maven parts which are utterly important if we like to maintain maven itself. Just check how deep aether is anchored in DefaultMaven.java! The original decision was to introduce a 'pluggable repository layer' which in my opinion would have meant to introduce a series of interfaces and data holder classes in form of a SPI. But this very part has not been implemented this way. Instead lots of internal details needs to be addressed/controlled directly from inside Maven. I tried to introduce such an interface layer for a few days but failed due to the deep integration... So I'd definitely -1 a EPL core dependency which once was part of maven core as long as there is no ALv2 alternative which we can bugfix ourselfs! LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 1:26 PM After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. On Sun, Jul 17, 2011 at 10:15 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: http://maven.apache.org/developers/dependency-policies On 17 July 2011 15:02, Mark Struberg strub...@yahoo.de wrote: Actually the discussions I remember have explicitly favoured (3) (forking the last ALv2 version) if no ALv2 licensed version is available anymore. There are 2 arguments for that: it's not only aether, it's also sisu and the other guice stuff. Aether and likes are core maven parts which are utterly important if we like to maintain maven itself. Just check how deep aether is anchored in DefaultMaven.java! The original decision was to introduce a 'pluggable repository layer' which in my opinion would have meant to introduce a series of interfaces and data holder classes in form of a SPI. But this very part has not been implemented this way. Instead lots of internal details needs to be addressed/controlled directly from inside Maven. I tried to introduce such an interface layer for a few days but failed due to the deep integration... So I'd definitely -1 a EPL core dependency which once was part of maven core as long as there is no ALv2 alternative which we can bugfix ourselfs! LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 1:26 PM After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. My sense, without reading private archives, is that the community decided not to adopt the overall course of action of which (3) would be a part, so I believe that it's not a serious option at this point. (2) is possible, but my view is that the value to the community of the dual license is not worth the trouble. Thus, I'm proposing (1), but I'm certainly not going to complain if some PMC member decides to take a run at (2). A positive decision to allow incorporation of EPL Aether would give us flexibility, and if (2) happened later that would be a good thing. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1147613 - in /maven/jxr/trunk: maven-jxr-plugin/pom.xml maven-jxr/pom.xml pom.xml
Benson: I have locally built and staged the site before and after this
commit and I don't see any of the mentioned issues. Have you actually
checked your local site? Did you run the site phase or the site:site
goal? Anyway, with site-plugin-2.3 the locally built and
stage(-deployed) sites should be completely identical.
-Lukas
bimargul...@apache.org wrote:
Author: bimargulies
Date: Sun Jul 17 13:49:35 2011
New Revision: 1147613
URL: http://svn.apache.org/viewvc?rev=1147613view=rev
Log:
Copy more configuration from the standard plugin parent to see if I can't fix
up the site issues that Hervé
pointed out. This is certainly not all the fixes needed.
Modified:
maven/jxr/trunk/maven-jxr-plugin/pom.xml
maven/jxr/trunk/maven-jxr/pom.xml
maven/jxr/trunk/pom.xml
Modified: maven/jxr/trunk/maven-jxr-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/maven-jxr-plugin/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/maven-jxr-plugin/pom.xml (original)
+++ maven/jxr/trunk/maven-jxr-plugin/pom.xml Sun Jul 17 13:49:35 2011
@@ -48,7 +48,7 @@ under the License.
properties
mavenVersion2.0.9/mavenVersion
-sitePluginVersion2.2/sitePluginVersion
+sitePluginVersion2.3/sitePluginVersion
doxia-sitetoolsVersion1.2/doxia-sitetoolsVersion
doxiaVersion1.2/doxiaVersion
/properties
@@ -73,10 +73,6 @@ under the License.
forkModealways/forkMode
/configuration
/plugin
-plugin
-artifactIdmaven-site-plugin/artifactId
-version${sitePluginVersion}/version
-/plugin
/plugins
/pluginManagement
@@ -84,6 +80,7 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
+ version2.8/version
executions
execution
idgenerated-helpmojo/id
@@ -185,6 +182,7 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
+ version2.8/version
/plugin
/plugins
/reporting
@@ -235,7 +233,7 @@ under the License.
/file
/activation
properties
-sitePluginVersion3.0-beta-1-SNAPSHOT/sitePluginVersion
+sitePluginVersion3.0-beta-4-SNAPSHOT/sitePluginVersion
/properties
/profile
@@ -246,13 +244,13 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
-version2.5/version
+version2.8/version
configuration
tagletArtifacts
tagletArtifact
groupIdorg.apache.maven.plugin-tools/groupId
artifactIdmaven-plugin-tools-javadoc/artifactId
-version2.5/version
+version2.8/version
/tagletArtifact
tagletArtifact
groupIdorg.codehaus.plexus/groupId
Modified: maven/jxr/trunk/maven-jxr/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/maven-jxr/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/maven-jxr/pom.xml (original)
+++ maven/jxr/trunk/maven-jxr/pom.xml Sun Jul 17 13:49:35 2011
@@ -101,6 +101,7 @@ under the License.
/site
/distributionManagement
+
dependencies
dependency
groupIdjunit/groupId
Modified: maven/jxr/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/pom.xml (original)
+++ maven/jxr/trunk/pom.xml Sun Jul 17 13:49:35 2011
@@ -60,6 +60,7 @@ under the License.
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
+ scopetest/scope
version4.8.2/version
/dependency
/dependencies
@@ -69,6 +70,13 @@ under the License.
pluginManagement
plugins
plugin
+artifactIdmaven-site-plugin/artifactId
+ version2.3/version
+configuration
+stagingSiteURLscp://people.apache.org/www/maven.apache.org/jxr/${project.artifactId}-${project.version}/stagingSiteURL
+/configuration
+/plugin
+plugin
artifactIdmaven-release-plugin/artifactId
configuration
tagBasehttps://svn.apache.org/repos/asf/maven/jxr/tags/tagBase
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven JXR version 2.3
Here's a dilemma. With -Preporting, I get the following when trying to
build both sites at the same time, since the plugin tries to use a jxr
report of itself. Maybe I just stick to one site at a time?
[ERROR] BUILD FAILURE
[INFO]
[INFO] The projects in the reactor contain a cyclic reference: Edge
between 'Vertex{label='org.apache.maven.plugins:maven-jxr-plugin'}'
and 'Vertex{label='org.apache.maven:maven-jxr'}' introduces to cycle
in the graph org.apache.maven:maven-jxr --
org.apache.maven.plugins:maven-jxr-plugin --
org.apache.maven:maven-jxr
On Sat, Jul 16, 2011 at 5:06 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
+1
tested in Maven 3.0.4-SNAPSHOT [1] (sync pending)
notice that there are some glitches with documentation:
- plugin-info.html isn't there nor goals documentation (?)
- aggregating example should be modified like javadoc to show new goals and
mark aggregate parameter as obsolete
nothing that prevents plugin release, but these should be fixed when the site
is published
Regards,
Hervé
Le vendredi 15 juillet 2011, Benson Margulies a écrit :
Hi,
We solved 6 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=ACIO-CAVI-QX7G-9
IAS|939d07db80126b429369a4acdb3a1c32519711ef|linversion=16520styleName=Te
xtprojectId=11085Create=Create
There are still a gaggle of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=pro
ject+%3D+JXR+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide
Staging repo:
https://repository.apache.org/content/repositories/maven-028/
Staging sites:
maven.apache.org/plugins/maven-jxr-plugin/staging
maven.apache.org/jxr/staging
Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html
Vote open for at leasr 72 hours.
[ ] +1
[ ] +0
[ ] -1
-
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: r1147613 - in /maven/jxr/trunk: maven-jxr-plugin/pom.xml maven-jxr/pom.xml pom.xml
Lukas,
I'm beginning to think that I did something specially stupid when I
staged the site for the vote, like forget -Preporting. On the other
hand, the additional commentary on the deprecated parameter wasn't
there until about 2 minutes ago.
I'm going to go to target/checkout and redo things and see what pops out.
--benson
On Sun, Jul 17, 2011 at 10:54 AM, Lukas Theussl ltheu...@apache.org wrote:
Benson: I have locally built and staged the site before and after this
commit and I don't see any of the mentioned issues. Have you actually
checked your local site? Did you run the site phase or the site:site goal?
Anyway, with site-plugin-2.3 the locally built and stage(-deployed) sites
should be completely identical.
-Lukas
bimargul...@apache.org wrote:
Author: bimargulies
Date: Sun Jul 17 13:49:35 2011
New Revision: 1147613
URL: http://svn.apache.org/viewvc?rev=1147613view=rev
Log:
Copy more configuration from the standard plugin parent to see if I can't
fix up the site issues that Hervé
pointed out. This is certainly not all the fixes needed.
Modified:
maven/jxr/trunk/maven-jxr-plugin/pom.xml
maven/jxr/trunk/maven-jxr/pom.xml
maven/jxr/trunk/pom.xml
Modified: maven/jxr/trunk/maven-jxr-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/maven-jxr-plugin/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/maven-jxr-plugin/pom.xml (original)
+++ maven/jxr/trunk/maven-jxr-plugin/pom.xml Sun Jul 17 13:49:35 2011
@@ -48,7 +48,7 @@ under the License.
properties
mavenVersion2.0.9/mavenVersion
-sitePluginVersion2.2/sitePluginVersion
+sitePluginVersion2.3/sitePluginVersion
doxia-sitetoolsVersion1.2/doxia-sitetoolsVersion
doxiaVersion1.2/doxiaVersion
/properties
@@ -73,10 +73,6 @@ under the License.
forkModealways/forkMode
/configuration
/plugin
-plugin
-artifactIdmaven-site-plugin/artifactId
-version${sitePluginVersion}/version
-/plugin
/plugins
/pluginManagement
@@ -84,6 +80,7 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
+ version2.8/version
executions
execution
idgenerated-helpmojo/id
@@ -185,6 +182,7 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
+ version2.8/version
/plugin
/plugins
/reporting
@@ -235,7 +233,7 @@ under the License.
/file
/activation
properties
-sitePluginVersion3.0-beta-1-SNAPSHOT/sitePluginVersion
+sitePluginVersion3.0-beta-4-SNAPSHOT/sitePluginVersion
/properties
/profile
@@ -246,13 +244,13 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
-version2.5/version
+version2.8/version
configuration
tagletArtifacts
tagletArtifact
groupIdorg.apache.maven.plugin-tools/groupId
artifactIdmaven-plugin-tools-javadoc/artifactId
-version2.5/version
+version2.8/version
/tagletArtifact
tagletArtifact
groupIdorg.codehaus.plexus/groupId
Modified: maven/jxr/trunk/maven-jxr/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/maven-jxr/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/maven-jxr/pom.xml (original)
+++ maven/jxr/trunk/maven-jxr/pom.xml Sun Jul 17 13:49:35 2011
@@ -101,6 +101,7 @@ under the License.
/site
/distributionManagement
+
dependencies
dependency
groupIdjunit/groupId
Modified: maven/jxr/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/pom.xml (original)
+++ maven/jxr/trunk/pom.xml Sun Jul 17 13:49:35 2011
@@ -60,6 +60,7 @@ under the License.
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
+ scopetest/scope
version4.8.2/version
/dependency
/dependencies
@@ -69,6 +70,13 @@ under the License.
pluginManagement
plugins
plugin
+artifactIdmaven-site-plugin/artifactId
+ version2.3/version
+configuration
+stagingSiteURLscp://people.apache.org/www/maven.apache.org/jxr/${project.artifactId}-${project.version}/stagingSiteURL
+/configuration
+/plugin
+plugin
artifactIdmaven-release-plugin/artifactId
configuration
tagBasehttps://svn.apache.org/repos/asf/maven/jxr/tags/tagBase
Re: [DISCUSS] incorporate EPL Aether
On Jul 17, 2011, at 7:45 AM, Benson Margulies wrote: So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Sure, those are only my personal .02! It's a majority vote so it's not black/white of course. It's also not a problem with EPL but just my personal thoughts about our (the Apache Maven projects) ability to maintain Maven if a bug gets found. In my opinion we just cannot guarantee that bugs in Maven which are caused by a bug in aether can get effectively fixed. We just don't have it under our own control if there is no safety net of being able to fork-and-fix anymore. Btw, the Eclipse Foundation effectively demised projects because of external dependencies which are not under their control. And that also had nothing to do with any sentiment regarding a particular license but solely with the question of the maintainability. LieGrue, strub --- On Sun, 7/17/11, Ralph Goers ralph.go...@dslextreme.com wrote: From: Ralph Goers ralph.go...@dslextreme.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 3:47 PM On Jul 17, 2011, at 7:45 AM, Benson Margulies wrote: So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. 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: [DISCUSS] incorporate EPL Aether
I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. I don't follow your last sentence. I just submitted a patch to Aether, and it was cordially received, but there is, of course, no guarantee. This thread started out as a discussion of licensing, not control. If Sonatype put the dual license back today, there would be no vote required to update to a new version of Aether, and mods to Aether would still require cooperation with Sonatype. So, I can imagine a thread of discussion about forking Aether (or anything else) to achieve control, but that's not this thread. My primary view in opposition to forking is the this: Sonatype and the Maven PMC share an interest in the success of Maven. The current situation isn't ideal, but it could be a whole lot worse. Based on recent history, I don't personally believe that dramatic tactics are the best option to achieve cooperation here. Forking would, in my opinion, come in under the category of 'a dramatic tactic.' My secondary argument has to do with workload. This development community is trying to maintain a giant raft of stuff. Deciding to fork these components without any visible plan to find the effort to work on them would be, in my opinion, 'shooting ourselves in the feet'. I might go so far as to ask people proposing a fork to list their recent commits to core Maven code. Another way to put this: If there is a majority of PMC members willing to vote +1 to just accept Aether as EPL (which means more work if relations with Sonatype degenerate and we wish to disentangle), let's do that. If there isn't, then the next step in my view is to talk to Sonatype about the dual license. I personally thing that it is nuts to fork without talking to Sonatype first. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1147613 - in /maven/jxr/trunk: maven-jxr-plugin/pom.xml maven-jxr/pom.xml pom.xml
Lukas,
My brain hurts.
I republished http://maven.apache.org/staging/plugins/maven-jxr-plugin/
from the tag via
/opt/apache-maven-2.2.1/bin/mvn clean install site site:stage-deploy -Preporting
I bumped site plugin to 2.3 to avoid authentication issues.
plugin-info.html is still missing in there.
On Sun, Jul 17, 2011 at 10:54 AM, Lukas Theussl ltheu...@apache.org wrote:
Benson: I have locally built and staged the site before and after this
commit and I don't see any of the mentioned issues. Have you actually
checked your local site? Did you run the site phase or the site:site goal?
Anyway, with site-plugin-2.3 the locally built and stage(-deployed) sites
should be completely identical.
-Lukas
bimargul...@apache.org wrote:
Author: bimargulies
Date: Sun Jul 17 13:49:35 2011
New Revision: 1147613
URL: http://svn.apache.org/viewvc?rev=1147613view=rev
Log:
Copy more configuration from the standard plugin parent to see if I can't
fix up the site issues that Hervé
pointed out. This is certainly not all the fixes needed.
Modified:
maven/jxr/trunk/maven-jxr-plugin/pom.xml
maven/jxr/trunk/maven-jxr/pom.xml
maven/jxr/trunk/pom.xml
Modified: maven/jxr/trunk/maven-jxr-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/maven-jxr-plugin/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/maven-jxr-plugin/pom.xml (original)
+++ maven/jxr/trunk/maven-jxr-plugin/pom.xml Sun Jul 17 13:49:35 2011
@@ -48,7 +48,7 @@ under the License.
properties
mavenVersion2.0.9/mavenVersion
-sitePluginVersion2.2/sitePluginVersion
+sitePluginVersion2.3/sitePluginVersion
doxia-sitetoolsVersion1.2/doxia-sitetoolsVersion
doxiaVersion1.2/doxiaVersion
/properties
@@ -73,10 +73,6 @@ under the License.
forkModealways/forkMode
/configuration
/plugin
-plugin
-artifactIdmaven-site-plugin/artifactId
-version${sitePluginVersion}/version
-/plugin
/plugins
/pluginManagement
@@ -84,6 +80,7 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
+ version2.8/version
executions
execution
idgenerated-helpmojo/id
@@ -185,6 +182,7 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-plugin-plugin/artifactId
+ version2.8/version
/plugin
/plugins
/reporting
@@ -235,7 +233,7 @@ under the License.
/file
/activation
properties
-sitePluginVersion3.0-beta-1-SNAPSHOT/sitePluginVersion
+sitePluginVersion3.0-beta-4-SNAPSHOT/sitePluginVersion
/properties
/profile
@@ -246,13 +244,13 @@ under the License.
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
-version2.5/version
+version2.8/version
configuration
tagletArtifacts
tagletArtifact
groupIdorg.apache.maven.plugin-tools/groupId
artifactIdmaven-plugin-tools-javadoc/artifactId
-version2.5/version
+version2.8/version
/tagletArtifact
tagletArtifact
groupIdorg.codehaus.plexus/groupId
Modified: maven/jxr/trunk/maven-jxr/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/maven-jxr/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/maven-jxr/pom.xml (original)
+++ maven/jxr/trunk/maven-jxr/pom.xml Sun Jul 17 13:49:35 2011
@@ -101,6 +101,7 @@ under the License.
/site
/distributionManagement
+
dependencies
dependency
groupIdjunit/groupId
Modified: maven/jxr/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/maven/jxr/trunk/pom.xml?rev=1147613r1=1147612r2=1147613view=diff
==
--- maven/jxr/trunk/pom.xml (original)
+++ maven/jxr/trunk/pom.xml Sun Jul 17 13:49:35 2011
@@ -60,6 +60,7 @@ under the License.
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
+ scopetest/scope
version4.8.2/version
/dependency
/dependencies
@@ -69,6 +70,13 @@ under the License.
pluginManagement
plugins
plugin
+artifactIdmaven-site-plugin/artifactId
+ version2.3/version
+configuration
+stagingSiteURLscp://people.apache.org/www/maven.apache.org/jxr/${project.artifactId}-${project.version}/stagingSiteURL
+/configuration
+/plugin
+plugin
artifactIdmaven-release-plugin/artifactId
configuration
tagBasehttps://svn.apache.org/repos/asf/maven/jxr/tags/tagBase
Re: svn commit: r1147613 - in /maven/jxr/trunk: maven-jxr-plugin/pom.xml maven-jxr/pom.xml pom.xml
OK, I got it. Without plugin-plugin 2.8, the plugin-info doesn't appear. I've restaged. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Sure, if aether gets back being dual licensing then all would be fine. The Maven project has good relationship with Sonatype so I'm sure the EPL is not a problem today. But if the license is not a CategoryA license, then we cannot make sure it will not become a problem in the future. Because we cannot fork it and maintain it ourself in case any problem arises! So - from a pure manager perspective - this is a imo no-go. You would also not build your business on pure good will, isn't? LieGrue, strub --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 4:08 PM I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. I don't follow your last sentence. I just submitted a patch to Aether, and it was cordially received, but there is, of course, no guarantee. This thread started out as a discussion of licensing, not control. If Sonatype put the dual license back today, there would be no vote required to update to a new version of Aether, and mods to Aether would still require cooperation with Sonatype. So, I can imagine a thread of discussion about forking Aether (or anything else) to achieve control, but that's not this thread. My primary view in opposition to forking is the this: Sonatype and the Maven PMC share an interest in the success of Maven. The current situation isn't ideal, but it could be a whole lot worse. Based on recent history, I don't personally believe that dramatic tactics are the best option to achieve cooperation here. Forking would, in my opinion, come in under the category of 'a dramatic tactic.' My secondary argument has to do with workload. This development community is trying to maintain a giant raft of stuff. Deciding to fork these components without any visible plan to find the effort to work on them would be, in my opinion, 'shooting ourselves in the feet'. I might go so far as to ask people proposing a fork to list their recent commits to core Maven code. Another way to put this: If there is a majority of PMC members willing to vote +1 to just accept Aether as EPL (which means more work if relations with Sonatype degenerate and we wish to disentangle), let's do that. If there isn't, then the next step in my view is to talk to Sonatype about the dual license. I personally thing that it is nuts to fork without talking to Sonatype first. - 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: [DISCUSS] incorporate EPL Aether
On Jul 17, 2011, at 11:55 AM, Mark Struberg wrote: Sure, those are only my personal .02! It's a majority vote so it's not black/white of course. It's also not a problem with EPL but just my personal thoughts about our (the Apache Maven projects) ability to maintain Maven if a bug gets found. In my opinion we just cannot guarantee that bugs in Maven which are caused by a bug in aether can get effectively fixed. We just don't have it under our own control if there is no safety net of being able to fork-and-fix anymore. Btw, the Eclipse Foundation effectively demised projects because of external dependencies which are not under their control. And that also had nothing to do with any sentiment regarding a particular license but solely with the question of the maintainability. Which projects are those? There are currently 85 libraries in Orbit (the IP approved repository of 3rd party components) from Apache[1] used across many projects at Eclipse. Apache doesn't have any definitive list of approved 3rd party libraries so it's hard to make a comparison but I don't believe Eclipse has a problem using code from Apache. [1]: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.orbit/?root=Tools_Project LieGrue, strub --- On Sun, 7/17/11, Ralph Goers ralph.go...@dslextreme.com wrote: From: Ralph Goers ralph.go...@dslextreme.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 3:47 PM On Jul 17, 2011, at 7:45 AM, Benson Margulies wrote: So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: [DISCUSS] incorporate EPL Aether
Hi Jason! Eclipse doesn't have problems with consuming ALv2 dependencies because ALv2 explicitly allows sublicensing - but EPL doesn't! So this is an unidirectional way and exactly the reason why we imo cannot do this. Btw, you should know exactly how hard it is to pass Eclipse' IP review and stuff. Wasn't that the reason why you needed to drop a few plexus dependencies because of uncertain IP? They are careful, which is a good thing. Couldn't you just put the ALv2/EPL dual licensing back in place and all are happy? Noone of us is eager to maintain aether or to fork it if not necessary. But otoh not being able to fork it if there were problems is imo a no-go. Also, there are a few contributors eager to ship patches it seems... txs and LieGrue, strub --- On Sun, 7/17/11, Jason van Zyl ja...@sonatype.com wrote: From: Jason van Zyl ja...@sonatype.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 4:36 PM On Jul 17, 2011, at 11:55 AM, Mark Struberg wrote: Sure, those are only my personal .02! It's a majority vote so it's not black/white of course. It's also not a problem with EPL but just my personal thoughts about our (the Apache Maven projects) ability to maintain Maven if a bug gets found. In my opinion we just cannot guarantee that bugs in Maven which are caused by a bug in aether can get effectively fixed. We just don't have it under our own control if there is no safety net of being able to fork-and-fix anymore. Btw, the Eclipse Foundation effectively demised projects because of external dependencies which are not under their control. And that also had nothing to do with any sentiment regarding a particular license but solely with the question of the maintainability. Which projects are those? There are currently 85 libraries in Orbit (the IP approved repository of 3rd party components) from Apache[1] used across many projects at Eclipse. Apache doesn't have any definitive list of approved 3rd party libraries so it's hard to make a comparison but I don't believe Eclipse has a problem using code from Apache. [1]: http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.orbit/?root=Tools_Project LieGrue, strub --- On Sun, 7/17/11, Ralph Goers ralph.go...@dslextreme.com wrote: From: Ralph Goers ralph.go...@dslextreme.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 3:47 PM On Jul 17, 2011, at 7:45 AM, Benson Margulies wrote: So, the document states that the PMC decided that category B's are acceptable by majority vote. As per standard ASF community norms, it's better to give people a chance to achieve consensus and vote to affirm it than to just stage a vote straight off, so here we are. I do not think that Mark's view that all these components should fork is a viable plan for this community, but I don't feel inclined to elaborate at this point. I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
On Jul 17, 2011, at 9:08 AM, Benson Margulies wrote: I think you are going to have to. Mark isn't the only one who has expressed the sentiment. Some of the discussions I've seen on changing the relationship Maven has with repository managers would surely require changes at the Aether layer. I don't follow your last sentence. I just submitted a patch to Aether, and it was cordially received, but there is, of course, no guarantee. This thread started out as a discussion of licensing, not control. If Sonatype put the dual license back today, there would be no vote required to update to a new version of Aether, and mods to Aether would still require cooperation with Sonatype. There have been discussions regarding whether having a central repository is a good thing. With Aether as a separate project Maven itself can't really do much to change that. While you are correct that putting the dual license back wouldn't require a vote, what it would mean is that if someone decided to innovate and create a different way of doing things they could start with the existing Aether code base at any point in time. As it stands, they would either have to go back to the last point that Aether was under the Apache license, which becomes less and less possible as time goes on and changes are made, or convince the Aether community to incorporate their changes, which is probably a much harder sell then just changing Maven. I agree that I only see the 3 choices you presented and the most favorable would be to have Aether continue to be dual licensed. When it comes to which of the other 2 options are better than I see pluses and minuses on both sides. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
There's a technical point of interest here. Aether has a very extensive separation of interface and implementation. So, there's a great deal that we could do unilaterally while still using the EPL core. The existence of 'central', I'm reasonably sure, is not inside of Aether itself at all. I don't expect this to be a killer argument in any direction, but I thought it was worth noting. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
'central' is defined in pom-4.0.0.xml [1] which resides in maven core. LieGrue, strub [1] http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml --- On Sun, 7/17/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Sunday, July 17, 2011, 7:44 PM There's a technical point of interest here. Aether has a very extensive separation of interface and implementation. So, there's a great deal that we could do unilaterally while still using the EPL core. The existence of 'central', I'm reasonably sure, is not inside of Aether itself at all. I don't expect this to be a killer argument in any direction, but I thought it was worth noting. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
sø., 17.07.2011 kl. 09.26 -0400, skrev Benson Margulies: After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. Hervé and I are aether committers, and if I wasn't so /extremely busy/ here on Mallorca I'd look at your patch. Opposed to Mark and Ralph, I have no qualms accepting an EPL 3rd party dependency, If you start showing an interest in aether matters I'm sure you'll get that commit bit pretty quickly yourself. I really just want to get over this license-of-the week crap we've been seeing for aether and sisu, which I think is totally unacceptable. Assuming aether actually goes to stay at eclipse I'm happy with that, until so happens I still want to keep the asl version (and fork if necessary). Technically, not that much has happened since the last ASL versioned aether, so there's no real gap to talk about. I /wish/ there was some kind of change in the pipeline that I could say made the aether/maven split problematic. But there isn't, is there ? I am much more worried about change in maven at a higher level than interfaces. I somehow sense that pom version 5 is never going to happen; but that's not aether's fault..? Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
kristian, I want to repeat that b.b. has been perfectly hospitable about my little patch and proposal for a bigger one. your message, with which I have no disagreement, might give a casual reader another impression. On Jul 17, 2011, at 4:35 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: sø., 17.07.2011 kl. 09.26 -0400, skrev Benson Margulies: After re-reading the ASF legal licensing policy, I'm starting this thread to formally propose that the Maven incorporate versions of Aether that are EPL without an AL dual-license. As per convention, someone can make a VOTE thread once voices have been heard here. EPL is 'Category B'. Binary redistribution with a notice is acceptable. Maven incorporated many plexus components, and at least some of them have IP question marks hanging over them (c.f. the discussion of the plexus-utils replacement). I, therefore, don't see any real impact on the users of Maven in adopting EPL copies of Aether. To the extent that Maven is a development tool, the user impact of category B components is lighter than with something that is routinely incorporated in larger systems. To the extent, on the other hand, that Maven is embeddable, this could be a problem for someone. However, that argument would make a lot more sense if every other scrap of the ecosystem were fully-vetted category A. Someone might wonder, 'Why has Benson decided to tilt at this particular windmill?' Well, some itches of mine have led into Aether, and I'd feel fairly silly investing a lot of time and energy in Aether patches that will never see the light of day in Maven. So, I'm inclined to push the community to choose a course of action. I see three possibilities: 1) Just make the notice arrangements to use Aether under EPL. 2) Actively see if Sonatype will put the dual license back. 3) Fork the last dual version. Hervé and I are aether committers, and if I wasn't so /extremely busy/ here on Mallorca I'd look at your patch. Opposed to Mark and Ralph, I have no qualms accepting an EPL 3rd party dependency, If you start showing an interest in aether matters I'm sure you'll get that commit bit pretty quickly yourself. I really just want to get over this license-of-the week crap we've been seeing for aether and sisu, which I think is totally unacceptable. Assuming aether actually goes to stay at eclipse I'm happy with that, until so happens I still want to keep the asl version (and fork if necessary). Technically, not that much has happened since the last ASL versioned aether, so there's no real gap to talk about. I /wish/ there was some kind of change in the pipeline that I could say made the aether/maven split problematic. But there isn't, is there ? I am much more worried about change in maven at a higher level than interfaces. I somehow sense that pom version 5 is never going to happen; but that's not aether's fault..? Kristian - 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
dependency plugin versus Aether
Since I've gone and given myself a crash course in Aether, I wondered if I could do something about the dependency plugin issue (of disagreeing with maven proper). I didn't get very far; I can't even figure out which JIRA in MDEP corresponds to it. Could someone please send me a pointer? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
the pom compatibility threads
Many threads lead back to the recent discussion, and all of its predecessors, about preparing for a new version of the pom by allowing for backwards compatibility. How do we start this? There seemed a consensus on the design. Do we need some branches of things? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the pom compatibility threads
For me the first thing is to push some ideas in the wiki and make them challenged by developpers I'm not so sure that there is a consensus and a real proposal to solve that upgrade taking care of all use cases (previous/future versions of maven, transitive dependencies, depMgt import, inheritence ...) The thing said by everybody is that we won't be able to change the format/version of *.pom files in shared repositories but I saw no real proposal to manage all cases listed above when we'll have several versions of POMs out (even if we just add new entries). Arnaud On Sun, Jul 17, 2011 at 11:33 PM, Benson Margulies bimargul...@gmail.comwrote: Many threads lead back to the recent discussion, and all of its predecessors, about preparing for a new version of the pom by allowing for backwards compatibility. How do we start this? There seemed a consensus on the design. Do we need some branches of things? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: the pom compatibility threads
OK, I'm willing to write what I think I understood. 2011/7/17 Arnaud Héritier aherit...@gmail.com: For me the first thing is to push some ideas in the wiki and make them challenged by developpers I'm not so sure that there is a consensus and a real proposal to solve that upgrade taking care of all use cases (previous/future versions of maven, transitive dependencies, depMgt import, inheritence ...) The thing said by everybody is that we won't be able to change the format/version of *.pom files in shared repositories but I saw no real proposal to manage all cases listed above when we'll have several versions of POMs out (even if we just add new entries). Arnaud On Sun, Jul 17, 2011 at 11:33 PM, Benson Margulies bimargul...@gmail.comwrote: Many threads lead back to the recent discussion, and all of its predecessors, about preparing for a new version of the pom by allowing for backwards compatibility. How do we start this? There seemed a consensus on the design. Do we need some branches of things? - 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: the pom compatibility threads
I don't seem to have karma for https://cwiki.apache.org/confluence/display/MAVEN/Proposals?showChildren=true#children. Can I? 2011/7/17 Arnaud Héritier aherit...@gmail.com: For me the first thing is to push some ideas in the wiki and make them challenged by developpers I'm not so sure that there is a consensus and a real proposal to solve that upgrade taking care of all use cases (previous/future versions of maven, transitive dependencies, depMgt import, inheritence ...) The thing said by everybody is that we won't be able to change the format/version of *.pom files in shared repositories but I saw no real proposal to manage all cases listed above when we'll have several versions of POMs out (even if we just add new entries). Arnaud On Sun, Jul 17, 2011 at 11:33 PM, Benson Margulies bimargul...@gmail.comwrote: Many threads lead back to the recent discussion, and all of its predecessors, about preparing for a new version of the pom by allowing for backwards compatibility. How do we start this? There seemed a consensus on the design. Do we need some branches of things? - 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
