You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "herve.boutemy@free.fr" <he...@free.fr> on 2013/03/13 08:30:36 UTC
Re : The next major release of Maven: 4.0.0
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
Envoyé depuis mon mobile
----- Reply message -----
De : "Jason van Zyl" <ja...@tesla.io>
Pour : "Maven Developers List" <de...@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 <an...@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
>>> <mf...@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" <br...@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 <he...@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
>>>>>>>> <st...@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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Olivier Lamy
>>>>>>> Talend: http://coders.talend.com
>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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
Re: The next major release of Maven: 4.0.0
Posted by Jason van Zyl <ja...@tesla.io>.
On Mar 13, 2013, at 3:30 AM, herve.boutemy@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" <de...@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 <an...@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
>>>> <mf...@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" <br...@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 <he...@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
>>>>>>>>> <st...@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-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Olivier Lamy
>>>>>>>> Talend: http://coders.talend.com
>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@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