maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/
Date Sat, 27 Jul 2013 01:45:18 GMT

On 26/07/2013 11:35 AM, Baptiste MATHUS wrote:
> Le 25 juil. 2013 23:05, "Stephen Connolly" <>
> a écrit :
>> Perhaps we could reframe the question a little then (as people seem to be
>> testing hung up on the committed wording)...
>> Should the PMC encourage people experimenting on new improvements to Maven
>> to do that work at the ASF?
> Sure. I don't see how one could disagree with the statement.

Encourage or force! Big difference.

Sometimes groupthink does not reach the best conclusion and an 
individual effort may be required to move the state of the art.
OTOH, the majority should not be held up by a person with ideas that the 
majority does not want to pursue. Both sides can benefit from a fork.

>> And if so, should they then practice what they
>> preach, and ensure that any experiments with Maven take place on the ASF
>> SCM servers (at least once such experiments become semi-serious or
> progress
>> enough not to cause egg-on-face syndrome)?
> Re-reading it with *PMC member* in mind, it also makes sense.
> The difficulty is actually defining what is semi-serious, but anyway not
> sure I'd see the goal for a *pmc member* to commit his WIP outside the asf.
> Sure there's github's facilities to help contribution but there's already
> an automatic asf->github mirroring, right?
>> Shoud the PMC promote other Apache projects, or moving non-Apache projects
>> to Apache? (Right now, to work on an issue in core and effect the change
>> yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
>> Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
>> fine with half of these at Eclipse and the ther half here... Or maybe
>> not... But that is a lot of projects where you need to establish merit and
>> perhaps maintain merit just to be able to commit directly (which sometimes
>> is the only way to effect the type of cross system changes that some of
> our
>> more obscure bugs may require... GIT makes this less of a requirement, as
>> patches on SVN are a PITA, though) )
> Not sure how this one could get handled in practice. I suppose this is
> better to try and keep them at Apache, but using a myriad of different libs
> is a reality in a majority if not all java projects.
> To handle code issues, I think this might suffice to check the license
> allows a local versions be used (as Jenkins does) to be sure Maven does not
> get stuck because of one of those deps.
> I think apache projects should be preferred when there's a real equivalence
> between two choices. But again defining/agreeing on this can be hard. On
> the log4j2/logback side for example, even if I personally use logback on a
> daily-basis I'd understand log4j2 be chosen as a default provider because
> it's a apache project and the equivalence seems to be more and more a
> reality.
As a consumer of Apache products, I certainly appreciate the importance 
of reducing the number of licenses schemes in a dependency.
This means that I would prefer log4j over a marginally better logging 
framework that came with another license even if the terms of the 
license are acceptable.
I simply prefer to work with a license that I already have invested time 
in understanding and trust rather than a license that I have to research.


> Cheers
> -- Baptiste

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message