Any other comments? Unless I hear otherwise this week I'll start merging Eclipse Aether into master and start a discussion about what that means.
On Mar 10, 2013, at 1:20 AM, Anders Hammar <[email protected]> wrote: > Personally I would like us to stick with the initial discussion of shipping > 3.1 with the slf4j usage (and slf4j-simple). That's what we've discussed > and talked about for some time so it would be great to get that out of the > door. The we could discuss the next step. Basically, and generally, I'd > like us to stick to the plans we discuss. > > At the same time I fully appreciate that I'm not doing the work. > > > On Sat, Mar 9, 2013 at 9:04 AM, Mirko Friedenhagen > <[email protected]>wrote: > >> Well at least with Maven 4.0 I would not get the question anymore, why the >> pom's model version is at 4 while we use Maven 3 ;-). >> >> Regards Mirko >> -- >> Sent from my mobile >> On Mar 9, 2013 12:15 AM, "Brian Fox" <[email protected]> wrote: >> >>> I don't think we should move to 4.0 because of this. The primary consumer >>> of our systems are the end users and this change doesn't represent "api" >>> breakage to them. If we make what appears to be such a large version >>> change, that could scare off or confuse people who are just now warming >> up >>> to 3.x. I think this does need to be resolved, but lets just call it 3.1 >>> and notify the plugins that need to know directly. >>> >>> >>> On Wed, Mar 6, 2013 at 9:20 PM, Jason van Zyl <[email protected]> wrote: >>> >>>> >>>> On Mar 6, 2013, at 6:09 PM, Olivier Lamy <[email protected]> wrote: >>>> >>>>> 2013/3/4 Hervé BOUTEMY <[email protected]>: >>>>>> 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 >>>>>> <[email protected]> wrote: >>>>>>>> On 3 March 2013 14:16, Jason van Zyl <[email protected]> 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: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olivier Lamy >>>>> Talend: http://coders.talend.com >>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa
