On 7/17/11 12:08 PM, Benson Margulies wrote:
I think you are going to have to. Mark isn't the only one who has expressed the
sentiment. Some of the discussions I've seen on changing the relationship Maven
has with repository managers would surely require changes at the Aether layer.
I don't follow your last sentence. I just submitted a patch to Aether,
and it was cordially received, but there is, of course, no guarantee.
This thread started out as a discussion of licensing, not control. If
Sonatype put the dual license back today, there would be no vote
required to update to a new version of Aether, and mods to Aether
would still require cooperation with Sonatype.
So, I can imagine a thread of discussion about forking Aether (or
anything else) to achieve control, but that's not this thread.
My primary view in opposition to forking is the this:
Sonatype and the Maven PMC share an interest in the success of Maven.
The current situation isn't ideal, but it could be a whole lot worse.
Based on recent history, I don't personally believe that dramatic
tactics are the best option to achieve cooperation here. Forking
would, in my opinion, come in under the category of 'a dramatic
tactic.'
My secondary argument has to do with workload. This development
community is trying to maintain a giant raft of stuff. Deciding to
fork these components without any visible plan to find the effort to
work on them would be, in my opinion, 'shooting ourselves in the
feet'. I might go so far as to ask people proposing a fork to list
their recent commits to core Maven code.
Another way to put this:
If there is a majority of PMC members willing to vote +1 to just
accept Aether as EPL (which means more work if relations with Sonatype
degenerate and we wish to disentangle), let's do that.
If there isn't, then the next step in my view is to talk to Sonatype
about the dual license.
I personally thing that it is nuts to fork without talking to Sonatype first.
I understand where you're coming from WRT workload, but if you haven't
learned something from recent history in terms of exporting control of
this project, I'd suggest you re-read whatever archives you have access
to. If you need details, I can provide them.
If we switch to the EPL-only version of Aether, we lose our ability to
innovate in how Maven resolves artifacts...or, at least, we lose our
ability to do this without the approval of the Aether folks. Normally,
that may not be a bad thing, having an alliance with another project.
But this is central to what Maven does...it's not just some plugin or
supplemental protocol.
I've hacked into the way Aether works - a little bit - to get the
mirror-group-routing branch of maven3 to work
(http://svn.apache.org/repos/asf/maven/maven-3/branches/mirror-group-routing/).
This branch is meant to allow more flexible routing of mirrors and
groupId-URLs. Anyway, I've had to hack into Aether to get this running,
and it's not been fun.
All of my work there was done in a way such that it would work without
requiring an Aether patch, since I assumed that the Aether community
wouldn't find a lot of value in my work. IMO, there's not much that we
could do regarding the way Aether resolves artifacts without requiring a
fork anyway.
If we want to incorporate future Aether versions in Maven, I'm -1 unless
Aether changes back to dual licensing, or we fork Aether into Maven and
re-streamline the consolidated codebase.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
