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/AAAAAAAAAK8/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" so we cannot propose an alternative at this point, and as you point out, there is a need for some of the information to be exposed to plugins (heck versions-maven-plugin needs some of that stuff, and I know how difficult it is to maintain functionality across 2.x and 3.x for v-m-p) so we need to tell plugin authors here is the API you can rely on. So I am currently feeling negative towards using Eclipse Aether as that API, but I have no alternative, and I don't have the time to write the shim layer myself, so this is not a veto point... just a sore one. * John Casey was looking at writing an alternative for Aether. I would really like to hear his input w.r.t. how he has got on, and also how well the Aether API has abstracted the problem (given that he would have the view point of an independent implementation in this problem space). *If* John has a nearly complete implementation of his API for dependency graph solving, what I would like to see is how difficult it would be to map his API as an alternative Aether implementation I.O.W. test how well the Aether API abstraction is, and test if there are hidden biases that the architects of the API cannot see by nature of writing their implementation. > 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 think we have said we were going to do a 3.1.0. To be honest this smacks a bit too much of the 3.0 rational again... I fear that given we have said that we were going to do a 3.1.0, let's stick with that. It gives us a little bit more time to digest whether we should bite Eclipse's Aether as an exposed API or whether we should shim it. I am not, given how little time I have to commit code for Maven, going to direct the decision, but that is my view. I will let the people who are willing to step up and commit drive what versions they want to release. > > 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. > I take your point on board, I just don't have a warm and fuzzy feeling that the API of Aether has no design biases that may preclude some of the features that others (such as myself when I *do* get the time) would like to add. > 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. John, could you please chim in with some status information on your explorations > 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. > I don't want Sonatype Aether as the API plugins depend on, so we do need to decouple that from people trying to solve the problem. I don't know yet that Eclipse Aether is an API that is the API we want to expose... I am not saying it isn't, just saying that I don't know it is... yet > > 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, Nothing wrong with that view from my PoV. Multiple implementations, ok so the 3 real implementations share the same root author as original architect, but there are separate communities and the API has been battle hardened for some time. I might quibble with one or two parts of SLF4J, but it has a massive community and it is the defacto standard. > JSR330 is standard More than one implementation, the two major implementations have completely different heritages, again, one may quibble with parts of the API, but it is able to have two big implementations stand on top of it. > and Eclipse Aether post 1.0.0 will adhere to the Eclipse API guidelines > and won't be changing But that is a different metric than the other two technologies. Yes it is better to use this than Sonatype Aether (which since the move to Eclipse is effectively a dead stack... but that was the point of *moving* it to Eclipse) but that does not prove (in the original sense of "test") that the API is absent of biases. SLF4J is tackling a smallish problem, so biases are easy to spot. JSR330 is tacking a problem, to my view, comparable in size to Aether, yet it had two major heavyweight implementations collaborate/fight to build a common API. As such a lot of the biases will have been shaken out... there will still be biases, but there is enough scope between the two major implementations for a 3rd implementation to arise, innovate and steal the crown. How likely is it that a competing implementation could arise and do that with Aether's API? > so it's best just to build on these technologies of any new versions of > Maven and get on with it. > SLF4J, you have my +1 JSR330, you have my +1 Eclipse Aether... * I am +1 on integrating that into Maven, * I am _undecided_ on officially exposing it as an API for plugin developers. I look forward to the debate of those who have the spare time and are prepared to walk the walk and commit code on my points above to sway my opinion. -Stephen > > 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 > > > > > >
