On Mar 6, 2013, at 6:09 PM, Olivier Lamy <ol...@apache.org> wrote: > 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).
Go for it. As I wrote previously if anyone wants to make a shim or compatibility layer over Eclipse Aether they are welcome too. I'm not doing for all the reasons I cited previously, but feel free to take the opportunity. > 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 > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- I never make the mistake of arguing with people for whose opinions I have no respect. -- Edward Gibbon
