My one comment would be to please just get this out and available to everyone soon so we can move on.
manfred > 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 > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
