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 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. > Ok, I'll take a look. > -- > 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 > 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.
