Re: [VOTE] formally end support for Maven 1
+1 Regards, Hervé Le samedi 2 mars 2013 07:18:51 Benson Margulies a écrit : Based on the sentiment on the discussion thread, I call a formal vote to end support for Maven 1.x. This is a vote to: 1: Remove maven 1 release materials from the primary distribution area, leaving them only on the archive. 2: Make appropriate changes to the web site to state clearly that the community no longer provides support for Maven 1. This vote will be open for until Wed March 6, 00:00 GMT (we're not in a hurry here). Here is my +1. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
The next major release of Maven: 4.0.0
Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. As such I believe doing a 3.0.5 release, and then a 3.0.6 release (to fix the problem with 3.0.5), a 3.1.0 release for SLF4J and then a 4.0.0 for the Eclipse Aether changes is just going to confuse users greatly. I would prefer to roll in the Eclipse Aether changes and skip the 3.1.0 release and just call it a 4.0.0. I would just like to move on and start developing some features. Trying to create adapter layers and shims is just going to kill us. I think we should just cut bait because there is no desire amongst the people who can make a shim that have time (myself, Benjamin, Igor) and I doubt Hervé or Kristian really have the time to make a complete shim between the versions of Aether. The few points that people are calling into Aether essentially expose the whole API so the shim needed will be enormous given the package name changes and the API changes in Aether. It will be very much like bridge Aether and Maven Artifact APIs and that simply isn't something that would ever have been done without full-time work and I just don't deem that a worthy investment this time. So I propose rolling in the Eclipse Aether changes along with the JSR330 and SLF4J changes and call it 4.0.0. Also I feel that any hiding of the Aether at this point has been a failure. Everyone is jumping around the Maven Artifact APIs because they need to get at more powerful constructs. This hiding of Aether in practice has been futile and no one is every going to make another artifact API in Maven, it's just not going to happen let's face it. Once Eclipse Aether 1.0.0 is released given the Eclipse standards the API will have to remain compatible. I believe all the changes in Aether made in the last 18 months have been worthwhile and there's no point to unwind anything to try and make it work with Sonatype Aether. If we agree on this then I will roll in all the changes, figure out what's wrong with JDK8 and then we release it. The ITs pass and we'll just have to help people adapt their plugins. I talked to Manfred Moser who works on the Android Maven plugin and he doesn't see an issue with updating. We'll just have to update the rest of the plugins or we'll be spending months trying to make a shim or a magic classloader and I'm not sure it's really worth it. I think it's time to move on with our better core and just move on in general. I think people need to digest this and think about it, but I do believe it is the most practical way forward. SLF4J I consider standard, JSR330 is standard and Eclipse Aether post 1.0.0 will adhere to the Eclipse API guidelines and won't be changing so it's best just to build on these technologies of any new versions of Maven and get on with it. Thanks, Jason [1]: http://ci.tesla.io:8080/job/tesla-its/ws/ -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl
Re: [VOTE] formally end support for Maven 1
+1 On Sun, Mar 3, 2013 at 5:34 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 Regards, Hervé Le samedi 2 mars 2013 07:18:51 Benson Margulies a écrit : Based on the sentiment on the discussion thread, I call a formal vote to end support for Maven 1.x. This is a vote to: 1: Remove maven 1 release materials from the primary distribution area, leaving them only on the archive. 2: Make appropriate changes to the web site to state clearly that the community no longer provides support for Maven 1. This vote will be open for until Wed March 6, 00:00 GMT (we're not in a hurry here). Here is my +1. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] formally end support for Maven 1
+1 (non binding). Kind regards Karl-Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path.
Re: [VOTE] Release Maven Changes Plugin version 2.9
+0.5 (non-binding) the documentation at http://maven.apache.org/plugins-archives/maven-changes-plugin-2.9/announcement-generate-mojo.html#issueManagementSystems does not list GitHub (or Trac) as valid system. So I had to configure the changes-plugin to explicitly use GitHub although this is the only issueManagement in my pom. Then the announcement-report was generated. Regards Mirko On Sun, Mar 3, 2013 at 8:40 AM, Markku Saarela markku.saar...@iki.fi wrote: +1 (non-binding) GitHub generate announcement report works. Cheers, Markku Saarela On 03/02/2013 12:56 AM, Benson Margulies wrote: Hi, We solved some issues: ** Bug * [MCHANGES-276] - TracDownloader does not set issue key to ticket id * [MCHANGES-293] - XML Parser error backtraces from, presumably, malformed JIRA responses * [MCHANGES-299] - ClassNotFoundException when running jira-report using Maven 2.2.1 * [MCHANGES-301] - Impossible to use ParameterBasedQuery in combination with JIRA authentication * [MCHANGES-302] - The REST API is always used when JIRA authentication is configured ** Improvement * [MCHANGES-46] - There is no link to the RSS feed of changes in the changes report * [MCHANGES-278] - Improved logging and exception messages to aid troubleshooting * [MCHANGES-289] - Please add support for HTTP digest authentication to the 'trac-report' plugin. * [MCHANGES-290] - Provide GitHub support for generate announcement report * [MCHANGES-295] - Remove need for numeric component ID's etc when using REST with JIRA ** New Feature * [MCHANGES-300] - Make it possible to run the changes-check and changes-validate goals only once for a multi-module project There are still a couple of issues left in JIRA: http://jira.codehaus.org/issues/?jql=project%20%3D%20MCHANGES%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC Staging repo: https://repository.apache.org/content/repositories/maven-321/ https://repository.apache.org/content/repositories/maven-321/org/apache/maven/plugins/maven-changes-plugin/2.9/maven-changes-plugin-2.9-source-release.zip Staging site: http://maven.apache.org/plugins-archives/maven-changes-plugin-2.9/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
On 3 Mar 2013, at 14:16, Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. Apart from the org.sonatype.aether - org.eclipse.aether package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. As such I believe doing a 3.0.5 release, and then a 3.0.6 release (to fix the problem with 3.0.5), a 3.1.0 release for SLF4J and then a 4.0.0 for the Eclipse Aether changes is just going to confuse users greatly. I would prefer to roll in the Eclipse Aether changes and skip the 3.1.0 release and just call it a 4.0.0. Speaking personally, one concern I have is that there will no doubt be other major features people want to get into 4.0.0 (because of the major version shift) and this could all take a while to plan, stabilize, and release - meanwhile there could be minor fixes and features stuck in limbo that would benefit people. So while I think it's a good idea to plan for 4.0.0 I'm not sure that should prevent anyone planning a 3.0.x or 3.1.x release. PS. I see that Maven trunk currently exports org.sonatype.inject from the core realm - this package is not required for the JSR330 support, only if you want to use some of the additional Sisu behaviour such as eager singletons. If you happen to know which classes or annotations you want to use (or are using) from this package then I can make sure that they will also be supported in Eclipse/Sisu. It only contains a small handful of interfaces and annotations so this really isn't much work. Otherwise if you don't use anything from org.sonatype.inject then I suggest this package is removed from the export list for the moment. -- Cheers, Stuart I would just like to move on and start developing some features. Trying to create adapter layers and shims is just going to kill us. I think we should just cut bait because there is no desire amongst the people who can make a shim that have time (myself, Benjamin, Igor) and I doubt Hervé or Kristian really have the time to make a complete shim between the versions of Aether. The few points that people are calling into Aether essentially expose the whole API so the shim needed will be enormous given the package name changes and the API changes in Aether. It will be very much like bridge Aether and Maven Artifact APIs and that simply isn't something that would ever have been done without full-time work and I just don't deem that a worthy investment this time. So I propose rolling in the Eclipse Aether changes along with the JSR330 and SLF4J changes and call it 4.0.0. Also I feel that any hiding of the Aether at this point
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 2:43 PM, Stuart McCulloch mccu...@gmail.com wrote: On 3 Mar 2013, at 14:16, Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. Apart from the org.sonatype.aether - org.eclipse.aether package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code. I'll collect them with Benjamin, as I'm not sure how good any standard API diffing tool is going to work with all the package changes. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. As such I believe doing a 3.0.5 release, and then a 3.0.6 release (to fix the problem with 3.0.5), a 3.1.0 release for SLF4J and then a 4.0.0 for the Eclipse Aether changes is just going to confuse users greatly. I would prefer to roll in the Eclipse Aether changes and skip the 3.1.0 release and just call it a 4.0.0. Speaking personally, one concern I have is that there will no doubt be other major features people want to get into 4.0.0 (because of the major version shift) and this could all take a while to plan, stabilize, and release - I don't really want to add anything beyond JSR330, SLF4J and Eclipse Aether. The frequency of change in the core for new features basically ground to a halt. I really don't think this behaviour is going to change radically so I don't see much point in waiting for anything beyond agreement to get a 4.0.0 out the door. meanwhile there could be minor fixes and features stuck in limbo that would benefit people. So while I think it's a good idea to plan for 4.0.0 I'm not sure that should prevent anyone planning a 3.0.x or 3.1.x release. If someone wants to do a 3.1.x that's fine with me but I think having two major branches will just get out of sync. I'm personally in favour of getting a 4.0.0 as fast as possible because the ITs still pass and the few plugins that seem to have issue can be fixed pretty quickly. I just don't think the bandwidth exists to maintain two major branches. Sonatype Aether isn't going to get any love and syncing the branches across package changes probably won't be much fun. We would probably also have to deal with multiple branches across the plugins that will be affected. I proposed what I'm willing to maintain and I think that's ultimately going to be the easiest for us to maintain. PS. I see that Maven trunk currently exports org.sonatype.inject from the core realm - this package is not required for the JSR330 support, only if you want to use some of the additional Sisu behaviour such as eager singletons. If you happen to know which classes or annotations you want to use (or are using) from this package then I can make sure that they
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: [VOTE] formally end support for Maven 1
+1 On 03/03/2013, at 2:18 AM, Benson Margulies bimargul...@gmail.com wrote: Based on the sentiment on the discussion thread, I call a formal vote to end support for Maven 1.x. This is a vote to: 1: Remove maven 1 release materials from the primary distribution area, leaving them only on the archive. 2: Make appropriate changes to the web site to state clearly that the community no longer provides support for Maven 1. This vote will be open for until Wed March 6, 00:00 GMT (we're not in a hurry here). Here is my +1. - 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 http://twitter.com/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. I would rather see us use the version number to communicate with the vast number of people who use Maven. So, I'd switch to Eclipse Aether, including the need to fork a few plugins, as 3.2, and use the number 4.0.0 for a version that has real user-visible impact and value. If you presented a long list of wonderful user-visible improvements that would result from the adoption of the new Aether, I'd be happier with your proposal. On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. I have not formed an opinion yet, but here are some things that are filtering around in my head w.r.t. this proposal. * When the switch to Aether was originally put forward, the promise was that with Aether at Eclipse there would be a community of people to work on the directed dependency graph problem set... http://lh5.ggpht.com/-MY5CB_MVKCo/UQErH7pws-I/AK8/WT_zSXWy2eQ/graph.png?imgmax=800 I am seriously worried when I see that *I* am the #3 most active committer to Aether at Eclipse, not that I don't believe I could be a contributor to Aether, more that I have on two occasions said OK, Stephen, time to try and get involved with Aether, started trying to get my feet wet with some small tweaks, and then had my spare time stolen again. I.O.W. I have not engaged with Aether to the level I feel comfortable with saying *I* am a significant contributor...and I (as of 3rd Feb 2012) am the #3 committer! * OK, so logback has effectively 1 active committer... but a very long history, and an API that other implementations are available for, and it's the defacto standard. Aether has really only got users because of Maven from what I can see, and it's got Benjamin as its developer and driver. Now Benjamin knows this space backwards and is great at writing good code... if this is the proposal to resolve the issue of keeping Benjamin's skills available for Maven, while Benjamin (for perfectly legitimate, if outside of the control of the PMC, reasons) does not want to develop code at ASF (based on the evidence of not seeing any engagement from Benjamin since the Board reared its heavy hand), then lets state it as such. But I see that the community of logback developers vs the community of aether developers are a different kettle of fish. If we tie ourselves now to the Aether API, we make it hard to move to an alternative implementation. If there were two competing implementations of the Aether API I would be happy to say that the API is robust and there has been true separation of API from Implementation. In this case we have and API with one and only one implementation, it may or may not have true separation of API from Implementation, but without having been hardened by having a second implementation, it is hard to know for sure. There may be design biases based on the views of the implementers. I guess my point is that I would need to be convinced some more that we would not be baking an API with biases into the core of Maven. Right now we have the case where a few plugins have leaked dependencies to Sonatype Aether, the Maven developer view has been that plugin authors should not do that, but obviously some have, in so doing they should have been aware of the risk they take in using APIs that Maven is not saying are part of the exported hull. Having said that, nobody else has stood up to say oh I have an alternative for Aether
Re: The next major release of Maven: 4.0.0
On 3 March 2013 22:41, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. I would rather see us use the version number to communicate with the vast number of people who use Maven. So, I'd switch to Eclipse Aether, including the need to fork a few plugins, as 3.2, and use the number 4.0.0 for a version that has real user-visible impact and value. Well I agree with Semantic Versioning, so the question here that dictates 3.2 vs 4.0 is whether we see Sonatype Aether as part of the exposed supported API of Maven. IIRC the stated position is that plugin authors are not supposed to rely on the Sonatype Aether API. If plugin authors have relied on it then they are responsible for ensuring that the plugin works in its absence... that would strongly indicate that 3.2 (or 3.1 if at the same time as SLF4J) is the correct SemVer version... but if you view the Sonatype Aether API as being part of the exposed supported API of Maven (as opposed to leaked unsupported API) then 4.0 would be the correct SemVer -Stepjen If you presented a long list of wonderful user-visible improvements that would result from the adoption of the new Aether, I'd be happier with your proposal. On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
Well I agree with Semantic Versioning, so the question here that dictates 3.2 vs 4.0 is whether we see Sonatype Aether as part of the exposed supported API of Maven. IIRC the stated position is that plugin authors are not supposed to rely on the Sonatype Aether API. If plugin authors have relied on it then they are responsible for ensuring that the plugin works in its absence... that would strongly indicate that 3.2 (or 3.1 if at the same time as SLF4J) is the correct SemVer version... but if you view the Sonatype Aether API as being part of the exposed supported API of Maven (as opposed to leaked unsupported API) then 4.0 would be the correct SemVer What if we published a specific policy that covered this case: something like: The Maven project is in transition in the area of dependency resolution. The existing official API is good enough for many problems, but does not expose enough operations to allow the correct implementation of a few, important plugins. Therefore, these plugins are coded directly to 'Sonatype Aether.' The Maven community plans to make changes to these APIs over the next few releases as we work to refine an appropriate public API in this area. Since these changes won't have much user-visible impact, they won't be major versions, even though they will change this API, and require the few plugins which touch it to change to track it. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
Stephen, It doesn't matter where the code is. It's complicated, takes a lot of effort to understand and I don't really care, or see it as a problem that Benjamin is the one who works on it most. No one else worked on here, no one else is working on it there. It's not where it is, it's that it's a non-trivial body of code that requires focus and effort that any casual observer doesn't have the time for. The only people who have ever worked on it are those that were employed to work on it specifically. I don't see this as an issue, it's simply the way it is. Aether is already exposed and it's because the Maven Artifact APIs are anemic that it's used directly. Aether is complete, anything else made is just going to make a huge wrapper around that which serves no purpose really. If in the 18 months since Aether has been at Eclipse nothing has been done do you really think anything can be made in a timely fashion? I think that unlikely. There's probably 1000 man hours in Aether at least and there's probably lots of biases in the codebase because no one contributes anything to it for all the reasons cited above. Such is the reality we have right now. Until I actually merged in Eclipse Aether, worked with Benjamin to get all the ITs working, and testing it in the field with 10 or so people I didn't know how much work was involved, or what plugins were affected until I started getting feedback. I am not interested in weaving stuff back and forth between the branches given that all the ITs work with Eclipse Aether merged in and there are a few plugin compatibility issues. I myself cannot imagine trying to keep the two of those branches in sync and I don't see the point because the Eclipse Aether stuff is ready. I have the energy to maintain what I proposed. Even if someone wanted to stand up and maintain the 3.1.x branch I believe it would be a waste of time given what little time the core receives. On Mar 3, 2013, at 5:54 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 3 March 2013 14:16, Jason van Zyl ja...@tesla.io wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. SLF4J may cause some issues, but the introduction of Eclipse Aether is almost certainly going to cause issues. In Eclipse Aether some internal representations have been changed and it's not completely backward compatible. These changes have been made for good reason but because we waited almost 18 months to attempt to integrate Eclipse Aether there is some drift in the APIs and the Sonatype Aether APIs have leaked out into plugins like the Android Maven Plugin, the Shade Plugin, the Dependency Plugin and any plugin that reaches into the core of Maven to get Aether classes. Shielding Aether from users hasn't worked out in practice. I have had a version of Tesla[1] that integrates SLF4J and Eclipse Aether and the ITs pass but I've had many issues with plugins (and with the latest JDK8 I need to track down). I've had people using it for a couple weeks and all of them have run into Aether related issues in one or more of the plugins I've mentioned above. I quickly tried to build the new dependency plugin with the dependency tree and it doesn't appear yet to bridge the difference between Sonatype Aether and Eclipse Aether in the dependency plugin. I'm not sure this approach will work. I can tell you from the first time we created a shim between Aether and the Maven Artifact APIs that this was not fun and it took full-time work for a couple months. I am not willing to do that again and I honestly doubt anyone but myself or Benjamin can do it in a reasonable amount of time and neither of us want to do it. I don't think it's the end of the world that some plugins that touch Aether will not work without some upgrading. But this is a major API breakage and would deserve a major version change to 4.0.0. I think it needs to be clear that people know what they may potentially be getting themselves into. I have not formed an opinion yet, but here are some things that are filtering around in my head w.r.t. this proposal. * When the switch to Aether was originally put forward, the promise was that with Aether at Eclipse there would be a community of people to work on the directed dependency graph problem set... http://lh5.ggpht.com/-MY5CB_MVKCo/UQErH7pws-I/AK8/WT_zSXWy2eQ/graph.png?imgmax=800 I am seriously worried when I see that *I* am the #3 most active committer to Aether at Eclipse, not that I don't believe I could be a contributor to Aether, more that I have on two occasions said OK, Stephen, time to try and get involved with Aether, started trying to get my feet wet with some small tweaks, and then had my spare time stolen again. I.O.W. I have not engaged with Aether to the level I feel
Re: The next major release of Maven: 4.0.0
On Mar 3, 2013, at 5:41 PM, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says we did our best to make everything work, but you may have issues. I would rather see us use the version number to communicate with the vast number of people who use Maven. How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant. So, I'd switch to Eclipse Aether, including the need to fork a few plugins, as 3.2, and use the number 4.0.0 for a version that has real user-visible impact and value. I see JSR330, SLF4J and Eclipse Aether as valuable. If you presented a long list of wonderful user-visible improvements that would result from the adoption of the new Aether, I'd be happier with your proposal. I have no long use of user-visible improvements because I'm the only one working on the core. There's only so much I'm willing to do and I won't develop any features until I know they will be used. On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.com wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - 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 CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C.
Re: The next major release of Maven: 4.0.0
On Sun, Mar 3, 2013 at 4:29 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 5:41 PM, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says we did our best to make everything work, but you may have issues. I would rather see us use the version number to communicate with the vast number of people who use Maven. How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant. Let's consider three audiences: 1. end users 2. most plugin developers 3. core devs and the devs of the small inventory of very dependency-sensitve plugins I think that all of these things you are citing are good things. But I think that they are mostly in categories 2 and 3, and in the case of Aether, entirely in 3. Thus my view about version numbers. if I'm missing something and picking up a new Aether has benefits for category 1, great. I also want to write now that I'm not on a campaign here. I'd rather see all this happen as '4.0.0' than not happen at all, even if my preference is as expressed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The next major release of Maven: 4.0.0
To me I would like to roll in all of it, I think the bump in major version is appropriate but if we call that 3.1.0 that's fine. It really does work almost the same, there are some plugins that will get need some rework but that's not the end of the world. To me a plugin that works in 3.0.x but not in another later versions is a major breakage. We can define it however we like and call the version whatever we like. I think the major rub is adopting Aether as the Artifact API we're going to expose. My opinion is that it already is. It's out there because people ducked around to get at Aether but we also allowed the RepositorySystem and RepositorySystemSession to be pushed into plugins. Some people moaned but no one stopped it and that is public plugin API as far as I'm concerned. With those two classes exposed you have access to all of Aether and that's been sitting there for 2 years. So the cat is out of the bag and another Artifact API is such a futile value-less effort given Aether's existence. If someone had jumped up and made the bridge a year ago and kept in sync with Eclipse Aether that would be different. But as I noted it's hard, time consuming work. Unless someone commits to do full-time work on this I don't see a bridge, or shim, or new API being made before I'm elderly. If we roll the combo of JSR330, SLF4J and Eclipse Aether things will work for most and we can probably update the rest of the plugins before anyone switches. The code will also be smaller, the dependency plugins using Aether, for example, would probably shed 2/3 of the code. On Mar 3, 2013, at 7:58 PM, Benson Margulies bimargul...@gmail.com wrote: On Sun, Mar 3, 2013 at 4:29 PM, Jason van Zyl ja...@tesla.io wrote: On Mar 3, 2013, at 5:41 PM, Benson Margulies bimargul...@gmail.com wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says we did our best to make everything work, but you may have issues. I would rather see us use the version number to communicate with the vast number of people who use Maven. How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant. Let's consider three audiences: 1. end users 2. most plugin developers 3. core devs and the devs of the small inventory of very dependency-sensitve plugins I think that all of these things you are citing are good things. But I think that they are mostly in categories 2 and 3, and in the case of Aether, entirely in 3. Thus my view about version numbers. if I'm missing something and picking up a new Aether has benefits for category 1, great. I also want to write now that I'm not on a campaign here. I'd rather see all this happen as '4.0.0' than not happen at all, even if my preference is as expressed. - 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 CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith
Re: The next major release of Maven: 4.0.0
Same here. On Sunday, March 3, 2013, Benson Margulies wrote: As I see it, you are using the version number to communicate with the tiny number of people who have made plugins that depend on Aether. I would rather see us use the version number to communicate with the vast number of people who use Maven. So, I'd switch to Eclipse Aether, including the need to fork a few plugins, as 3.2, and use the number 4.0.0 for a version that has real user-visible impact and value. If you presented a long list of wonderful user-visible improvements that would result from the adoption of the new Aether, I'd be happier with your proposal. On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.iojavascript:; wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.comjavascript:; wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl ja...@tesla.iojavascript:; wrote: On Mar 3, 2013, at 2:23 PM, Mark Derricutt m...@talios.comjavascript:; wrote: A quick answer whilst I let my thoughts dwell on the full long post.. If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ). To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition. Mark Jason van Zyl wrote: Hi, No one seems to object to doing a release with the SLF4J support without the isolation so I wanted to discuss what happens when we integrate Eclipse Aether and suggest an alternate release path. Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:;
Re: [VOTE] formally end support for Maven 1
+1 (not binding) -Lukas Benson Margulies wrote: Based on the sentiment on the discussion thread, I call a formal vote to end support for Maven 1.x. This is a vote to: 1: Remove maven 1 release materials from the primary distribution area, leaving them only on the archive. 2: Make appropriate changes to the web site to state clearly that the community no longer provides support for Maven 1. This vote will be open for until Wed March 6, 00:00 GMT (we're not in a hurry here). Here is my +1. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
