On Mar 13, 2013, at 3:30 AM, herve.bout...@free.fr wrote: > I'm on vacation, with weak mobile connexion... > I'll try m-dependency-tree when back home > Id You updates m-dependency-p to latest -tree, the hope was it would work > without more efforts >
It may be something small, but it appears to be an issue at the moment. > Envoyé depuis mon mobile > > ----- Reply message ----- > De : "Jason van Zyl" <ja...@tesla.io> > Pour : "Maven Developers List" <dev@maven.apache.org> > Objet : The next major release of Maven: 4.0.0 > Date : mer., mars 13, 2013 08:00 > > > I will push the Eclipse Aether work to a branch as there are several ITs that > fail that are related to using real plugins in the ITs which are affected by > the changes. The dependency plugins and site plugin are the ones that are > visible right now. The shade plugin also doesn't work. > > The ITs should probably not be using real plugins, but we can decide what to > do once the branch is in. > > Hervé, just a note that I quickly tried the dependency tree with the > dependency plugin with Eclipse Aether wired in and it still seems to be > breaking. I have a build if you want to try it to see the error messages. I > assume what's on master is intended to work with both versions of Aether? > > On Mar 12, 2013, at 11:29 AM, Jason van Zyl <ja...@tesla.io> wrote: > >> I would like if someone would volunteer to do the documentation part of the >> release. This will probably be the 3rd time I've merged Eclipse Aether into >> Maven and there are a lot of moving parts that need to be tested and frankly >> it's starting to burn me out. I don't have time or interest in using the >> Subversion-based documentation system so I'd like someone else to do that. >> Do we really have no choice in how we publish our site? Checking stuff into >> SVN for documentation seems arcane and ridiculous. I don't mind doing the >> technical work, I would like someone else to pickup the documentation work >> for the release. Can someone help with that? >> >> On Mar 11, 2013, at 10:33 AM, Jason van Zyl <ja...@tesla.io> wrote: >> >>> 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 <and...@hammar.net> 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 >>>> <mfriedenha...@gmail.com>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" <bri...@infinity.nu> 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 <ja...@tesla.io> wrote: >>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> 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 >>> >>> >>> >>> >>> >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder & CTO, Sonatype >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> The modern conservative is engaged in one of man's oldest exercises in moral >> philosophy; that is, >> the search for a superior moral justification for selfishness. >> >> -- John Kenneth Galbraith >> >> >> >> >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder & CTO, Sonatype > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > The modern conservative is engaged in one of man's oldest exercises in moral > philosophy; that is, > the search for a superior moral justification for selfishness. > > -- John Kenneth Galbraith > > > > > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language
