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 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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
