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 > > > > > > > > > > > > >
