2013/3/4 Hervé BOUTEMY <herve.bout...@free.fr>: > some more personal thoughts and questions to make myself an opinion > > - about determining whether Aether API is biased or not: there was an argument > for not developing Aether in Maven that was "Aether API will be more generic > to cover other dependency resolution mecanisms and repository formats, like > P2". Is there something done on this area (be it P2 or anyhting else outside > Maven use)? > > - about maintaining a 3.1.0 bugfix branch like the actual one in parallel with > the master incorporating Eclipse Aether: isn't it the area where the git move > was expected to help? The 3.1.0 is just a bugfix branch, without much commits > expected since the work will happen on master (and on every components/plugins > having an impact from Eclipse Aether integration), or do I miss something? > I suppose these outside component will require some time to adapt and propose > a solution for users.
In such case why not using the opportunity of 4.0.0 to back to a org.apache.maven namespace (with a wrapper on top of the real implementation). At least that will be a more stable namespace. (If did as it since the beginning we could think about something else now !) > > > Regards, > > Hervé > > Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit : >> 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/AAAAAAAAAK8/WT_zSXWy2eQ/grap >> > h.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 >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> 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 > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
