maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manfred Moser" <manf...@mosabuam.com>
Subject Re: The next major release of Maven: 4.0.0
Date Mon, 11 Mar 2013 17:28:24 GMT
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 <anders@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
>> <mfriedenhagen@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" <brianf@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 <jason@tesla.io> wrote:
>>>>
>>>>>
>>>>> On Mar 6, 2013, at 6:09 PM, Olivier Lamy <olamy@apache.org> wrote:
>>>>>
>>>>>> 2013/3/4 Hervé BOUTEMY <herve.boutemy@free.fr>:
>>>>>>> some more personal thoughts and questions to make myself an opinion
>>>>>>>
>>>>>>> - about determining whether Aether API is biased or not: there
was
>>> an
>>>>> argument
>>>>>>> for not developing Aether in Maven that was "Aether API will
be
>>>>>>> more
>>>>> generic
>>>>>>> to cover other dependency resolution mecanisms and repository
>>> formats,
>>>>> like
>>>>>>> P2". Is there something done on this area (be it P2 or anyhting
>>>>>>> else
>>>>> outside
>>>>>>> Maven use)?
>>>>>>>
>>>>>>> - about maintaining a 3.1.0 bugfix branch like the actual one
in
>>>>> parallel with
>>>>>>> the master incorporating Eclipse Aether: isn't it the area where
>>>>>>> the
>>>>> git move
>>>>>>> was expected to help? The 3.1.0 is just a bugfix branch, without
>>> much
>>>>> commits
>>>>>>> expected since the work will happen on master (and on every
>>>>> components/plugins
>>>>>>> having an impact from Eclipse Aether integration), or do I miss
>>>>> something?
>>>>>>> I suppose these outside component will require some time to adapt
>>> and
>>>>> propose
>>>>>>> a solution for users.
>>>>>>
>>>>>> In such case why not using the opportunity of 4.0.0 to back to a
>>>>>> org.apache.maven namespace (with a wrapper on top of the real
>>>>>> implementation).
>>>>>
>>>>> Go for it. As I wrote previously if anyone wants to make a shim or
>>>>> compatibility layer over Eclipse Aether they are welcome too. I'm not
>>>> doing
>>>>> for all the reasons I cited previously, but feel free to take the
>>>>> opportunity.
>>>>>
>>>>>> At least that will be a more stable namespace. (If did as it since
>>> the
>>>>>> beginning we could think about something else now !)
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Hervé
>>>>>>>
>>>>>>> Le dimanche 3 mars 2013 19:24:23 Jason van Zyl a écrit :
>>>>>>>> Stephen,
>>>>>>>>
>>>>>>>> It doesn't matter where the code is. It's complicated, takes
a lot
>>> of
>>>>> effort
>>>>>>>> to understand and I don't really care, or see it as a problem
that
>>>>> Benjamin
>>>>>>>> is the one who works on it most. No one else worked on here,
no
>>>>>>>> one
>>>>> else is
>>>>>>>> working on it there. It's not where it is, it's that it's
a
>>>> non-trivial
>>>>>>>> body of code that requires focus and effort that any casual
>>> observer
>>>>>>>> doesn't have the time for. The only people who have ever
worked on
>>> it
>>>>> are
>>>>>>>> those that were employed to work on it specifically. I don't
see
>>> this
>>>>> as an
>>>>>>>> issue, it's simply the way it is.
>>>>>>>>
>>>>>>>> Aether is already exposed and it's because the Maven Artifact
APIs
>>>> are
>>>>>>>> anemic that it's used directly. Aether is complete, anything
else
>>>> made
>>>>> is
>>>>>>>> just going to make a huge wrapper around that which serves
no
>>> purpose
>>>>>>>> really. If in the 18 months since Aether has been at Eclipse
>>> nothing
>>>>> has
>>>>>>>> been done do you really think anything can be made in a timely
>>>>> fashion? I
>>>>>>>> think that unlikely. There's probably 1000 man hours in Aether
at
>>>>> least and
>>>>>>>> there's probably lots of biases in the codebase because no
one
>>>>> contributes
>>>>>>>> anything to it for all the reasons cited above. Such is the
>>>>>>>> reality
>>>> we
>>>>> have
>>>>>>>> right now.
>>>>>>>>
>>>>>>>> Until I actually merged in Eclipse Aether, worked with Benjamin
to
>>>> get
>>>>> all
>>>>>>>> the ITs working, and testing it in the field with 10 or so
people
>>>>>>>> I
>>>>> didn't
>>>>>>>> know how much work was involved, or what plugins were affected
>>> until
>>>> I
>>>>>>>> started getting feedback. I am not interested in weaving
stuff
>>>>>>>> back
>>>> and
>>>>>>>> forth between the branches given that all the ITs work with
>>>>>>>> Eclipse
>>>>> Aether
>>>>>>>> merged in and there are a few plugin compatibility issues.
>>>>>>>>
>>>>>>>> I myself cannot imagine trying to keep the two of those branches
>>>>>>>> in
>>>>> sync and
>>>>>>>> I don't see the point because the Eclipse Aether stuff is
ready. I
>>>>> have the
>>>>>>>> energy to maintain what I proposed. Even if someone wanted
to
>>>>>>>> stand
>>>> up
>>>>> and
>>>>>>>> maintain the 3.1.x branch I believe it would be a waste of
time
>>> given
>>>>> what
>>>>>>>> little time the core receives.
>>>>>>>> On Mar 3, 2013, at 5:54 PM, Stephen Connolly
>>>>>>> <stephen.alan.connolly@gmail.com> wrote:
>>>>>>>>> On 3 March 2013 14:16, Jason van Zyl <jason@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


Mime
View raw message