Re: broken test in maven-javadoc-plugin
yes, I tried too and couldn't find (then chose to continue on m-site-p...), but your conclusion is really plausible I tried on every CI failures, fixed what I could fix, but actual failures are really hard to fix (AFAIK, were the same on previous Sonatype's CI, then there is really some logic in them, not only bad specific configuration): thanks for your work and sharing once the CI will be fully ok, we'll have to celebrate! :) Regards, Hervé Le vendredi 29 juillet 2011, Dennis Lundberg a écrit : Hi Mark I spent a couple of hours debugging this earlier this week. Unfortunately I wasn't able to crack it. But I find your conclusion very plausible. On 2011-07-29 16:22, Mark Struberg wrote: Hi! This is a sum-up of my last 5 hours of debugging. Currently there is a failing test in the maven-javadoc-plugin: JavadocReportTest#testProxy() This test fails since the last commit but I actually think it only ever worked by accident. It did rely on a commons-logging-1.0.4.pom which got resolved by a test which did run previously. But after updating to commons-logging.1.1.1 there is no pre-resolved artifact available in target/local-repo anymore, thus the javadoc link info cannot get built and the test fails in line 829: assertTrue( optionsContent.contains( -link 'http://commons.apache.org/logging/apidocs' ) ); I'll for now just disable this line of code, because the test as far as I can see _never_ did go upstream. The remoteRepository list used is always empty!. If anyone has an idea how to get this fixed properly, then please speak up ;) LieGrue, strug - 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: broken test in maven-javadoc-plugin
This sounds VERY much like the problem Richard Vowles reported awhile back which is solved by ungrading Maven to use Aether 1.12. The problem lies in having some artifcts downloaded directly, some from a mirror. Maven generates a metadata file which includes a references to the upstream repository id used originally to fetch the artifact, and when you run a project that doesn't match that - the artifact gets reported as not being found - even if it is. ( at least, thats my simple summation ). http://jira.codehaus.org/browse/MNG-5084 was the ticket that Richard raised. Sadly it looks like no one on the Apache team has responded to either Richard or my queries about this problem, tho I did discover that Aether 1.12 actually fixes the problem - unfortunately due to the EPL license change ( see other threads ) I'm not sure when we will see this fixed. Jason van Zyl has made available a distro/packaging of maven with additional fixes ( see his thread about that for details ) , including this Aether release - I wonder if you could try that and see if this solves the problem you're seeing? On 30/07/2011, at 2:22 AM, Mark Struberg wrote: This test fails since the last commit but I actually think it only ever worked by accident. It did rely on a commons-logging-1.0.4.pom which got resolved by a test which did run previously. But after updating to commons-logging.1.1.1 there is no pre-resolved artifact available in target/local-repo anymore, thus the javadoc link info cannot get built and the test fails in line 829: assertTrue( optionsContent.contains( -link 'http://commons.apache.org/logging/apidocs' ) );
RE: non-reproducible issues on CI
Hi Martin! Good idea basically. But nope, both snapshots and releases are set to true. LieGrue, strub --- On Sat, 7/30/11, Martin Gainty mgai...@hotmail.com wrote: From: Martin Gainty mgai...@hotmail.com Subject: RE: non-reproducible issues on CI To: dev@maven.apache.org Date: Saturday, July 30, 2011, 2:02 AM Mark- ..do you have snapshots enabled false for your repository..e.g repositories repository snapshots enabledfalse/enabled /snapshots /repository /repositories Liebe GruBe Martin Date: Sat, 30 Jul 2011 00:22:12 +0100 From: strub...@yahoo.de Subject: non-reproducible issues on CI To: dev@maven.apache.org Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.sonatype.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:282) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:316) at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:115) ... 20 more Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541) at
Re: broken test in maven-javadoc-plugin
Hi! Thanks for the info. I'll take the latest ALv2 licensed version of Aether and try to tinker a fix. But this will only happen next week since I'm now off to the country with my family. LieGrue, strub --- On Sat, 7/30/11, Mark Derricutt m...@talios.com wrote: From: Mark Derricutt m...@talios.com Subject: Re: broken test in maven-javadoc-plugin To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 7:22 AM This sounds VERY much like the problem Richard Vowles reported awhile back which is solved by ungrading Maven to use Aether 1.12. The problem lies in having some artifcts downloaded directly, some from a mirror. Maven generates a metadata file which includes a references to the upstream repository id used originally to fetch the artifact, and when you run a project that doesn't match that - the artifact gets reported as not being found - even if it is. ( at least, thats my simple summation ). http://jira.codehaus.org/browse/MNG-5084 was the ticket that Richard raised. Sadly it looks like no one on the Apache team has responded to either Richard or my queries about this problem, tho I did discover that Aether 1.12 actually fixes the problem - unfortunately due to the EPL license change ( see other threads ) I'm not sure when we will see this fixed. Jason van Zyl has made available a distro/packaging of maven with additional fixes ( see his thread about that for details ) , including this Aether release - I wonder if you could try that and see if this solves the problem you're seeing? On 30/07/2011, at 2:22 AM, Mark Struberg wrote: This test fails since the last commit but I actually think it only ever worked by accident. It did rely on a commons-logging-1.0.4.pom which got resolved by a test which did run previously. But after updating to commons-logging.1.1.1 there is no pre-resolved artifact available in target/local-repo anymore, thus the javadoc link info cannot get built and the test fails in line 829: assertTrue( optionsContent.contains( -link 'http://commons.apache.org/logging/apidocs' ) ); - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: non-reproducible issues on CI
Hi I've seen this kind of error at my day job a couple of times. Although I'm sure sure why they happen, I do know how to get rid of it. You need to manually remove the offending artifact from the local repo to get a freshly downloaded copy of it. By removing all versions of the artifact, including the meta data you ensure that the corrupt meta data will also be removed. The only reason I can think of as to why it happens is that the repository don't respond when the artifact is being downloaded for the first time. That puts some special meta data in the local repository. That meta data looks like it is supposed to help determine when the failed attempt occurred. This somehow blocks any further download of the artifact in question. Even forcing a new download via command line option have failed for us. I haven't reported it in JIRA yet because I don't have anything even remotely reproducible. On 2011-07-30 01:22, Mark Struberg wrote: Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.sonatype.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:282) at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:316) at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:115) ... 20 more Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was
Re: non-reproducible issues on CI
Might be if the metadata got downloaded but the artifact (a fat jar for example) didn't make it? I bet there are situations where such things still might end ugly. Just for the record: I'm currently looking at maven-repository-plugin BundleCreateIT#createWithSCMInfoProvided(). It looks like this issue only hits ITs. Here is the local IT repo on our CI box: https://builds.apache.org/job/maven-plugins-ITs-3.x/ws/maven-repository-plugin/target/it-repo/ A comparison of the artifacts I get locally shows that commons-cli-1.0 and commons-lang-2.1 don't make it on the CI box. I'll try to ping infra and get drop them from our jenkins repo cache. LieGrue, strub --- On Sat, 7/30/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: non-reproducible issues on CI To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 8:31 AM Hi I've seen this kind of error at my day job a couple of times. Although I'm sure sure why they happen, I do know how to get rid of it. You need to manually remove the offending artifact from the local repo to get a freshly downloaded copy of it. By removing all versions of the artifact, including the meta data you ensure that the corrupt meta data will also be removed. The only reason I can think of as to why it happens is that the repository don't respond when the artifact is being downloaded for the first time. That puts some special meta data in the local repository. That meta data looks like it is supposed to help determine when the failed attempt occurred. This somehow blocks any further download of the artifact in question. Even forcing a new download via command line option have failed for us. I haven't reported it in JIRA yet because I don't have anything even remotely reproducible. On 2011-07-30 01:22, Mark Struberg wrote: Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.sonatype.aether.resolution.ArtifactDescriptorException: Failed to read
Re: [DISCUSS] SCM child-project URL composition
i think I'm missing something. My understanding has been that any file named pom.xml that isn't compliant with 4.0.0 is going to break Maven 2 users. Am I misunderstanding something about what is being proposed? Ralph On Jul 29, 2011, at 8:04 AM, Benson Margulies wrote: I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - 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 - 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: non-reproducible issues on CI
I replied to the other thread saying it sounded similar to MNG-5084 [1] - if that sounds like it to you add your votes to the ticket. [1] http://jira.codehaus.org/browse/MNG-5084 On 30/07/2011, at 8:31 PM, Dennis Lundberg wrote: I haven't reported it in JIRA yet because I don't have anything even remotely reproducible.
Re: [VOTE] Incorporate EPL Ether in Maven Releases
I'm in the same boat. I can't in good conscience vote -1 because I am in no position to take on the task of doing a rewrite. OTOH, given the things people have said they would really like to do I am pretty sure this issue is going to keep coming up. For the same reasons as yours I'm going to have to vote -0. Ralph On Jul 29, 2011, at 10:16 AM, Brett Porter wrote: -0 I don't like it, but I'm not the one doing the work. I'd accept it if there's no better way to get the problems fixed for whoever is working to fix them. I don't think it's good to get stuck on an old version no one is maintaining. I'm happy to discuss ideas for alternatives. However, I would strongly prefer it to remain dual licensed: - it gives us more options if we need to incorporate source code changes that aren't accepted upstream, particularly if goals change over time - consumers know what they are getting from Maven - it can all be used under the terms of the AL 2.0. - it had the terms of the AL 2.0 when we agreed to incorporate it I continue to hope that will be reconsidered. FWIW, I don't have any argument with regard to the EPL as a license, I just believe AL 2.0 is appropriate here given its history, the early state of community development, and with Maven as its primary consumer. - Brett On 28/07/2011, at 4:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: non-reproducible issues on CI
Hi! I'll try to reproduce it on the weekend. LieGrue, strub --- On Sat, 7/30/11, Mark Derricutt m...@talios.com wrote: From: Mark Derricutt m...@talios.com Subject: Re: non-reproducible issues on CI To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 8:54 AM I replied to the other thread saying it sounded similar to MNG-5084 [1] - if that sounds like it to you add your votes to the ticket. [1] http://jira.codehaus.org/browse/MNG-5084 On 30/07/2011, at 8:31 PM, Dennis Lundberg wrote: I haven't reported it in JIRA yet because I don't have anything even remotely reproducible. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: non-reproducible issues on CI
On 2011-07-30 10:54, Mark Struberg wrote: Might be if the metadata got downloaded but the artifact (a fat jar for example) didn't make it? I bet there are situations where such things still might end ugly. Just for the record: I'm currently looking at maven-repository-plugin BundleCreateIT#createWithSCMInfoProvided(). It looks like this issue only hits ITs. Here is the local IT repo on our CI box: https://builds.apache.org/job/maven-plugins-ITs-3.x/ws/maven-repository-plugin/target/it-repo/ A comparison of the artifacts I get locally shows that commons-cli-1.0 and commons-lang-2.1 don't make it on the CI box. I'll try to ping infra and get drop them from our jenkins repo cache. That should be directed to builds@a.o I'm a recent subscriber there, so I can ask them. LieGrue, strub --- On Sat, 7/30/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: non-reproducible issues on CI To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 8:31 AM Hi I've seen this kind of error at my day job a couple of times. Although I'm sure sure why they happen, I do know how to get rid of it. You need to manually remove the offending artifact from the local repo to get a freshly downloaded copy of it. By removing all versions of the artifact, including the meta data you ensure that the corrupt meta data will also be removed. The only reason I can think of as to why it happens is that the repository don't respond when the artifact is being downloaded for the first time. That puts some special meta data in the local repository. That meta data looks like it is supposed to help determine when the failed attempt occurred. This somehow blocks any further download of the artifact in question. Even forcing a new download via command line option have failed for us. I haven't reported it in JIRA yet because I don't have anything even remotely reproducible. On 2011-07-30 01:22, Mark Struberg wrote: Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at
Re: non-reproducible issues on CI
gav dropped it already (pinged him on IRC). Build #152 is currently running. LieGrue, strub --- On Sat, 7/30/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: non-reproducible issues on CI To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 9:55 AM On 2011-07-30 10:54, Mark Struberg wrote: Might be if the metadata got downloaded but the artifact (a fat jar for example) didn't make it? I bet there are situations where such things still might end ugly. Just for the record: I'm currently looking at maven-repository-plugin BundleCreateIT#createWithSCMInfoProvided(). It looks like this issue only hits ITs. Here is the local IT repo on our CI box: https://builds.apache.org/job/maven-plugins-ITs-3.x/ws/maven-repository-plugin/target/it-repo/ A comparison of the artifacts I get locally shows that commons-cli-1.0 and commons-lang-2.1 don't make it on the CI box. I'll try to ping infra and get drop them from our jenkins repo cache. That should be directed to builds@a.o I'm a recent subscriber there, so I can ask them. LieGrue, strub --- On Sat, 7/30/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: non-reproducible issues on CI To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 8:31 AM Hi I've seen this kind of error at my day job a couple of times. Although I'm sure sure why they happen, I do know how to get rid of it. You need to manually remove the offending artifact from the local repo to get a freshly downloaded copy of it. By removing all versions of the artifact, including the meta data you ensure that the corrupt meta data will also be removed. The only reason I can think of as to why it happens is that the repository don't respond when the artifact is being downloaded for the first time. That puts some special meta data in the local repository. That meta data looks like it is supposed to help determine when the failed attempt occurred. This somehow blocks any further download of the artifact in question. Even forcing a new download via command line option have failed for us. I haven't reported it in JIRA yet because I don't have anything even remotely reproducible. On 2011-07-30 01:22, Mark Struberg wrote: Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
Re: non-reproducible issues on CI
These jobs should use a custom repo. Trusting the built-in Jenkins repo is not wise when testing maven. It's just a checkbox in the job config. On Sat, Jul 30, 2011 at 6:09 AM, Mark Struberg strub...@yahoo.de wrote: gav dropped it already (pinged him on IRC). Build #152 is currently running. LieGrue, strub --- On Sat, 7/30/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: non-reproducible issues on CI To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 9:55 AM On 2011-07-30 10:54, Mark Struberg wrote: Might be if the metadata got downloaded but the artifact (a fat jar for example) didn't make it? I bet there are situations where such things still might end ugly. Just for the record: I'm currently looking at maven-repository-plugin BundleCreateIT#createWithSCMInfoProvided(). It looks like this issue only hits ITs. Here is the local IT repo on our CI box: https://builds.apache.org/job/maven-plugins-ITs-3.x/ws/maven-repository-plugin/target/it-repo/ A comparison of the artifacts I get locally shows that commons-cli-1.0 and commons-lang-2.1 don't make it on the CI box. I'll try to ping infra and get drop them from our jenkins repo cache. That should be directed to builds@a.o I'm a recent subscriber there, so I can ask them. LieGrue, strub --- On Sat, 7/30/11, Dennis Lundberg denn...@apache.org wrote: From: Dennis Lundberg denn...@apache.org Subject: Re: non-reproducible issues on CI To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 8:31 AM Hi I've seen this kind of error at my day job a couple of times. Although I'm sure sure why they happen, I do know how to get rid of it. You need to manually remove the offending artifact from the local repo to get a freshly downloaded copy of it. By removing all versions of the artifact, including the meta data you ensure that the corrupt meta data will also be removed. The only reason I can think of as to why it happens is that the repository don't respond when the artifact is being downloaded for the first time. That puts some special meta data in the local repository. That meta data looks like it is supposed to help determine when the failed attempt occurred. This somehow blocks any further download of the artifact in question. Even forcing a new download via command line option have failed for us. I haven't reported it in JIRA yet because I don't have anything even remotely reproducible. On 2011-07-30 01:22, Mark Struberg wrote: Hi! Our CI is broken since a while and most of the errors are of the following kind: [ERROR] Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT: Failure to find org.apache.maven.plugins:maven-repository-plugin:pom:2.3.2-SNAPSHOT in /home/hudson/hudson-slave/workspace/maven-plugins-ITs-3.x/maven-repository-plugin/target/it-repo was cached in the local repository, resolution will not be reattempted until the update interval of local.central has elapsed or updates are forced - [Help 1] org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-repository-plugin:2.3.2-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-repository-plugin:jar:2.3.2-SNAPSHOT at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:129) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getPluginDescriptor(DefaultMavenPluginManager.java:142) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:261) at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185) at org.apache.maven.lifecycle.internal.MojoDescriptorCreator.getMojoDescriptor(MojoDescriptorCreator.java:235) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:106) at org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments(DefaultLifecycleTaskSegmentCalculator.java:86) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:98) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at
Re: [DISCUSS] SCM child-project URL composition
I think that your understanding is oversimplified, with all due respect. Yes, there is an xml schema emitted by modello. However, no, no version of maven checks poms against a schema. So, it is possible to make changes to the pom that are compatible with Maven 2, by the expedient of testing that they are, in fact, compatible. In particular Maven 2 pays no attention to attributes on url/ elements. So adding them can't break it. Now, anyone who adds the attributes has to use a new enough maven-release-plugin to get the benefit of them. On Sat, Jul 30, 2011 at 4:55 AM, Ralph Goers ralph.go...@dslextreme.com wrote: i think I'm missing something. My understanding has been that any file named pom.xml that isn't compliant with 4.0.0 is going to break Maven 2 users. Am I misunderstanding something about what is being proposed? Ralph On Jul 29, 2011, at 8:04 AM, Benson Margulies wrote: I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - 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 - 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
I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
well it seems to me that we need to ensure that aether is not leaking into our public api. if it is entirely private from plugins, then i really don't care if it is epl or dual... dual would be nicer, and truer to the original plan whereby the code would be developed at github for speed, and then given back to maven. that plan changed, and now the code is (likely) ending up at eclipse... Jason has reasons for eclipse... that is just reality. personally i feel that it is another merit hurdle to have the code at eclipse, but then having maven at apache is a legal pain for m2eclipse because of eclipse's ip review policy, so i can see why Jason would want as much of the code m2eclipse depends on at eclipse. in any case, let's wait - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 12:47, Benson Margulies bimargul...@gmail.com wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
I'm not binding, but I'm sad about MSITE-600, which blocks my adoption at the day job. So +0 not that it matters. On Sat, Jul 30, 2011 at 11:03 AM, Dennis Lundberg denn...@apache.org wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - 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: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
Hi Does MSITE-600 also affect maven-site-plugin version 3? If so, can you please update that JIRA to also have the appropriate 3.0 version as Affects version. On 2011-07-30 17:32, Benson Margulies wrote: I'm not binding, but I'm sad about MSITE-600, which blocks my adoption at the day job. So +0 not that it matters. On Sat, Jul 30, 2011 at 11:03 AM, Dennis Lundberg denn...@apache.org wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
The 'funny' thing is that I always hear the ranting about how complicated the code handling at Apache. But then: it took them way over 2 years to get m2eclipse cleared in Eclipse! So their arguments against the ASF are just moot. It looks like it's nothing more than a personal problem. If we have no ability to fix bugs in that stuff, then we gonna kick it out sooner or later. I'll dig into the problems we have in our CI atm, and if it turns out to be another aether bug, then I'll start a fork over to apache-extras where every Maven committer can participate if he likes. Of course, the doors are not closed, but we are currently doomed to be completely depending on an external project which was a central part of maven-core short time ago. LieGrue, strub --- On Sat, 7/30/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 1:00 PM well it seems to me that we need to ensure that aether is not leaking into our public api. if it is entirely private from plugins, then i really don't care if it is epl or dual... dual would be nicer, and truer to the original plan whereby the code would be developed at github for speed, and then given back to maven. that plan changed, and now the code is (likely) ending up at eclipse... Jason has reasons for eclipse... that is just reality. personally i feel that it is another merit hurdle to have the code at eclipse, but then having maven at apache is a legal pain for m2eclipse because of eclipse's ip review policy, so i can see why Jason would want as much of the code m2eclipse depends on at eclipse. in any case, let's wait - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 12:47, Benson Margulies bimargul...@gmail.com wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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] SCM child-project URL composition
I am aware the Maven never does schema checking but that it complains when processing the pom when it sees things that aren't part of the model. So if IIUC you are just taking advantage of a place that Maven isn't rigorous in its validation. That would be fine. Ralph On Jul 30, 2011, at 4:29 AM, Benson Margulies wrote: I think that your understanding is oversimplified, with all due respect. Yes, there is an xml schema emitted by modello. However, no, no version of maven checks poms against a schema. So, it is possible to make changes to the pom that are compatible with Maven 2, by the expedient of testing that they are, in fact, compatible. In particular Maven 2 pays no attention to attributes on url/ elements. So adding them can't break it. Now, anyone who adds the attributes has to use a new enough maven-release-plugin to get the benefit of them. On Sat, Jul 30, 2011 at 4:55 AM, Ralph Goers ralph.go...@dslextreme.com wrote: i think I'm missing something. My understanding has been that any file named pom.xml that isn't compliant with 4.0.0 is going to break Maven 2 users. Am I misunderstanding something about what is being proposed? Ralph On Jul 29, 2011, at 8:04 AM, Benson Margulies wrote: I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - 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 - 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
The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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
actually now the argument is that asf's processes are not rigorous enough! seemingly some of sonatypes customers think the asf ip process is too weak... but when i asked a certain person how the epl process was any stronger, given that they take signatures on the cla's on trust and don't verify them, it seemed to me that rather than answer they decided they were going to leave the pmc abduction resign as about asf member... or maybe that was just a co-incident... either way i never got an answer. back to the topic. mark do not rush to fork just yet. lets wait a week or two. rushed actions do not build a community, and it feels to me that everyone has been rushing their actions and making things worse for everyone. if we slow down a piece and get everyone to see some sense we might be able to get a resolution that is a win-win and a win for users too - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 17:50, Mark Struberg strub...@yahoo.de wrote: The 'funny' thing is that I always hear the ranting about how complicated the code handling at Apache. But then: it took them way over 2 years to get m2eclipse cleared in Eclipse! So their arguments against the ASF are just moot. It looks like it's nothing more than a personal problem. If we have no ability to fix bugs in that stuff, then we gonna kick it out sooner or later. I'll dig into the problems we have in our CI atm, and if it turns out to be another aether bug, then I'll start a fork over to apache-extras where every Maven committer can participate if he likes. Of course, the doors are not closed, but we are currently doomed to be completely depending on an external project which was a central part of maven-core short time ago. LieGrue, strub --- On Sat, 7/30/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 1:00 PM well it seems to me that we need to ensure that aether is not leaking into our public api. if it is entirely private from plugins, then i really don't care if it is epl or dual... dual would be nicer, and truer to the original plan whereby the code would be developed at github for speed, and then given back to maven. that plan changed, and now the code is (likely) ending up at eclipse... Jason has reasons for eclipse... that is just reality. personally i feel that it is another merit hurdle to have the code at eclipse, but then having maven at apache is a legal pain for m2eclipse because of eclipse's ip review policy, so i can see why Jason would want as much of the code m2eclipse depends on at eclipse. in any case, let's wait - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 12:47, Benson Margulies bimargul...@gmail.com wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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:
Re: [DISCUSS] incorporate EPL Aether
On 7/30/11 9:00 AM, Stephen Connolly wrote: well it seems to me that we need to ensure that aether is not leaking into our public api. if it is entirely private from plugins, then i really don't care if it is epl or dual... I agree completely. But, how can we keep it from leaking into plugins, when it's using the same plexus component system as the rest of Maven? This has long been a problem inside Maven, namely that we can't control _which_ components plugin devs have access to, and therefore we have an extremely difficult time deprecating/removing old components or reworking the internal design. Maybe firewalling and restricting the list of core components available to plugin devs is what we really need to address in order to address this concern. dual would be nicer, and truer to the original plan whereby the code would be developed at github for speed, and then given back to maven. that plan changed, and now the code is (likely) ending up at eclipse... Jason has reasons for eclipse... that is just reality. personally i feel that it is another merit hurdle to have the code at eclipse, but then having maven at apache is a legal pain for m2eclipse because of eclipse's ip review policy, so i can see why Jason would want as much of the code m2eclipse depends on at eclipse. in any case, let's wait +1 I want to at least see Aether in a stable location with some real bylaws and culture before I'll be okay with it. This was supposed to happen long ago, and as I remember it, that promise is a big part of why we adopted Aether... That, and this argument that we should give in to whatever demands are made by the People Who Are Getting Things Done Around Here. Now, we see that the pressure is off to follow up on these promises, as long as we keep agreeing to adopt versions developed without corresponding movement on the promises. I think we have to take some sort of stand, or this will not improve. Words are nice, but action is better. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 12:47, Benson Marguliesbimargul...@gmail.com wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - 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: [DISCUSS] incorporate EPL Aether
The board will not look fondly on Maven switching to a fork hosted at Apache Extras. However, I'm not sure what they would think about a github fork since sonatype-aether is hosted there and that is precisely what github promotes. Ralph On Jul 30, 2011, at 9:50 AM, Mark Struberg wrote: The 'funny' thing is that I always hear the ranting about how complicated the code handling at Apache. But then: it took them way over 2 years to get m2eclipse cleared in Eclipse! So their arguments against the ASF are just moot. It looks like it's nothing more than a personal problem. If we have no ability to fix bugs in that stuff, then we gonna kick it out sooner or later. I'll dig into the problems we have in our CI atm, and if it turns out to be another aether bug, then I'll start a fork over to apache-extras where every Maven committer can participate if he likes. Of course, the doors are not closed, but we are currently doomed to be completely depending on an external project which was a central part of maven-core short time ago. LieGrue, strub --- On Sat, 7/30/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 1:00 PM well it seems to me that we need to ensure that aether is not leaking into our public api. if it is entirely private from plugins, then i really don't care if it is epl or dual... dual would be nicer, and truer to the original plan whereby the code would be developed at github for speed, and then given back to maven. that plan changed, and now the code is (likely) ending up at eclipse... Jason has reasons for eclipse... that is just reality. personally i feel that it is another merit hurdle to have the code at eclipse, but then having maven at apache is a legal pain for m2eclipse because of eclipse's ip review policy, so i can see why Jason would want as much of the code m2eclipse depends on at eclipse. in any case, let's wait - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 12:47, Benson Margulies bimargul...@gmail.com wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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
Can we create our own, new API that plugins should use for this? Eventually all of Maven could use that instead of Aether directly. Ralph On Jul 30, 2011, at 10:25 AM, John Casey wrote: On 7/30/11 9:00 AM, Stephen Connolly wrote: well it seems to me that we need to ensure that aether is not leaking into our public api. if it is entirely private from plugins, then i really don't care if it is epl or dual... I agree completely. But, how can we keep it from leaking into plugins, when it's using the same plexus component system as the rest of Maven? This has long been a problem inside Maven, namely that we can't control _which_ components plugin devs have access to, and therefore we have an extremely difficult time deprecating/removing old components or reworking the internal design. Maybe firewalling and restricting the list of core components available to plugin devs is what we really need to address in order to address this concern. dual would be nicer, and truer to the original plan whereby the code would be developed at github for speed, and then given back to maven. that plan changed, and now the code is (likely) ending up at eclipse... Jason has reasons for eclipse... that is just reality. personally i feel that it is another merit hurdle to have the code at eclipse, but then having maven at apache is a legal pain for m2eclipse because of eclipse's ip review policy, so i can see why Jason would want as much of the code m2eclipse depends on at eclipse. in any case, let's wait +1 I want to at least see Aether in a stable location with some real bylaws and culture before I'll be okay with it. This was supposed to happen long ago, and as I remember it, that promise is a big part of why we adopted Aether... That, and this argument that we should give in to whatever demands are made by the People Who Are Getting Things Done Around Here. Now, we see that the pressure is off to follow up on these promises, as long as we keep agreeing to adopt versions developed without corresponding movement on the promises. I think we have to take some sort of stand, or this will not improve. Words are nice, but action is better. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 12:47, Benson Marguliesbimargul...@gmail.com wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - 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 - 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 also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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
1. are you seriously telling me that if acme corp were to fork aether, and do a shed-load of work on it, resulting in a far better aether than the eclipse hosted one and it was still epl licensed, that the board would view that as a breach of policy? if the answer is yes, then this is a sad sad world we live in. 2. i cannot speak for anyone else, but i am concerned that core maven functionality is being moved behind another merit wall... if i want to fix a bug in core, my gut tells me 8 times out of 10 i will need to hit aether... having to cross a merit wall to do so is nuts... the whole point of aether being developed at github was to remove a merit wall... but then Jason decided to move aether to eclipse, and the sonatype cla discouraged collaboration, and we are where we are. there may be others who object because they feel Jason is pushing our hand, and stealing another OSS project to eclipse... but i am not obey of them. i am a merit wall objector. the only merit to work on a project is the work you are doing right now... Jenkins and github teach us that... eclipse is a higher merit wall than apache, and that is my gripe with eclipse i have a similar gripe with apache, but it is less if an issue for me as i am inside the wall! - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 18:32, David Jencks david_jen...@yahoo.com wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
Dennis Lundberg wrote: Hi Does MSITE-600 also affect maven-site-plugin version 3? If so, can you please update that JIRA to also have the appropriate 3.0 version as Affects version. I suppose it will affect 3.0 as well, the code is the same. However, it was suggested to release 3.0 in a form as similar as possible to 2.3, for a point of comparison. I have started to investigate MSITE-600 and think I know how to fix it (the culprit is DefaultSiteTool.getRelativePath in doxia-integration-tools), but I will be on vacation now for two weeks (and hopefully stay away from my notebook...), so unless someone beats me to it, I will try to get it fixed ASAP when I'm back. As I said before, I prefer to have 3.0 released now with a series of bug fix releases afterwards. Cheers, -Lukas On 2011-07-30 17:32, Benson Margulies wrote: I'm not binding, but I'm sad about MSITE-600, which blocks my adoption at the day job. So +0 not that it matters. On Sat, Jul 30, 2011 at 11:03 AM, Dennis Lundbergdenn...@apache.org wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - 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
Stephen, The problem we have here is that, under point (2), the horse has already left the barn. Or, at least, we'd need to re-evolve from Hyracotherium (Maven 2.2) back to Equus to really get rid of this problem. Maybe the move to Eclipse will result in a more open and equitable process of establishing merit for those components. That's the hope. The PMC could have chosen to require a grant as a condition of incorporating any version of AEther into Maven, and it didn't. That's the history. At this point, who said or promised what to whom at that point doesn't matter. Commits were made that caused Maven to depend on code outside of Apache. What's now clear is that this was a one-way street, *whatever the license on the code*, due to the policy requirement for voluntary contributions. Under point (1), well, it's clear that the board would take a dim view if a group of people indistinguishable from the Maven PMC were to undertake what I labelled as (b). I'm not sure what they'd think of some other variations with the same effect. Mostly, the tone of the remarks is that the Maven community comes across to them as a bunch of whiny children. This may or may not be a fair characterization. In my limited experience of reading board@, the board tends to adopt this tone until someone shows them a really good reason not to. A manager of mine long ago used to claim that one of the jobs of an executive was to impose a tax on people who used their time, to incent those people to solve problems for themselves. The board's harsh tone looks to me like a message along those lines. Now, some people have found the AEther merit wall impenetrable, and some haven't. The board is looking for the PMC to make a serious, adult, attempt to work this out with the legal owner of the code before they hear about deviations from policy or end-arounds. Trading more or less insulting public emails with Jason does not qualify under that rubric, in my opinion. The PMC could make an effort to engage Sonatype more formally either now, or after a move to Eclipse, in an effort to work out a tolerable solution to the 'merit barrier' problem. If such an effort fails, then it would make sense to approach the board and ask for help and advice. Me, if I had a vote, I'd vote for now, in an effort to avoid stalling useful bug fixes any longer than necessary. As for the 'leaking API' problem, anyone who felt strongly enough could start typing a set of shims in org.apache.maven that are a simple pass-through to AEther. Plugins could call it, and in the (unlikely) event that someone ever pulls up their socks and does AEther all over again, it can drop in. In my very personal opinion, a change back to a dual-license tomorrow would make only a symbolic difference. It would not suddenly enable a fork-back, and it would not change the merit barrier. So my view is that efforts should focus on the real issue, which is the ability a more or less cohesive Maven community to maintain Maven, and not to a fight about the licenses. --benson On Sat, Jul 30, 2011 at 2:12 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 1. are you seriously telling me that if acme corp were to fork aether, and do a shed-load of work on it, resulting in a far better aether than the eclipse hosted one and it was still epl licensed, that the board would view that as a breach of policy? if the answer is yes, then this is a sad sad world we live in. 2. i cannot speak for anyone else, but i am concerned that core maven functionality is being moved behind another merit wall... if i want to fix a bug in core, my gut tells me 8 times out of 10 i will need to hit aether... having to cross a merit wall to do so is nuts... the whole point of aether being developed at github was to remove a merit wall... but then Jason decided to move aether to eclipse, and the sonatype cla discouraged collaboration, and we are where we are. there may be others who object because they feel Jason is pushing our hand, and stealing another OSS project to eclipse... but i am not obey of them. i am a merit wall objector. the only merit to work on a project is the work you are doing right now... Jenkins and github teach us that... eclipse is a higher merit wall than apache, and that is my gripe with eclipse i have a similar gripe with apache, but it is less if an issue for me as i am inside the wall! - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 18:32, David Jencks david_jen...@yahoo.com wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual
Re: [DISCUSS] incorporate EPL Aether
The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary. We'd have to figure out how to stitch those changes together, but from the guidance I got I don't believe this would be prohibited by the board. Without the dual licensing it would be much harder to create these sort of enhancements as the original class could only be used in binary form. I don't believe anyone is concerned with Aether becoming unusable for Maven. My understanding of the concern is that interaction with the repository(ies) and artifact resolution are areas that people still feel has lots of room for improvement and don't want to go to a different community to do it. The idea that one has to go outside of the Maven project to make changes to part of what many to be a core function is what is of concern. Ralph On Jul 30, 2011, at 10:31 AM, David Jencks wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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] SCM child-project URL composition
On Sat, Jul 30, 2011 at 1:07 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I am aware the Maven never does schema checking but that it complains when processing the pom when it sees things that aren't part of the model. So if IIUC you are just taking advantage of a place that Maven isn't rigorous in its validation. That would be fine. Ralph, sorry to have assumed that you knew less, rather than more, than I did. We're now on the same page in any case. --benson Ralph On Jul 30, 2011, at 4:29 AM, Benson Margulies wrote: I think that your understanding is oversimplified, with all due respect. Yes, there is an xml schema emitted by modello. However, no, no version of maven checks poms against a schema. So, it is possible to make changes to the pom that are compatible with Maven 2, by the expedient of testing that they are, in fact, compatible. In particular Maven 2 pays no attention to attributes on url/ elements. So adding them can't break it. Now, anyone who adds the attributes has to use a new enough maven-release-plugin to get the benefit of them. On Sat, Jul 30, 2011 at 4:55 AM, Ralph Goers ralph.go...@dslextreme.com wrote: i think I'm missing something. My understanding has been that any file named pom.xml that isn't compliant with 4.0.0 is going to break Maven 2 users. Am I misunderstanding something about what is being proposed? Ralph On Jul 29, 2011, at 8:04 AM, Benson Margulies wrote: I think Herve said so. On Jul 29, 2011, at 10:50 AM, John Casey jdca...@commonjava.org wrote: On 7/29/11 7:45 AM, Benson Margulies wrote: thereof? Does anyone hate it? I'm just a bit behind on mail, but need a clarification - in Maven the XSD is an end result of the model that is generated, but you seem to describe it here as an input. Am I misreading? I've been assuming that the XSD file is a manual production, but I didn't actually check. I guess that modello might be in the business of excreting XSD files, too. So my more recent email is a bit wrong. Yes, Modello is used to generate the XSD. So the next question that comes up is: can we generate an XSD like you describe using Modello? If we can, I think this is a pretty decent plan, actually...the best of limited options, IMO. If we get the alternative format work done later, then we escape the need to live with the format forever too. So, the danger that we're adding to our ball of tape and chewing gum is limited by that. If you're suggesting a change to the model that is backwards compat API-wise with 4.0.0, and has identical behaviour (or graceful degradation) when read from the repository by= 3.0.3, then I don't see any problem with a particular change. Yes, that's precisely the idea. Some new accessors appear in the model, and if you don't bother them, they won't bother you. - Brett -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Chair - 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 - 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 - 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, from the responses given to my question I'm sure the board would not look fondly on a fork at github either. On Jul 30, 2011, at 10:28 AM, Ralph Goers wrote: The board will not look fondly on Maven switching to a fork hosted at Apache Extras. However, I'm not sure what they would think about a github fork since sonatype-aether is hosted there and that is precisely what github promotes. Ralph On Jul 30, 2011, at 9:50 AM, Mark Struberg wrote: The 'funny' thing is that I always hear the ranting about how complicated the code handling at Apache. But then: it took them way over 2 years to get m2eclipse cleared in Eclipse! So their arguments against the ASF are just moot. It looks like it's nothing more than a personal problem. If we have no ability to fix bugs in that stuff, then we gonna kick it out sooner or later. I'll dig into the problems we have in our CI atm, and if it turns out to be another aether bug, then I'll start a fork over to apache-extras where every Maven committer can participate if he likes. Of course, the doors are not closed, but we are currently doomed to be completely depending on an external project which was a central part of maven-core short time ago. LieGrue, strub --- On Sat, 7/30/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 1:00 PM well it seems to me that we need to ensure that aether is not leaking into our public api. if it is entirely private from plugins, then i really don't care if it is epl or dual... dual would be nicer, and truer to the original plan whereby the code would be developed at github for speed, and then given back to maven. that plan changed, and now the code is (likely) ending up at eclipse... Jason has reasons for eclipse... that is just reality. personally i feel that it is another merit hurdle to have the code at eclipse, but then having maven at apache is a legal pain for m2eclipse because of eclipse's ip review policy, so i can see why Jason would want as much of the code m2eclipse depends on at eclipse. in any case, let's wait - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 12:47, Benson Margulies bimargul...@gmail.com wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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
On Sat, Jul 30, 2011 at 2:52 PM, Ralph Goers ralph.go...@dslextreme.com wrote: The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary. Ralph, I'd like to really understand this, so I'm going to waste everyone' eyeballs on being picky. Assume that AEther started out as a substantive, working, code base inside Apache, and then, subsequently, it had forked out. I see how your procedure works in that case, since either fork could cherry-pick from the other. What I don't follow is how it helps given the facts on the ground. There is no code base inside Apache that is close enough to AEther to absorb patches, and there never will be, unless Sonatype grants it. So I don't understand the logic whereby a return to a dual license helps us, unless it also comes with an SGA. What am I missing? We'd have to figure out how to stitch those changes together, but from the guidance I got I don't believe this would be prohibited by the board. Without the dual licensing it would be much harder to create these sort of enhancements as the original class could only be used in binary form. I don't believe anyone is concerned with Aether becoming unusable for Maven. My understanding of the concern is that interaction with the repository(ies) and artifact resolution are areas that people still feel has lots of room for improvement and don't want to go to a different community to do it. The idea that one has to go outside of the Maven project to make changes to part of what many to be a core function is what is of concern. Ralph On Jul 30, 2011, at 10:31 AM, David Jencks wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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:
Re: [DISCUSS] incorporate EPL Aether
On Sat, Jul 30, 2011 at 2:55 PM, Ralph Goers ralph.go...@dslextreme.com wrote: Actually, from the responses given to my question I'm sure the board would not look fondly on a fork at github either. The board members' position in those emails is very critical of any fork as the next step. What the board would say if a sincere attempt to solve the merit problem failed, or if a 'rogue element' performed a fork and made a release available, is hard to say, since the board also hates hypothetical question with the power of 1000 suns. On Jul 30, 2011, at 10:28 AM, Ralph Goers wrote: The board will not look fondly on Maven switching to a fork hosted at Apache Extras. However, I'm not sure what they would think about a github fork since sonatype-aether is hosted there and that is precisely what github promotes. Ralph On Jul 30, 2011, at 9:50 AM, Mark Struberg wrote: The 'funny' thing is that I always hear the ranting about how complicated the code handling at Apache. But then: it took them way over 2 years to get m2eclipse cleared in Eclipse! So their arguments against the ASF are just moot. It looks like it's nothing more than a personal problem. If we have no ability to fix bugs in that stuff, then we gonna kick it out sooner or later. I'll dig into the problems we have in our CI atm, and if it turns out to be another aether bug, then I'll start a fork over to apache-extras where every Maven committer can participate if he likes. Of course, the doors are not closed, but we are currently doomed to be completely depending on an external project which was a central part of maven-core short time ago. LieGrue, strub --- On Sat, 7/30/11, Stephen Connolly stephen.alan.conno...@gmail.com wrote: From: Stephen Connolly stephen.alan.conno...@gmail.com Subject: Re: [DISCUSS] incorporate EPL Aether To: Maven Developers List dev@maven.apache.org Date: Saturday, July 30, 2011, 1:00 PM well it seems to me that we need to ensure that aether is not leaking into our public api. if it is entirely private from plugins, then i really don't care if it is epl or dual... dual would be nicer, and truer to the original plan whereby the code would be developed at github for speed, and then given back to maven. that plan changed, and now the code is (likely) ending up at eclipse... Jason has reasons for eclipse... that is just reality. personally i feel that it is another merit hurdle to have the code at eclipse, but then having maven at apache is a legal pain for m2eclipse because of eclipse's ip review policy, so i can see why Jason would want as much of the code m2eclipse depends on at eclipse. in any case, let's wait - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 12:47, Benson Margulies bimargul...@gmail.com wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought. - 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: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
Guys, I don't know if it effects 3.0. It's a circular problem for me: you've told me that 3.0-beta-3 isn't good enough even to publish internal maven project sites, so I haven't been testing maven 3 on my day-job code. All I've been praying for is a 2.4 that's compatible with 2.2. But nothing really awful will happen if there isn't one. How about the following: I stop complaining, and then I'll undertake to aggressively test post-3.0 snapshots on my work code if you'll try to make a post 3.0-release in the not too distant future that mops up MSITE-600 and anything else reasonable that turns up? In the mean time, I'll leave my day-job code on 2.2. --benson On Sat, Jul 30, 2011 at 2:12 PM, Lukas Theussl ltheu...@apache.org wrote: Dennis Lundberg wrote: Hi Does MSITE-600 also affect maven-site-plugin version 3? If so, can you please update that JIRA to also have the appropriate 3.0 version as Affects version. I suppose it will affect 3.0 as well, the code is the same. However, it was suggested to release 3.0 in a form as similar as possible to 2.3, for a point of comparison. I have started to investigate MSITE-600 and think I know how to fix it (the culprit is DefaultSiteTool.getRelativePath in doxia-integration-tools), but I will be on vacation now for two weeks (and hopefully stay away from my notebook...), so unless someone beats me to it, I will try to get it fixed ASAP when I'm back. As I said before, I prefer to have 3.0 released now with a series of bug fix releases afterwards. Cheers, -Lukas On 2011-07-30 17:32, Benson Margulies wrote: I'm not binding, but I'm sad about MSITE-600, which blocks my adoption at the day job. So +0 not that it matters. On Sat, Jul 30, 2011 at 11:03 AM, Dennis Lundbergdenn...@apache.org wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146styleName=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11146status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - 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
On Jul 30, 2011, at 11:58 AM, Benson Margulies wrote: On Sat, Jul 30, 2011 at 2:52 PM, Ralph Goers ralph.go...@dslextreme.com wrote: The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary. Ralph, I'd like to really understand this, so I'm going to waste everyone' eyeballs on being picky. Assume that AEther started out as a substantive, working, code base inside Apache, and then, subsequently, it had forked out. I see how your procedure works in that case, since either fork could cherry-pick from the other. What I don't follow is how it helps given the facts on the ground. There is no code base inside Apache that is close enough to AEther to absorb patches, and there never will be, unless Sonatype grants it. So I don't understand the logic whereby a return to a dual license helps us, unless it also comes with an SGA. What am I missing? Let's say you want to change how a class in Aether works. You can take the class from either in modify it if it is under the Apache license. You can then place it somewhere in Maven. After that, it is a matter of figuring out how to wire the modified class so it is used instead of the original. Under the EPL we would have to write a new class from scratch. Just so you know, my vacation is coming to an end and I will be on airplanes sporadically today so if you have other questions you'll have to be patient. 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
Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly wrote: 1. are you seriously telling me that if acme corp were to fork aether, and do a shed-load of work on it, resulting in a far better aether than the eclipse hosted one and it was still epl licensed, that the board would view that as a breach of policy? if the answer is yes, then this is a sad sad world we live in. 2. i cannot speak for anyone else, but i am concerned that core maven functionality is being moved behind another merit wall... if i want to fix a bug in core, my gut tells me 8 times out of 10 i will need to hit aether... having to cross a merit wall to do so is nuts... the whole point of aether being developed at github was to remove a merit wall... but then Jason decided to move aether to eclipse, and the sonatype cla discouraged collaboration, and we are where we are. there may be others who object because they feel Jason is pushing our hand, and stealing another OSS project to eclipse... but i am not obey of them. i am a merit wall objector. the only merit to work on a project is the work you are doing right now... Jenkins and github teach us that... eclipse is a higher merit wall than apache, and that is my gripe with eclipse i have a similar gripe with apache, but it is less if an issue for me as i am inside the wall! - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 18:32, David Jencks david_jen...@yahoo.com wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over
Re: [DISCUSS] incorporate EPL Aether
lø., 30.07.2011 kl. 14.51 -0400, skrev Benson Margulies: Commits were made that caused Maven to depend on code outside of Apache. What's now clear is that this was a one-way street, *whatever the license on the code*, due to the policy requirement for voluntary contributions. Technically I am unsure if this statement is true. At the time aether was extracted, maven3 was more or less functionally complete. Most of what has happened since then was bug-fixes. All this is slightly hypothetical, but we may be able to revert from r988749 (introduction of aether) and re-work from there. The integration test suite would pretty much tell if it's being done correctly. Do not underestimate the quality of those ITs. The code-bases are sufficiently similar that selectively re-implementing specific bugfixes is an option. Now why on earth would we do all that? Can someone please point to me to the *written* statement from the board that says we can't a) fork to apache-extras or B) fork the last asl version to maven-extras on github (together with plexus and sisu ?) I'm tired of all this word-of mouth crap I seem to be getting from management upstairs; and that includes all you ASF members. 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
On Jul 30, 2011, at 2:52 PM, Ralph Goers wrote: The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary. Makes no difference. You could fork it at Github makes changes, deploy a binary and consume it. How are you stopped from doing anything with the code? Including actually contributing to the project at Eclipse? The only difference you site is being within ASF SVN or not. Nothing stops you from forking the code and modifying it. The changes would be in a public repository and thus you would satisfy the requirements of the EPL for contributing back. We'd have to figure out how to stitch those changes together, but from the guidance I got I don't believe this would be prohibited by the board. Without the dual licensing it would be much harder to create these sort of enhancements as the original class could only be used in binary form. I don't believe anyone is concerned with Aether becoming unusable for Maven. My understanding of the concern is that interaction with the repository(ies) and artifact resolution are areas that people still feel has lots of room for improvement and don't want to go to a different community to do it. The idea that one has to go outside of the Maven project to make changes to part of what many to be a core function is what is of concern. This is a theoretical concern because everyone seems to have found every reason in the book not to help with the artifact resolution code for the last how many years? Additionally, close to 100% of what anyone here in the Maven project would be concerned with is in Maven SVN. The maven-aether-provider is where it all happens, the rest of Aether has zero dependencies on Maven and doesn't know what Maven is. So in practical terms you'd probably never need anything in the Aether codebase but if you happened not a soul can cite a single instance where Benjamin has not answered someone almost instantaneously about any concerns or problems they had with Aether. Ralph On Jul 30, 2011, at 10:31 AM, David Jencks wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to me that a plurality of people felt that EPL at Eclipse was tolerable. So that argues for sitting still for now. I offer only the observation that forking into apache-extras 'works' the same way today, or after the code appears in Eclipse. In other words, adopting what's out there today only makes choice (c) harder, it doesn't have any impact that I see on a, b, or d. However, a 'no' vote is a 'no' vote, so this is all just food for thought.
Re: [VOTE] Release Maven Site Plugin version 3.0 and Maven Reporting Exec version 1.0.1
nice plan the most important thing about 3.0 is that we shouldn't need to maintain 2 branches in parallel, which was a nightmare With 3.0 out and the only branch to maintain, no doubt we can continue to improve faster than previously Regards, Hervé Le samedi 30 juillet 2011, Benson Margulies a écrit : Guys, I don't know if it effects 3.0. It's a circular problem for me: you've told me that 3.0-beta-3 isn't good enough even to publish internal maven project sites, so I haven't been testing maven 3 on my day-job code. All I've been praying for is a 2.4 that's compatible with 2.2. But nothing really awful will happen if there isn't one. How about the following: I stop complaining, and then I'll undertake to aggressively test post-3.0 snapshots on my work code if you'll try to make a post 3.0-release in the not too distant future that mops up MSITE-600 and anything else reasonable that turns up? In the mean time, I'll leave my day-job code on 2.2. --benson On Sat, Jul 30, 2011 at 2:12 PM, Lukas Theussl ltheu...@apache.org wrote: Dennis Lundberg wrote: Hi Does MSITE-600 also affect maven-site-plugin version 3? If so, can you please update that JIRA to also have the appropriate 3.0 version as Affects version. I suppose it will affect 3.0 as well, the code is the same. However, it was suggested to release 3.0 in a form as similar as possible to 2.3, for a point of comparison. I have started to investigate MSITE-600 and think I know how to fix it (the culprit is DefaultSiteTool.getRelativePath in doxia-integration-tools), but I will be on vacation now for two weeks (and hopefully stay away from my notebook...), so unless someone beats me to it, I will try to get it fixed ASAP when I'm back. As I said before, I prefer to have 3.0 released now with a series of bug fix releases afterwards. Cheers, -Lukas On 2011-07-30 17:32, Benson Margulies wrote: I'm not binding, but I'm sad about MSITE-600, which blocks my adoption at the day job. So +0 not that it matters. On Sat, Jul 30, 2011 at 11:03 AM, Dennis Lundbergdenn...@apache.org wrote: Hi, We solved 46+1 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11146style Name=Htmlversion=16829 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761style Name=Htmlversion=17501 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=111 46status=1 Staging repos: https://repository.apache.org/content/repositories/maven-015/ https://repository.apache.org/content/repositories/maven-016/ Staging sites: http://maven.apache.org/plugins/maven-site-plugin-3.0/ http://maven.apache.org/shared/maven-reporting-exec-1.0.1/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Dennis Lundberg - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
Le samedi 30 juillet 2011, John Casey a écrit : But, how can we keep it from leaking into plugins, when it's using the same plexus component system as the rest of Maven? This has long been a problem inside Maven, namely that we can't control _which_ components plugin devs have access to, and therefore we have an extremely difficult time deprecating/removing old components or reworking the internal design. IIUC, this problem has been solved in M3 by DefaultClassRealmManager.java#importMavenApi: visibility changed from everything is available unless we hide it (with shade) in M2 to nothing is available unless we show it I don't know the impact of hiding aether, but hiding it should be easy Regards, Hervé - 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, legal-discuss is a public list, with public archives. You can go read these remarks for yourself in the archive. I apologize for assuming that you or anyone else didn't know that. Yes I am a member, but Ralph and I are not quoting any private crap. Note that some Ralph posed a relatively specific legal question to start with, and then it grew and grew into a more complex policy discussion that board members happened to participate in. If you want a clear statement of the board's view, you can ask the board. The board in general would, I bet, rather get a coherent question from the PMC chair in the monthly report, and deal with that, but nothing stops you from sending email to board@ stating your view of the question at hand and asking for clarification. I wasn't here for the technical deep history, I'm depending on what people have written lately, and as of your message (if not before) people have written what to me is a bewildering variety of contradictory things. If your copy of history is the accurate one, then it explains Ralph's views about dual licenses. In any case, Jason's invitation to all and sundry to have commit access on day one looks like an opportunity to lower the temperature on all this. I chose those words carefully, please no one accuse me of thinking that it's a guaranteed solution in a bottle. I think you've all read enough from me on this subject to last you a good long time, so I'm going to stop typing for the rest of the weekend at least. --benson On Sat, Jul 30, 2011 at 3:37 PM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: lø., 30.07.2011 kl. 14.51 -0400, skrev Benson Margulies: Commits were made that caused Maven to depend on code outside of Apache. What's now clear is that this was a one-way street, *whatever the license on the code*, due to the policy requirement for voluntary contributions. Technically I am unsure if this statement is true. At the time aether was extracted, maven3 was more or less functionally complete. Most of what has happened since then was bug-fixes. All this is slightly hypothetical, but we may be able to revert from r988749 (introduction of aether) and re-work from there. The integration test suite would pretty much tell if it's being done correctly. Do not underestimate the quality of those ITs. The code-bases are sufficiently similar that selectively re-implementing specific bugfixes is an option. Now why on earth would we do all that? Can someone please point to me to the *written* statement from the board that says we can't a) fork to apache-extras or B) fork the last asl version to maven-extras on github (together with plexus and sisu ?) I'm tired of all this word-of mouth crap I seem to be getting from management upstairs; and that includes all you ASF members. 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
Re: [DISCUSS] incorporate EPL Aether
See below. Sent from my iPhone On Jul 30, 2011, at 9:39 AM, Jason van Zyl ja...@sonatype.com wrote: On Jul 30, 2011, at 2:52 PM, Ralph Goers wrote: The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary. Makes no difference. You could fork it at Github makes changes, deploy a binary and consume it. We have been told by the VP of legal we cannot do this. How are you stopped from doing anything with the code? Including actually contributing to the project at Eclipse? We are not. My assumption has always been that what has been discussed is wrt something that Aether wouldn't accept - a purely hypothetical situation right now. The only difference you site is being within ASF SVN or not. Nothing stops you from forking the code and modifying it. Are you saying you would be willing to provide a software grant to allow us to do so? That would change the situation dramatically. The changes would be in a public repository and thus you would satisfy the requirements of the EPL for contributing back. We'd have to figure out how to stitch those changes together, but from the guidance I got I don't believe this would be prohibited by the board. Without the dual licensing it would be much harder to create these sort of enhancements as the original class could only be used in binary form. I don't believe anyone is concerned with Aether becoming unusable for Maven. My understanding of the concern is that interaction with the repository(ies) and artifact resolution are areas that people still feel has lots of room for improvement and don't want to go to a different community to do it. The idea that one has to go outside of the Maven project to make changes to part of what many to be a core function is what is of concern. This is a theoretical concern because everyone seems to have found every reason in the book not to help with the artifact resolution code for the last how many years? Additionally, close to 100% of what anyone here in the Maven project would be concerned with is in Maven SVN. The maven-aether-provider is where it all happens, the rest of Aether has zero dependencies on Maven and doesn't know what Maven is. So in practical terms you'd probably never need anything in the Aether codebase but if you happened not a soul can cite a single instance where Benjamin has not answered someone almost instantaneously about any concerns or problems they had with Aether. Ralph On Jul 30, 2011, at 10:31 AM, David Jencks wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by a number of senior ASF people (including a board member or two). So, the community has some choices. It seems to me that the viability of these different choices depends on the viability of walking away from AEther. In practical terms, the choices are: a) Use versions of AEther controlled by 'someone else'. b) Create our own 'someone else' at apache-extras or elsewhere. c) Go down the path of becoming an exception to the policy and take on reworking AEther from the last dual-licensed version. d) Start All Over Again from Maven 2.2. From the vote comments, it seemed to
Re: [DISCUSS] incorporate EPL Aether
Jason. please read my post carefully. i did not say you were a thief, i said there may be others who feel you are... i also said i do not agree with that point of view. i will gladly accept your offer to remove the merit wall. i am just interested in making the code easy to develop and fix, for the good of the users. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 20:26, Jason van Zyl ja...@sonatype.com wrote: Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly wrote: 1. are you seriously telling me that if acme corp were to fork aether, and do a shed-load of work on it, resulting in a far better aether than the eclipse hosted one and it was still epl licensed, that the board would view that as a breach of policy? if the answer is yes, then this is a sad sad world we live in. 2. i cannot speak for anyone else, but i am concerned that core maven functionality is being moved behind another merit wall... if i want to fix a bug in core, my gut tells me 8 times out of 10 i will need to hit aether... having to cross a merit wall to do so is nuts... the whole point of aether being developed at github was to remove a merit wall... but then Jason decided to move aether to eclipse, and the sonatype cla discouraged collaboration, and we are where we are. there may be others who object because they feel Jason is pushing our hand, and stealing another OSS project to eclipse... but i am not obey of them. i am a merit wall objector. the only merit to work on a project is the work you are doing right now... Jenkins and github teach us that... eclipse is a higher merit wall than apache, and that is my gripe with eclipse i have a similar gripe with apache, but it is less if an issue for me as i am inside the wall! - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 18:32, David Jencks david_jen...@yahoo.com wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this thread now, given the rather clear results of the vote thread. Ralph posed the following question on Legal Discuss: 'Can the Maven PMC pull a dual-licensed version of AEther back into Apache without a grant from Sonatype?' The answer was, legally yes, but it is counter to long-established policy, and strongly discouraged by
Re: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 4:16 PM, Ralph Goers wrote: See below. Sent from my iPhone On Jul 30, 2011, at 9:39 AM, Jason van Zyl ja...@sonatype.com wrote: On Jul 30, 2011, at 2:52 PM, Ralph Goers wrote: The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary. Makes no difference. You could fork it at Github makes changes, deploy a binary and consume it. We have been told by the VP of legal we cannot do this. It can't be for legal reasons. They are telling you that you don't have the right to take a codebase and fork it for which the license allows? For which Apache 3rd party policies states you can consume as a binary? I'm not saying you want to do this but I can't see how you're legally not entitled to do this. How are you stopped from doing anything with the code? Including actually contributing to the project at Eclipse? We are not. My assumption has always been that what has been discussed is wrt something that Aether wouldn't accept - a purely hypothetical situation right now. You probably couldn't care less what the main body of Aether does and there are extension points which allow you to do pretty much anything you want. The maven-aether-connector is a good example. The only difference you site is being within ASF SVN or not. Nothing stops you from forking the code and modifying it. Are you saying you would be willing to provide a software grant to allow us to do so? That would change the situation dramatically. No, I'm not saying that. I believe in the EPL and the function it serves. You don't have to agree with me but I ask you respect my choice. I don't think this adversely affects anything with respect to Maven. The same counter to the merit wall argument I'm willing to extend to anyone who wants it. If you wanted to be listed as a committer you can be. Would that make you feel more comfortable? Politics don't stand at Eclipse so there would be no way I could do anything to force you out of the project once you were part of it, if that concerned you. Mike would toss me out before he let me attempt to throw someone else out. Then if you chose to implement anything nothing would stop you. Additionally, I'm sure at some point in the future if you pointed at some harmful change in Aether the board would let you fork the project at Github and absorb the binary you produced. There is already precedent for absorbing EPL binaries so I can't see how that could legally be a problem. The changes would be in a public repository and thus you would satisfy the requirements of the EPL for contributing back. We'd have to figure out how to stitch those changes together, but from the guidance I got I don't believe this would be prohibited by the board. Without the dual licensing it would be much harder to create these sort of enhancements as the original class could only be used in binary form. I don't believe anyone is concerned with Aether becoming unusable for Maven. My understanding of the concern is that interaction with the repository(ies) and artifact resolution are areas that people still feel has lots of room for improvement and don't want to go to a different community to do it. The idea that one has to go outside of the Maven project to make changes to part of what many to be a core function is what is of concern. This is a theoretical concern because everyone seems to have found every reason in the book not to help with the artifact resolution code for the last how many years? Additionally, close to 100% of what anyone here in the Maven project would be concerned with is in Maven SVN. The maven-aether-provider is where it all happens, the rest of Aether has zero dependencies on Maven and doesn't know what Maven is. So in practical terms you'd probably never need anything in the Aether codebase but if you happened not a soul can cite a single instance where Benjamin has not answered someone almost instantaneously about any concerns or problems they had with Aether. Ralph On Jul 30, 2011, at 10:31 AM, David Jencks wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using
Re: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 4:29 PM, Stephen Connolly wrote: Jason. please read my post carefully. i did not say you were a thief, i said there may be others who feel you are... i also said i do not agree with that point of view. Sorry, I read it incorrectly. i will gladly accept your offer to remove the merit wall. Done. You will have seen the email to Wayne Beaton on the EMO. You should be listed there on Monday. i am just interested in making the code easy to develop and fix, for the good of the users. That's all I care about. I really do not believe being at Eclipse changes that. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 20:26, Jason van Zyl ja...@sonatype.com wrote: Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly wrote: 1. are you seriously telling me that if acme corp were to fork aether, and do a shed-load of work on it, resulting in a far better aether than the eclipse hosted one and it was still epl licensed, that the board would view that as a breach of policy? if the answer is yes, then this is a sad sad world we live in. 2. i cannot speak for anyone else, but i am concerned that core maven functionality is being moved behind another merit wall... if i want to fix a bug in core, my gut tells me 8 times out of 10 i will need to hit aether... having to cross a merit wall to do so is nuts... the whole point of aether being developed at github was to remove a merit wall... but then Jason decided to move aether to eclipse, and the sonatype cla discouraged collaboration, and we are where we are. there may be others who object because they feel Jason is pushing our hand, and stealing another OSS project to eclipse... but i am not obey of them. i am a merit wall objector. the only merit to work on a project is the work you are doing right now... Jenkins and github teach us that... eclipse is a higher merit wall than apache, and that is my gripe with eclipse i have a similar gripe with apache, but it is less if an issue for me as i am inside the wall! - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 18:32, David Jencks david_jen...@yahoo.com wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking behind the idea that sonatype will make aether unusable for maven (isn't this the basic concern over using aether?). I don't see this as a plausible scenario. thanks david jencks On Jul 30, 2011, at 10:14 AM, Ralph Goers wrote: The board made it pretty clear that option b is also highly discouraged so I wouldn't list that as an option. The only viable path I see will be to ultimately include the EPL version of Aether and then replace it with our own code when someone decides there is something they want to do that requires it. A dual licensed version of Aether would probably insure a complete replacement is never necessary. Ralph On Jul 30, 2011, at 4:46 AM, Benson Margulies wrote: I'd like to to try to put a little oxygen into this
Re: [DISCUSS] incorporate EPL Aether
Jason, please stick to the facts. Here is what I found after reading through the history in the private archives. 1.) the original artifact resolution mechanism was part of maven-core 2.) you wrote a new one which does certain things a bit better 3.) you told the Maven PMC that it will finally end up back in Maven. 4.) As a result of this promise work was done to replace the original maven owned code with your stuff. If the Maven PMC and the board would have known that aether would never made it over here, then they would NEVER EVER let any aether import hit the Maven SVN! NEVER! 5.) Aether got more and more complicated, and it doesn't have interfaces on the maven side not any other fixed set of SPI or API (imo a poor design decision). The result is that we now have aether imports like a kraken sitting in 30% of all maven-core classes. 6.) you switched your opinion and told the community that aether will not be part of maven. So one could argue that - from the effect - you stole the maven project a year of development or the ability to fix bugs themselfs. I don't say that you originally intended to do so in an intentional way. But that's what we have now! LieGrue, strub PS: Of course I know what you did for the project in the past, but that doesn't change that very topic. --- On Sat, 7/30/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: Saturday, July 30, 2011, 7:25 PM Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly wrote: 1. are you seriously telling me that if acme corp were to fork aether, and do a shed-load of work on it, resulting in a far better aether than the eclipse hosted one and it was still epl licensed, that the board would view that as a breach of policy? if the answer is yes, then this is a sad sad world we live in. 2. i cannot speak for anyone else, but i am concerned that core maven functionality is being moved behind another merit wall... if i want to fix a bug in core, my gut tells me 8 times out of 10 i will need to hit aether... having to cross a merit wall to do so is nuts... the whole point of aether being developed at github was to remove a merit wall... but then Jason decided to move aether to eclipse, and the sonatype cla discouraged collaboration, and we are where we are. there may be others who object because they feel Jason is pushing our hand, and stealing another OSS project to eclipse... but i am not obey of them. i am a merit wall objector. the only merit to work on a project is the work you are doing right now... Jenkins and github teach us that... eclipse is a higher merit wall than apache, and that is my gripe with eclipse i have a similar gripe with apache, but it is less if an issue for me as i am inside the wall! - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 18:32, David Jencks david_jen...@yahoo.com wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use it inconsistently with the owners wishes. I think we either use it as-is, or don't use it at all. I'm not sure I understand the thinking
Re: [DISCUSS] incorporate EPL Aether
Many things changed within the ASF which made me extremely uncomfortable, and everyone is entitled to change their opinions and their decisions. It's not as if everything remained immutable on the ASF side. Yes, I changed my mind and decided Eclipse was the place I would like to do the majority of my open source work. If politics, the ensuing strife and resulting frustration weren't present I would probably feel differently. But I don't believe we ever blocked anyone from contributing. On Jul 30, 2011, at 4:41 PM, Mark Struberg wrote: Jason, please stick to the facts. Here is what I found after reading through the history in the private archives. 1.) the original artifact resolution mechanism was part of maven-core 2.) you wrote a new one which does certain things a bit better 3.) you told the Maven PMC that it will finally end up back in Maven. 4.) As a result of this promise work was done to replace the original maven owned code with your stuff. If the Maven PMC and the board would have known that aether would never made it over here, then they would NEVER EVER let any aether import hit the Maven SVN! NEVER! 5.) Aether got more and more complicated, and it doesn't have interfaces on the maven side not any other fixed set of SPI or API (imo a poor design decision). The result is that we now have aether imports like a kraken sitting in 30% of all maven-core classes. 6.) you switched your opinion and told the community that aether will not be part of maven. So one could argue that - from the effect - you stole the maven project a year of development or the ability to fix bugs themselfs. I don't say that you originally intended to do so in an intentional way. But that's what we have now! LieGrue, strub PS: Of course I know what you did for the project in the past, but that doesn't change that very topic. --- On Sat, 7/30/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: Saturday, July 30, 2011, 7:25 PM Please don't call me a thief. If you're talking about Aether and Sisu and my decision to move those to Eclipse, they were never here and am responsible for funding the vast majority of the code written in those projects. As such do I not have the right to house those projects where I wish? At an organization with people who have some respect for the work I do? Where I'm not always getting attacked? Your last email a perfect case in point. As for your merit wall, if you wish to be listed as a committer on the Aether proposal I will list you as a committer. Merit wall removed. I doubt we are ever going to come to any agreement. I believe I am in the right, you believe you are in the right. It doesn't really matter at this point. Do you really find it that hard to comprehend given what's happened that I'm not overly keen to keep pouring resources into the ASF? I still care about Maven users and always will, but that does not mandate projects that I work on be here. My passion and philosophy lie outside the ASF at this point. That doesn't mean we can't be civil. I don't believe accusing me of stealing another project away to Eclipse does much to move toward that. On Jul 30, 2011, at 2:12 PM, Stephen Connolly wrote: 1. are you seriously telling me that if acme corp were to fork aether, and do a shed-load of work on it, resulting in a far better aether than the eclipse hosted one and it was still epl licensed, that the board would view that as a breach of policy? if the answer is yes, then this is a sad sad world we live in. 2. i cannot speak for anyone else, but i am concerned that core maven functionality is being moved behind another merit wall... if i want to fix a bug in core, my gut tells me 8 times out of 10 i will need to hit aether... having to cross a merit wall to do so is nuts... the whole point of aether being developed at github was to remove a merit wall... but then Jason decided to move aether to eclipse, and the sonatype cla discouraged collaboration, and we are where we are. there may be others who object because they feel Jason is pushing our hand, and stealing another OSS project to eclipse... but i am not obey of them. i am a merit wall objector. the only merit to work on a project is the work you are doing right now... Jenkins and github teach us that... eclipse is a higher merit wall than apache, and that is my gripe with eclipse i have a similar gripe with apache, but it is less if an issue for me as i am inside the wall! - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 30 Jul 2011 18:32, David Jencks david_jen...@yahoo.com wrote: I also was just about to point out that the legal
Re: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 4:49 PM, Jason van Zyl wrote: Many things changed within the ASF which made me extremely uncomfortable, and everyone is entitled to change their opinions and their decisions. It's not as if everything remained immutable on the ASF side. Yes, I changed my mind and decided Eclipse was the place I would like to do the majority of my open source work. If politics, the ensuing strife and resulting frustration weren't present I would probably feel differently. But I don't believe we ever blocked anyone from contributing. On Jul 30, 2011, at 4:41 PM, Mark Struberg wrote: 5.) Aether got more and more complicated, and it doesn't have interfaces on the maven side not any other fixed set of SPI or API (imo a poor design decision). The result is that we now have aether imports like a kraken sitting in 30% of all maven-core classes. This one is just inaccurate. The interfaces on the Maven side are close to 100% backward compatibility with the existing APIs. We broke almost nothing and that was a lot of work. You need zero Aether imports to do anything in plugins with respect to artifact resolution. You can use them if you like but you don't have to. But's it not like we changed all the external APIs. I believe the vast majority of the Aether imports are in the compatibility layer. 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: [DISCUSS] incorporate EPL Aether
See below Sent from my iPhone On Jul 30, 2011, at 10:33 AM, Jason van Zyl ja...@sonatype.com wrote: On Jul 30, 2011, at 4:16 PM, Ralph Goers wrote: See below. Sent from my iPhone On Jul 30, 2011, at 9:39 AM, Jason van Zyl ja...@sonatype.com wrote: On Jul 30, 2011, at 2:52 PM, Ralph Goers wrote: The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary. Makes no difference. You could fork it at Github makes changes, deploy a binary and consume it. We have been told by the VP of legal we cannot do this. It can't be for legal reasons. They are telling you that you don't have the right to take a codebase and fork it for which the license allows? For which Apache 3rd party policies states you can consume as a binary? I'm not saying you want to do this but I can't see how you're legally not entitled to do this. It is not for legal reasons. The policy is that we cannot fork software whose copyright owners do not wish us to do so. How are you stopped from doing anything with the code? Including actually contributing to the project at Eclipse? We are not. My assumption has always been that what has been discussed is wrt something that Aether wouldn't accept - a purely hypothetical situation right now. You probably couldn't care less what the main body of Aether does and there are extension points which allow you to do pretty much anything you want. The maven-aether-connector is a good example. The only difference you site is being within ASF SVN or not. Nothing stops you from forking the code and modifying it. Are you saying you would be willing to provide a software grant to allow us to do so? That would change the situation dramatically. No, I'm not saying that. I believe in the EPL and the function it serves. You don't have to agree with me but I ask you respect my choice. I don't think this adversely affects anything with respect to Maven. The same counter to the merit wall argument I'm willing to extend to anyone who wants it. If you wanted to be listed as a committer you can be. Would that make you feel more comfortable? Politics don't stand at Eclipse so there would be no way I could do anything to force you out of the project once you were part of it, if that concerned you. Mike would toss me out before he let me attempt to throw someone else out. Then if you chose to implement anything nothing would stop you. Additionally, I'm sure at some point in the future if you pointed at some harmful change in Aether the board would let you fork the project at Github and absorb the binary you produced. There is already precedent for absorbing EPL binaries so I can't see how that could legally be a problem. The changes would be in a public repository and thus you would satisfy the requirements of the EPL for contributing back. We'd have to figure out how to stitch those changes together, but from the guidance I got I don't believe this would be prohibited by the board. Without the dual licensing it would be much harder to create these sort of enhancements as the original class could only be used in binary form. I don't believe anyone is concerned with Aether becoming unusable for Maven. My understanding of the concern is that interaction with the repository(ies) and artifact resolution are areas that people still feel has lots of room for improvement and don't want to go to a different community to do it. The idea that one has to go outside of the Maven project to make changes to part of what many to be a core function is what is of concern. This is a theoretical concern because everyone seems to have found every reason in the book not to help with the artifact resolution code for the last how many years? Additionally, close to 100% of what anyone here in the Maven project would be concerned with is in Maven SVN. The maven-aether-provider is where it all happens, the rest of Aether has zero dependencies on Maven and doesn't know what Maven is. So in practical terms you'd probably never need anything in the Aether codebase but if you happened not a soul can cite a single instance where Benjamin has not answered someone almost instantaneously about any concerns or problems they had with Aether. Ralph On Jul 30, 2011, at 10:31 AM, David Jencks wrote: I also was just about to point out that the legal discuss thread indicated that (b) and (c) are equivalent violations of apache policy. Since jason/sonatype doesn't want this code at apache, and the board doesn't want us forking it somewhere else to use it because jason/sonatype doesn't want the code at apache, I don't see why the dual licensing would make any difference. We still can't bring the code here or fork it anywhere else to use
Re: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 5:08 PM, Ralph Goers wrote: See below Sent from my iPhone On Jul 30, 2011, at 10:33 AM, Jason van Zyl ja...@sonatype.com wrote: On Jul 30, 2011, at 4:16 PM, Ralph Goers wrote: See below. Sent from my iPhone On Jul 30, 2011, at 9:39 AM, Jason van Zyl ja...@sonatype.com wrote: On Jul 30, 2011, at 2:52 PM, Ralph Goers wrote: The dual license makes a difference because if someone wants to make a change that Aether doesn't want it can easily be incorporated here since the original class could be taken and modified as necessary. Makes no difference. You could fork it at Github makes changes, deploy a binary and consume it. We have been told by the VP of legal we cannot do this. It can't be for legal reasons. They are telling you that you don't have the right to take a codebase and fork it for which the license allows? For which Apache 3rd party policies states you can consume as a binary? I'm not saying you want to do this but I can't see how you're legally not entitled to do this. It is not for legal reasons. The policy is that we cannot fork software whose copyright owners do not wish us to do so. So then you can't fork any version of Aether. So why are we continuing this discussion? Be a committer on Aether, you're then free to do what you like -- and anyone else for that matter -- and we can get on with releasing 3.0.4 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: [DISCUSS] incorporate EPL Aether
On Jul 30, 2011, at 5:14 PM, Jason van Zyl wrote: It is not for legal reasons. The policy is that we cannot fork software whose copyright owners do not wish us to do so. So then you can't fork any version of Aether. So why are we continuing this discussion? Be a committer on Aether, you're then free to do what you like -- and anyone else for that matter -- and we can get on with releasing 3.0.4 Also note that currently we have Eclipse committers among us. Myself, Igor, Benjamin, Milos, and Jesse. Herve, Kristian and Stephen will be as part of the Aether proposal. At one point Brett and Carlos were as well. Additionally Sonatype, Cloudbees (Stephen) and Intuit (yourself) are members at Eclipse. So it's not like it's a completely foreign land. 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 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: [DISCUSS] incorporate EPL Aether
This one is just inaccurate. The interfaces on the Maven side are close to 100% backward compatibility with the existing APIs. Hum, 323 aether imports for the maven-core module alone doesn't sound non-intrusive. Thats almost 15% of all imports (2930)! LieGrue, strub --- On Sat, 7/30/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: Saturday, July 30, 2011, 9:08 PM On Jul 30, 2011, at 4:49 PM, Jason van Zyl wrote: Many things changed within the ASF which made me extremely uncomfortable, and everyone is entitled to change their opinions and their decisions. It's not as if everything remained immutable on the ASF side. Yes, I changed my mind and decided Eclipse was the place I would like to do the majority of my open source work. If politics, the ensuing strife and resulting frustration weren't present I would probably feel differently. But I don't believe we ever blocked anyone from contributing. On Jul 30, 2011, at 4:41 PM, Mark Struberg wrote: 5.) Aether got more and more complicated, and it doesn't have interfaces on the maven side not any other fixed set of SPI or API (imo a poor design decision). The result is that we now have aether imports like a kraken sitting in 30% of all maven-core classes. This one is just inaccurate. The interfaces on the Maven side are close to 100% backward compatibility with the existing APIs. We broke almost nothing and that was a lot of work. You need zero Aether imports to do anything in plugins with respect to artifact resolution. You can use them if you like but you don't have to. But's it not like we changed all the external APIs. I believe the vast majority of the Aether imports are in the compatibility layer. 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] incorporate EPL Aether
That's fine, but who ensures us that you wont change your mind again? But fair enough, it will be much better at Eclipse than somewhere in the wild. LieGrue, strub --- On Sat, 7/30/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: Saturday, July 30, 2011, 9:32 PM On Jul 30, 2011, at 5:14 PM, Jason van Zyl wrote: It is not for legal reasons. The policy is that we cannot fork software whose copyright owners do not wish us to do so. So then you can't fork any version of Aether. So why are we continuing this discussion? Be a committer on Aether, you're then free to do what you like -- and anyone else for that matter -- and we can get on with releasing 3.0.4 Also note that currently we have Eclipse committers among us. Myself, Igor, Benjamin, Milos, and Jesse. Herve, Kristian and Stephen will be as part of the Aether proposal. At one point Brett and Carlos were as well. Additionally Sonatype, Cloudbees (Stephen) and Intuit (yourself) are members at Eclipse. So it's not like it's a completely foreign land. 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 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 - 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 would suggest you re-read Brett's last email as to why we continue to have this discussion. He seems to be able to word things a bit better than me. Sent from my iPhone On Jul 30, 2011, at 11:14 AM, Jason van Zyl ja...@sonatype.com wrote: So then you can't fork any version of Aether. So why are we continuing this discussion? Be a committer on Aether, you're then free to do what you like -- and anyone else for that matter -- and we can get on with releasing 3.0.4 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Incorporate EPL Ether in Maven Releases
Ok, I'll pick up from Ralph's discussion. On Jul 29, 2011, at 1:16 PM, Brett Porter wrote: -0 I don't like it, but I'm not the one doing the work. I'd accept it if there's no better way to get the problems fixed for whoever is working to fix them. I don't think it's good to get stuck on an old version no one is maintaining. I'm happy to discuss ideas for alternatives. However, I would strongly prefer it to remain dual licensed: - it gives us more options if we need to incorporate source code changes that aren't accepted upstream, particularly if goals change over time If you can't fork any version of Aether per ASF board guidelines/mandate (I'm only repeating what Ralph said) then what does it matter? And let's say this is not the case, worst case you fork it at Github, make your changes and create a binary. This doesn't hinder you from doing anything if the board changed it's mind on this policy. My preference would certainly be not to fork it but the license affords you that right. The chances that upstream requests for change are not accepted are close to zero, especially with a bunch of committers here on Aether. This is virtually no different than Plexus and Modello. Kristian made the last set of changes on a Plexus project and released them. I don't know when the last release of Modello happened but I think that was Hervé. - consumers know what they are getting from Maven - it can all be used under the terms of the AL 2.0. There's precedent for redistributing EPL at the ASF, and the EPL is commercially friendly. Millions of people use Eclipse, extend Eclipse so I really don't think users have a problem with the EPL. - it had the terms of the AL 2.0 when we agreed to incorporate it As I said to Mark things here have changed I prefer in the EPL and what it affords. If I have a choice of organization it's the Eclipse Foundation and the preference is not to dual license. We may not agree about foundations or licenses but our commonality is Maven users. If you believe you can serve them better by forking the code and not joining the Aether project then that's your prerogative. I can't honestly see how that would be, but you're free to do what you like. I can't see what danger Maven would ever be in with Aether being at Eclipse and EPL. Even less if people here chose to be committers on the project. The current count is 6 people here being committers on Aether. The more people from here over there the more likely your requests for change will be incorporated. I continue to hope that will be reconsidered. FWIW, I don't have any argument with regard to the EPL as a license, I just believe AL 2.0 is appropriate here given its history, the early state of community development, and with Maven as its primary consumer. - Brett On 28/07/2011, at 4:45 AM, Benson Margulies wrote: As per the approved policy, this message opens a vote to allow Maven releases to depend on EPL (and thus Category B) versions of Aether. The vote will be open for 72 hours and the results determined according to the policy. Discussion on this question took place on a thread labelled '[DISCUSS] incorporate EPL Aether'. - 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 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
Pluggable Dependency Resolution
Hi all, I wanted to start this discussion completely separate from any of the other, rather heated ASL vs EPL discussions around Aether to try and keep this more on topic. For awhile we ( members of the Illegal Argument podcast ) have often discussed a desire to have a pluggable dependency resolution mechanism within Apache Maven, mostly around having the ability to force maven to use the lowest bound in a range rather than the highest for highlight fast-fail API breakages. With the rise of these ASF/EPL threads I again thought of the pluggable resolution idea. For those with more of a code-centric knowledge of the workings of Apache Maven, is it possible/feasible/semi-cleanly-codeable to have an install, or even project level selection of resolution of artifacts. I imagine a difficulty in that this would have to occur early in the bootstrap process of maven, but if this were the case, would we not be able to work a solution to not only the Aether inclusion issues, but also Kasun's Gentoo resolution issues. This allows the end-user of Apache Maven (in the case that they care about it) the ability to update artifact resolution code independent of maven itself, or use a hardened/locked down resolution scheme backed by portage - and portage only. Apache Maven could stick with (for now) using Aether 1.11, the last dual licensed release out of the box, where as the Gentoo ebuild could configure maven to use its own ( an idea I see as flawed personally ) and those who wish to use Aether, or a custom resolution strategy could do so. Thoughts? Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
On 31/07/2011, at 11:14 AM, Mark Derricutt wrote: I imagine a difficulty in that this would have to occur early in the bootstrap process of maven, but if this were the case, would we not be able to work a solution to not only the Aether inclusion issues, but also Kasun's Gentoo resolution issues. Replying to my own post ;-) I was just having the thought that doing something like moving the toolchains-plugin into core, and making use of this as a means to choose your dependency resolution. If we combined this idea with the discussion of a new version of the POM, we could introduce a new toolchains/ element inside of build/ whilst preserving backwards compatibility of declaring the toolchain plugin maybe? The superpom could declare a dependency toolchain/ for the system default/standard resolution. And any users who want something custom would need to define it both in their pom, and there ~/.m2/toolchains.xml file - viable? Mark - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Pluggable Dependency Resolution
On Jul 30, 2011, at 7:14 PM, Mark Derricutt wrote: Hi all, I wanted to start this discussion completely separate from any of the other, rather heated ASL vs EPL discussions around Aether to try and keep this more on topic. For awhile we ( members of the Illegal Argument podcast ) have often discussed a desire to have a pluggable dependency resolution mechanism within Apache Maven, mostly around having the ability to force maven to use the lowest bound in a range rather than the highest for highlight fast-fail API breakages. I think the potential for wreaking havoc would be too high. If it's something that is thought to be generally beneficial we should add it. But how would you stop everyone and their brother from thinking they had a better scheme? They all deploys those schemes and then Maven has to deal with potentially incompatible schemes and the default behaviour becoming meaningless. This is why OSGi has a specification on the scheme and the interpretation and you live with the one way for the sake of it working consistently for everyone. The idea seems appealing but I believe it would make the system too fragile. With the rise of these ASF/EPL threads I again thought of the pluggable resolution idea. For those with more of a code-centric knowledge of the workings of Apache Maven, is it possible/feasible/semi-cleanly-codeable to have an install, or even project level selection of resolution of artifacts. Sure, it's possible. Maven's behavior is setup in the Maven specific RepositorySystemSession: http://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-aether-provider/src/main/java/org/apache/maven/repository/internal/MavenRepositorySystemSession.java This describes what the various bits do: http://aether.sonatype.org/introduction.html Right now nothing changes in the session once it starts up, and there are no extension points in our particular session. All I see is problems really. If this were project specific we would have to be able to load the scheme from wherever it came from and then determining whether the scheme or interpretations were the same would be problematic. In your particular case where you want to change something like the behaviour of a bound ... maybe that's less problematic but I think everyone living with one defined behavior and it being augmented as a community would be wiser. In OSGi this doesn't really change now because so many people depend on a very specific behaviour. I don't think this would be a great idea, and I'm not convinced it could even work. I imagine a difficulty in that this would have to occur early in the bootstrap process of maven, but if this were the case, would we not be able to work a solution to not only the Aether inclusion issues, but also Kasun's Gentoo resolution issues. This allows the end-user of Apache Maven (in the case that they care about it) the ability to update artifact resolution code independent of maven itself, or use a hardened/locked down resolution scheme backed by portage - and portage only. Apache Maven could stick with (for now) using Aether 1.11, the last dual licensed release out of the box, where as the Gentoo ebuild could configure maven to use its own ( an idea I see as flawed personally ) and those who wish to use Aether, or a custom resolution strategy could do so. Thoughts? Mark - 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 - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C.
