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 --------------------------------------------------------- In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
