On Wed, Mar 13, 2013 at 8:47 AM, Ansgar Konermann < ansgar.konerm...@googlemail.com> wrote:
> Am 13.03.2013 08:38 schrieb "herve.bout...@free.fr" <herve.bout...@free.fr > >: > > > > If you write documentation in Maven core (the components), not in Maven > site (the global project), you'll be happy with git like you do with > sources > > > > I can then take care of svnpubsub publication, or anybody else since I > already prepared it > > (notice ranting against svnpubsub is just a waste of time and karma) > > What is the value of svnpubsub? Why is it so valuable compared to > alternatives? Which alternatives are could you (all) imagine? > We don't have an alternative at Apache, so it's not worth chewing over, and this is not the list to re-produce infra@'s reasons > > I'm clueless. > > Best > > Ansgar > > > > 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 : mar., mars 12, 2013 16:29 > > > > > > 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 > > > > > > > > > > >
