The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

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.

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

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

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, JSR330 is standard and Eclipse Aether post 1.0.0 will adhere to the Eclipse API guidelines and won't be changing so it's best just to build on these technologies of any new versions of Maven and get on with it.

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

Re: The next major release of Maven: 4.0.0

[Manfred Moser <ma...@mosabuam.com>]

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

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

[Jason van Zyl <ja...@tesla.io>]

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

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

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

Re: The next major release of Maven: 4.0.0

[Anders Hammar <an...@hammar.net>]

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

Re: The next major release of Maven: 4.0.0

[Mirko Friedenhagen <mf...@gmail.com>]

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

Re: The next major release of Maven: 4.0.0

[Brian Fox <br...@infinity.nu>]

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

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

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

Re: The next major release of Maven: 4.0.0

[Olivier Lamy <ol...@apache.org>]

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

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

On Mar 4, 2013, at 2:52 AM, Hervé BOUTEMY <he...@free.fr> wrote:

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

I'm using an OSGi version scheme with semantic versioning for some continuous delivery work I'm doing. As for a bias I'm not sure exactly what the concern is because the Aether provider we have here encapsulates everything that Maven currently does. Even across the change to Eclipse Aether this behaviour is preserved which is important. I plan to stop using SNAPSHOT repositories in Tesla and I will have a slightly different version scheme so I'm using more of the capabilities of Aether. There have been patches by some people using SBT where they are using Aether instead of Ivy. The way trees can be transformed into the final graph is still completely flexible in Aether and that's very powerful.

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

If you want to maintain a 3.1.x branch that's fine with me. I personally don't see any value, I think it will be more work than it appears. I've spent a lot of the last month merging and testing Eclipse Aether with Maven's core. But if you or someone else wants to maintain it and backport changes from master that's great. But I don't have time or the desire to maintain both.

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

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

Re: The next major release of Maven: 4.0.0

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


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

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

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/graph.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

Re: The next major release of Maven: 4.0.0

[Stephen Connolly <st...@gmail.com>]

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/graph.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
>
>
>
>
>
>

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

To me I would like to roll in all of it, I think the bump in major version is appropriate but if we call that 3.1.0 that's fine. It really does work almost the same, there are some plugins that will get need some rework but that's not the end of the world. To me a plugin that works in 3.0.x but not in another later versions is a major breakage. We can define it however we like and call the version whatever we like.

I think the major rub is adopting Aether as the Artifact API we're going to expose. My opinion is that it already is. It's out there because people ducked around to get at Aether but we also allowed the RepositorySystem and RepositorySystemSession to be pushed into plugins. Some people moaned but no one stopped it and that is public plugin API as far as I'm concerned. With those two classes exposed you have access to all of Aether and that's been sitting there for 2 years. So the cat is out of the bag and another Artifact API is such a futile value-less effort given Aether's existence. If someone had jumped up and made the bridge a year ago and kept in sync with Eclipse Aether that would be different. But as I noted it's hard, time consuming work. Unless someone commits to do full-time work on this I don't see a bridge, or shim, or new API being made before I'm elderly.

If we roll the combo of JSR330, SLF4J and Eclipse Aether things will work for most and we can probably update the rest of the plugins before anyone switches. The code will also be smaller, the dependency plugins using Aether, for example, would probably shed 2/3 of the code.

On Mar 3, 2013, at 7:58 PM, Benson Margulies <bi...@gmail.com> wrote: 

> On Sun, Mar 3, 2013 at 4:29 PM, Jason van Zyl <ja...@tesla.io> wrote:
>> 
>> On Mar 3, 2013, at 5:41 PM, Benson Margulies <bi...@gmail.com> wrote:
>> 
>>> As I see it, you are using the version number to communicate with the
>>> tiny number of people who have made plugins that depend on Aether.
>>> 
>> 
>> Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says "we did our best to make everything work, but you may have issues."
>> 
>>> I would rather see us use the version number to communicate with the
>>> vast number of people who use Maven.
>>> 
>> 
>> How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant.
> 
> Let's consider three audiences:
> 
> 1. end users
> 2. most plugin developers
> 3. core devs and the devs of the small inventory of very
> dependency-sensitve plugins
> 
> I think that all of these things you are citing are good things. But I
> think that they are mostly in categories 2 and 3, and in the case of
> Aether, entirely in 3. Thus my view about version numbers. if I'm
> missing something and picking up a new Aether has benefits for
> category 1, great.
> 
> I also want to write now that I'm not on a campaign here. I'd rather
> see all this happen as '4.0.0' than not happen at all, even if my
> preference is as expressed.
> 
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------

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

[Benson Margulies <bi...@gmail.com>]

On Sun, Mar 3, 2013 at 4:29 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Mar 3, 2013, at 5:41 PM, Benson Margulies <bi...@gmail.com> wrote:
>
>> As I see it, you are using the version number to communicate with the
>> tiny number of people who have made plugins that depend on Aether.
>>
>
> Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says "we did our best to make everything work, but you may have issues."
>
>> I would rather see us use the version number to communicate with the
>> vast number of people who use Maven.
>>
>
> How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant.

Let's consider three audiences:

1. end users
2. most plugin developers
3. core devs and the devs of the small inventory of very
dependency-sensitve plugins

I think that all of these things you are citing are good things. But I
think that they are mostly in categories 2 and 3, and in the case of
Aether, entirely in 3. Thus my view about version numbers. if I'm
missing something and picking up a new Aether has benefits for
category 1, great.

I also want to write now that I'm not on a campaign here. I'd rather
see all this happen as '4.0.0' than not happen at all, even if my
preference is as expressed.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: The next major release of Maven: 4.0.0

[Arnaud Héritier <ah...@gmail.com>]

I have no more time to spend on maven sadly.
I pushed here some things I would like to see in a new major version
https://gist.github.com/olamy/5081375
And for sure as an end user I have really nothing to do about SLF4J,
aether, Guice or any other component used within the product.
I understand very well that we have a debt, and we'll need to pay it.
We need to renew our stack and a part of code that didn't evolved a lot
especially if we want to address some features I listed but don't tell me
that you will do a Maven 4=3+ with only some internal changes and no/few
users related improvements.
I really don't like Gradle and others projects like these where you are
quickly writing a project dedicated to the build inside your dev project
just to create a war, jar because in the major part of them it is useless.
But I may really understand people switching to such tool just because they
are seeing no future in Maven itself.
Let's be clear, there is no personal attack and all of us are probably
responsible to where we are nowadays but that's sad.
I won't spend more time to reply, as I said I cannot any more.
I wish you good luck

Cheers,



On Mon, Mar 4, 2013 at 1:29 AM, Jason van Zyl <ja...@tesla.io> wrote:

>
> On Mar 3, 2013, at 5:41 PM, Benson Margulies <bi...@gmail.com>
> wrote:
>
> > As I see it, you are using the version number to communicate with the
> > tiny number of people who have made plugins that depend on Aether.
> >
>
> Any JSR330 discrepancies, SLF4J being used for logging and the Aether
> changes. 4.0.0 says "we did our best to make everything work, but you may
> have issues."
>
> > I would rather see us use the version number to communicate with the
> > vast number of people who use Maven.
> >
>
> How do you see this as not communicating with everyone. JSR330, SLF4J, and
> Eclipse Aether are not insignificant.
>
> > So, I'd switch to Eclipse Aether, including the need to fork a few
> > plugins, as 3.2, and use the number 4.0.0 for a version that has real
> > user-visible impact and value.
> >
>
> I see JSR330, SLF4J and Eclipse Aether as valuable.
>
> > If you presented a long list of wonderful user-visible improvements
> > that would result from the adoption of the new Aether, I'd be happier
> > with your proposal.
> >
>
> I have no long use of user-visible improvements because I'm the only one
> working on the core. There's only so much I'm willing to do and I won't
> develop any features until I know they will be used.
>
> >
> > On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
> >>
> >> On Mar 3, 2013, at 2:23 PM, Mark Derricutt <ma...@talios.com> wrote:
> >>
> >>> A quick answer whilst I let my thoughts dwell on the full long post..
> >>>
> >>> If we're jumping to a major release here, is this a viable time to
> also update the schema and address of the things we've long been wanting
> there? ( mixins of some form ) - or is this out of scope ( of this
> discussion at least ).
> >>>
> >>
> >> To me it's out of scope. I want to get the API changes out there and
> signal the potential of major API breakages. Features can be rolled out
> whenever. To me the change in versions is to signal API breakage, not
> feature addition.
> >>
> >>> Mark
> >>>
> >>>
> >>> Jason van Zyl 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.
> >>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> the course of true love never did run smooth ...
> >>
> >> -- Shakespeare
> >>
> >>
> >>
> >>
> >>
> >
> >
> > On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
> >>
> >> On Mar 3, 2013, at 2:23 PM, Mark Derricutt <ma...@talios.com> wrote:
> >>
> >>> A quick answer whilst I let my thoughts dwell on the full long post..
> >>>
> >>> If we're jumping to a major release here, is this a viable time to
> also update the schema and address of the things we've long been wanting
> there? ( mixins of some form ) - or is this out of scope ( of this
> discussion at least ).
> >>>
> >>
> >> To me it's out of scope. I want to get the API changes out there and
> signal the potential of major API breakages. Features can be rolled out
> whenever. To me the change in versions is to signal API breakage, not
> feature addition.
> >>
> >>> Mark
> >>>
> >>>
> >>> Jason van Zyl 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.
> >>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder & CTO, Sonatype
> >> Founder,  Apache Maven
> >> http://twitter.com/jvanzyl
> >> ---------------------------------------------------------
> >>
> >> the course of true love never did run smooth ...
> >>
> >> -- Shakespeare
> >>
> >>
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> ---------------------------------------------------------
>
> To do two things at once is to do neither.
>
>  -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>


-- 
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

On Mar 3, 2013, at 5:41 PM, Benson Margulies <bi...@gmail.com> wrote:

> As I see it, you are using the version number to communicate with the
> tiny number of people who have made plugins that depend on Aether.
> 

Any JSR330 discrepancies, SLF4J being used for logging and the Aether changes. 4.0.0 says "we did our best to make everything work, but you may have issues."

> I would rather see us use the version number to communicate with the
> vast number of people who use Maven.
> 

How do you see this as not communicating with everyone. JSR330, SLF4J, and Eclipse Aether are not insignificant.

> So, I'd switch to Eclipse Aether, including the need to fork a few
> plugins, as 3.2, and use the number 4.0.0 for a version that has real
> user-visible impact and value.
> 

I see JSR330, SLF4J and Eclipse Aether as valuable.

> If you presented a long list of wonderful user-visible improvements
> that would result from the adoption of the new Aether, I'd be happier
> with your proposal.
> 

I have no long use of user-visible improvements because I'm the only one working on the core. There's only so much I'm willing to do and I won't develop any features until I know they will be used.

> 
> On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
>> 
>> On Mar 3, 2013, at 2:23 PM, Mark Derricutt <ma...@talios.com> wrote:
>> 
>>> A quick answer whilst I let my thoughts dwell on the full long post..
>>> 
>>> If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ).
>>> 
>> 
>> To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition.
>> 
>>> Mark
>>> 
>>> 
>>> Jason van Zyl 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.
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> the course of true love never did run smooth ...
>> 
>> -- Shakespeare
>> 
>> 
>> 
>> 
>> 
> 
> 
> On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
>> 
>> On Mar 3, 2013, at 2:23 PM, Mark Derricutt <ma...@talios.com> wrote:
>> 
>>> A quick answer whilst I let my thoughts dwell on the full long post..
>>> 
>>> If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ).
>>> 
>> 
>> To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition.
>> 
>>> Mark
>>> 
>>> 
>>> Jason van Zyl 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.
>>> 
>> 
>> Thanks,
>> 
>> Jason
>> 
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder & CTO, Sonatype
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> ---------------------------------------------------------
>> 
>> the course of true love never did run smooth ...
>> 
>> -- Shakespeare
>> 
>> 
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------

To do two things at once is to do neither.
 
 -- Publilius Syrus, Roman slave, first century B.C.

Re: The next major release of Maven: 4.0.0

[Stephane Nicoll <st...@gmail.com>]

Same here.

On Sunday, March 3, 2013, Benson Margulies wrote:

> As I see it, you are using the version number to communicate with the
> tiny number of people who have made plugins that depend on Aether.
>
> I would rather see us use the version number to communicate with the
> vast number of people who use Maven.
>
> So, I'd switch to Eclipse Aether, including the need to fork a few
> plugins, as 3.2, and use the number 4.0.0 for a version that has real
> user-visible impact and value.
>
> If you presented a long list of wonderful user-visible improvements
> that would result from the adoption of the new Aether, I'd be happier
> with your proposal.
>
>
> On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <jason@tesla.io<javascript:;>>
> wrote:
> >
> > On Mar 3, 2013, at 2:23 PM, Mark Derricutt <mark@talios.com<javascript:;>>
> wrote:
> >
> >> A quick answer whilst I let my thoughts dwell on the full long post..
> >>
> >> If we're jumping to a major release here, is this a viable time to also
> update the schema and address of the things we've long been wanting there?
> ( mixins of some form ) - or is this out of scope ( of this discussion at
> least ).
> >>
> >
> > To me it's out of scope. I want to get the API changes out there and
> signal the potential of major API breakages. Features can be rolled out
> whenever. To me the change in versions is to signal API breakage, not
> feature addition.
> >
> >> Mark
> >>
> >>
> >> Jason van Zyl 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.
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > the course of true love never did run smooth ...
> >
> >  -- Shakespeare
> >
> >
> >
> >
> >
>
>
> On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <jason@tesla.io<javascript:;>>
> wrote:
> >
> > On Mar 3, 2013, at 2:23 PM, Mark Derricutt <mark@talios.com<javascript:;>>
> wrote:
> >
> >> A quick answer whilst I let my thoughts dwell on the full long post..
> >>
> >> If we're jumping to a major release here, is this a viable time to also
> update the schema and address of the things we've long been wanting there?
> ( mixins of some form ) - or is this out of scope ( of this discussion at
> least ).
> >>
> >
> > To me it's out of scope. I want to get the API changes out there and
> signal the potential of major API breakages. Features can be rolled out
> whenever. To me the change in versions is to signal API breakage, not
> feature addition.
> >
> >> Mark
> >>
> >>
> >> Jason van Zyl 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.
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > the course of true love never did run smooth ...
> >
> >  -- Shakespeare
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

Re: The next major release of Maven: 4.0.0

[Benson Margulies <bi...@gmail.com>]

> Well I agree with Semantic Versioning, so the question here that dictates
> 3.2 vs 4.0 is whether we see Sonatype Aether as part of the exposed
> supported API of Maven. IIRC the stated position is that plugin authors are
> not supposed to rely on the Sonatype Aether API. If plugin authors have
> relied on it then they are responsible for ensuring that the plugin works
> in its absence... that would strongly indicate that 3.2 (or 3.1 if at the
> same time as SLF4J) is the correct SemVer version... but if you view the
> Sonatype Aether API as being part of the exposed supported API of Maven (as
> opposed to leaked unsupported API) then 4.0 would be the correct SemVer


What if we published a specific policy that covered this case: something like:

The Maven project is in transition in the area of dependency
resolution. The existing official API is good enough for many
problems, but does not expose enough operations to allow the correct
implementation of a few, important plugins. Therefore, these plugins
are coded directly to 'Sonatype Aether.' The Maven community plans to
make changes to these APIs over the next few releases as we work to
refine an appropriate public API in this area. Since these changes
won't have much user-visible impact, they won't be major versions,
even though they will change this API, and require the few plugins
which touch it to change to track it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: The next major release of Maven: 4.0.0

[Stephen Connolly <st...@gmail.com>]

On 3 March 2013 22:41, Benson Margulies <bi...@gmail.com> wrote:

> As I see it, you are using the version number to communicate with the
> tiny number of people who have made plugins that depend on Aether.
>
> I would rather see us use the version number to communicate with the
> vast number of people who use Maven.
>
> So, I'd switch to Eclipse Aether, including the need to fork a few
> plugins, as 3.2, and use the number 4.0.0 for a version that has real
> user-visible impact and value.
>

Well I agree with Semantic Versioning, so the question here that dictates
3.2 vs 4.0 is whether we see Sonatype Aether as part of the exposed
supported API of Maven. IIRC the stated position is that plugin authors are
not supposed to rely on the Sonatype Aether API. If plugin authors have
relied on it then they are responsible for ensuring that the plugin works
in its absence... that would strongly indicate that 3.2 (or 3.1 if at the
same time as SLF4J) is the correct SemVer version... but if you view the
Sonatype Aether API as being part of the exposed supported API of Maven (as
opposed to leaked unsupported API) then 4.0 would be the correct SemVer

-Stepjen


>
> If you presented a long list of wonderful user-visible improvements
> that would result from the adoption of the new Aether, I'd be happier
> with your proposal.
>
>
> On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
> >
> > On Mar 3, 2013, at 2:23 PM, Mark Derricutt <ma...@talios.com> wrote:
> >
> >> A quick answer whilst I let my thoughts dwell on the full long post..
> >>
> >> If we're jumping to a major release here, is this a viable time to also
> update the schema and address of the things we've long been wanting there?
> ( mixins of some form ) - or is this out of scope ( of this discussion at
> least ).
> >>
> >
> > To me it's out of scope. I want to get the API changes out there and
> signal the potential of major API breakages. Features can be rolled out
> whenever. To me the change in versions is to signal API breakage, not
> feature addition.
> >
> >> Mark
> >>
> >>
> >> Jason van Zyl 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.
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > the course of true love never did run smooth ...
> >
> >  -- Shakespeare
> >
> >
> >
> >
> >
>
>
> On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
> >
> > On Mar 3, 2013, at 2:23 PM, Mark Derricutt <ma...@talios.com> wrote:
> >
> >> A quick answer whilst I let my thoughts dwell on the full long post..
> >>
> >> If we're jumping to a major release here, is this a viable time to also
> update the schema and address of the things we've long been wanting there?
> ( mixins of some form ) - or is this out of scope ( of this discussion at
> least ).
> >>
> >
> > To me it's out of scope. I want to get the API changes out there and
> signal the potential of major API breakages. Features can be rolled out
> whenever. To me the change in versions is to signal API breakage, not
> feature addition.
> >
> >> Mark
> >>
> >>
> >> Jason van Zyl 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.
> >>
> >
> > Thanks,
> >
> > Jason
> >
> > ----------------------------------------------------------
> > Jason van Zyl
> > Founder & CTO, Sonatype
> > Founder,  Apache Maven
> > http://twitter.com/jvanzyl
> > ---------------------------------------------------------
> >
> > the course of true love never did run smooth ...
> >
> >  -- Shakespeare
> >
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: The next major release of Maven: 4.0.0

[Benson Margulies <bi...@gmail.com>]

As I see it, you are using the version number to communicate with the
tiny number of people who have made plugins that depend on Aether.

I would rather see us use the version number to communicate with the
vast number of people who use Maven.

So, I'd switch to Eclipse Aether, including the need to fork a few
plugins, as 3.2, and use the number 4.0.0 for a version that has real
user-visible impact and value.

If you presented a long list of wonderful user-visible improvements
that would result from the adoption of the new Aether, I'd be happier
with your proposal.


On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Mar 3, 2013, at 2:23 PM, Mark Derricutt <ma...@talios.com> wrote:
>
>> A quick answer whilst I let my thoughts dwell on the full long post..
>>
>> If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ).
>>
>
> To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition.
>
>> Mark
>>
>>
>> Jason van Zyl 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.
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> the course of true love never did run smooth ...
>
>  -- Shakespeare
>
>
>
>
>


On Sun, Mar 3, 2013 at 12:08 PM, Jason van Zyl <ja...@tesla.io> wrote:
>
> On Mar 3, 2013, at 2:23 PM, Mark Derricutt <ma...@talios.com> wrote:
>
>> A quick answer whilst I let my thoughts dwell on the full long post..
>>
>> If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ).
>>
>
> To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition.
>
>> Mark
>>
>>
>> Jason van Zyl 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.
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder & CTO, Sonatype
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> the course of true love never did run smooth ...
>
>  -- Shakespeare
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

On Mar 3, 2013, at 2:23 PM, Mark Derricutt <ma...@talios.com> wrote:

> A quick answer whilst I let my thoughts dwell on the full long post..
> 
> If we're jumping to a major release here, is this a viable time to also update the schema and address of the things we've long been wanting there? ( mixins of some form ) - or is this out of scope ( of this discussion at least ).
> 

To me it's out of scope. I want to get the API changes out there and signal the potential of major API breakages. Features can be rolled out whenever. To me the change in versions is to signal API breakage, not feature addition.

> Mark
> 
> 
> Jason van Zyl 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.
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder & CTO, Sonatype
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

the course of true love never did run smooth ...

 -- Shakespeare

Re: The next major release of Maven: 4.0.0

[Mark Derricutt <ma...@talios.com>]

A quick answer whilst I let my thoughts dwell on the full long post..

If we're jumping to a major release here, is this a viable time to also 
update the schema and address of the things we've long been wanting 
there? ( mixins of some form ) - or is this out of scope ( of this 
discussion at least ).

Mark


Jason van Zyl 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.

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

On Mar 3, 2013, at 2:43 PM, Stuart McCulloch <mc...@gmail.com> wrote:

> On 3 Mar 2013, at 14:16, Jason van Zyl 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.
> 
> Apart from the "org.sonatype.aether" -> "org.eclipse.aether" package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code.
> 

I'll collect them with Benjamin, as I'm not sure how good any standard API diffing tool is going to work with all the package changes.

>> 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.
>> 
>> 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. 
> 
> Speaking personally, one concern I have is that there will no doubt be other major features people want to get into 4.0.0 (because of the major version shift) and this could all take a while to plan, stabilize, and release -

I don't really want to add anything beyond JSR330, SLF4J and Eclipse Aether. The frequency of change in the core for new features basically ground to a halt. I really don't think this behaviour is going to change radically so I don't see much point in waiting for anything beyond agreement to get a 4.0.0 out the door.

> meanwhile there could be minor fixes and features stuck in limbo that would benefit people. So while I think it's a good idea to plan for 4.0.0 I'm not sure that should prevent anyone planning a 3.0.x or 3.1.x release.

If someone wants to do a 3.1.x that's fine with me but I think having two major branches will just get out of sync. I'm personally in favour of getting a 4.0.0 as fast as possible because the ITs still pass and the few plugins that seem to have issue can be fixed pretty quickly. I just don't think the bandwidth exists to maintain two major branches. Sonatype Aether isn't going to get any love and syncing the branches across package changes probably won't be much fun. We would probably also have to deal with multiple branches across the plugins that will be affected. I proposed what I'm willing to maintain and I think that's ultimately going to be the easiest for us to maintain.


> 
> PS. I see that Maven trunk currently exports "org.sonatype.inject" from the core realm - this package is not required for the JSR330 support, only if you want to use some of the additional Sisu behaviour such as eager singletons. If you happen to know which classes or annotations you want to use (or are using) from this package then I can make sure that they will also be supported in Eclipse/Sisu. It only contains a small handful of interfaces and annotations so this really isn't much work. Otherwise if you don't use anything from "org.sonatype.inject" then I suggest this package is removed from the export list for the moment.
> 

Ok, I'll take a look.

> --
> Cheers, Stuart
> 
>> 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.
>> 
>> 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. 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.
>> 
>> 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, JSR330 is standard and Eclipse Aether post 1.0.0 will adhere to the Eclipse API guidelines and won't be changing so it's best just to build on these technologies of any new versions of Maven and get on with it.
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------

To do two things at once is to do neither.
 
 -- Publilius Syrus, Roman slave, first century B.C.

Re: The next major release of Maven: 4.0.0

[Jason van Zyl <ja...@tesla.io>]

On Mar 3, 2013, at 2:43 PM, Stuart McCulloch <mc...@gmail.com> wrote:

> On 3 Mar 2013, at 14:16, Jason van Zyl 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.
> 
> Apart from the "org.sonatype.aether" -> "org.eclipse.aether" package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code.
> 

Here you go: http://wiki.eclipse.org/Aether/New_and_Noteworthy

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

[Stuart McCulloch <mc...@gmail.com>]

On 3 Mar 2013, at 14:16, Jason van Zyl 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.

Apart from the "org.sonatype.aether" -> "org.eclipse.aether" package rename, is there an overview of the client-facing changes? (or perhaps a jdiff report?) There are various other Aether users who'll also need to know how to upgrade, so if this information isn't captured somewhere then it's worth putting it on the Eclipse wiki. Even if it's not possible to bridge between the old and new APIs then this information will help people migrate their existing code.

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

Speaking personally, one concern I have is that there will no doubt be other major features people want to get into 4.0.0 (because of the major version shift) and this could all take a while to plan, stabilize, and release - meanwhile there could be minor fixes and features stuck in limbo that would benefit people. So while I think it's a good idea to plan for 4.0.0 I'm not sure that should prevent anyone planning a 3.0.x or 3.1.x release.

PS. I see that Maven trunk currently exports "org.sonatype.inject" from the core realm - this package is not required for the JSR330 support, only if you want to use some of the additional Sisu behaviour such as eager singletons. If you happen to know which classes or annotations you want to use (or are using) from this package then I can make sure that they will also be supported in Eclipse/Sisu. It only contains a small handful of interfaces and annotations so this really isn't much work. Otherwise if you don't use anything from "org.sonatype.inject" then I suggest this package is removed from the export list for the moment.

--
Cheers, Stuart

> 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.
> 
> 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. 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.
> 
> 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, JSR330 is standard and Eclipse Aether post 1.0.0 will adhere to the Eclipse API guidelines and won't be changing so it's best just to build on these technologies of any new versions of Maven and get on with it.
> 
> 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
> 
> 
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org