Kenney Westerhof wrote:
On Tue, 1 Nov 2005, Brett Porter wrote:
+0.
I believe these projects are not technically maven related, and hence do
not require to be in the m2 repository.
There is a distinction between Maven the build tool and Maven the Apache
project. Both tools fall within the mission statement of the project, in
the same was as Maven SCM, Wagon, JXR and Continuum are.
Eric explained it perfectly:
> Having some set of code that Maven uses over on Codehaus, when it is
> all developed by Maven committers and tightly intertwined seems odd.
>
> If there isn't a good licensing reason/access reason like what
> prompted maven-plugins.sf.net to be created, then I'd like to see it
> all stay on the Apache infrastructure. Basically it feels to me like
> Maven should be either an Apache project, and done there, or a
> Codehaus project and done there, versus straddling the two.
Kenney continued:
It would be the same as moving
classworlds to maven2, except we know classworlds is also used by other
projects.
Possbily - there is no reason that if it was here, that other projects
couldn't use it. It's not beyond Maven's scope to provide reusable
libraries for other projects. For example, there has been talk of
collaborating with Cruise Control to beef up and reuse Maven SCM.
However, as you say, classworlds is used elsewhere. We don't need to
absorb everything that is capably looked after elsewhere :)
To promote usage of these components without requiring maven2 I
believe it's best to leave them on a separate repository. This also
reduces 'hacking' those projects to create special maven2 shortcuts.
The latter requires some discipline, but I can assure you the current
situation doesn't change that one bit :)
This is not just about source code repositories. The fact that these are
closely related to Maven but not found here is a barrier to entry. One
of the mantras at Apache is that community is more important than code
(if I get hit by a bus tomorrow, I hope you all mourn me but are still
able to continue on).
Also when people are using it in mojo projects (especially doxia, when the
site plugin is moved to mojo someday, as I believe are the plans),
it will be harder to give them commit access if these libs are hosted at
apache.
Ok, this is disappointing to read, as we obviously have created some
confusion here, so I'll discuss this at greater length.
Firstly, there is no way the site plugin should be moved to the mojo
project, IMO. I'm not sure where that impression came from - but I'd
like to hear more so that we can avoid spreading that misconception in
the future.
Secondly, easier granting of commit access is not the way we want to
operate with core pieces of functionality. People should have to earn
their stripes. The time from decision to access at Apache is generally
less than 4 weeks (I know you had a particularly bad experience, but it
seems to have improved). I think anyone that can't hang around that long
and submit patches is probably not going to stick around through any
other minor issues either, so it doesn't greatly concern me.
We need to work a lot more on creating a lower barrier to participation,
but that is not the same as a low barrier to commit access. The work on
the documentation and the getting started in contributing guides in
particular are helpful, but simply documenting more of the code and
design would be even better.
Now, to elaborate more on how I view the mojo.codehaus.org project.
There are two reasons it is used:
a) house plugins that can not be distributed from Apache. This is for
things that have dependencies on, for example, LGPL code that Apache
doesn't distribute for a variety of reasons beyond the scope of this
email. This is similar to the maven-plugins.sf.net project that has
Maven 1.x plugins, but the Codehaus infrastructure is nicer to work with.
b) Satellite plugins. I struggle to find the right term for this - but
this could be where the "easier to grant commit" argument mistakenly
comes from. In Maven 1.x we had a problem with a lot of people
contributing a useful plugin that would be reasonably complete and then
disappear. They never got invested enough in the project as a whole to
become committers, and the rest of us got left with unattended plugins
that tended to rot without support. So, the strategy here is to allow
people to bring plugins in to the sandbox at mojo.codehaus.org, and work
on it to make it release quality, and let them rule their own domain a
little bit there. But, at the same time, I hope that we can operate that
community in the same way as the Apache community, and if people start
to participate across plugins or parts of the code that they will join
the Maven community.
I'd like (b) not to be necessary - like Ant tasks, the plugins should
originate from the tools themselves reducing the number of plugins at
mojo.codehaus.org to just the different licenses. Most users should be
able to get by with just what's at Apache.
This isn't exactly how its gone to date, and I hope we can work to
correct this moving forward.
Thanks for the feedback - I hope this is helpful!
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
