Hi,
I think Mojo is in need of another clean up. I know some stuff
has been
done (particularly with docs), and it has been improving - but I
have a
few more suggestions that might help with the problems I
experienced as
a user coming in yesterday.
I was in the position of kind of knowing that what I needed was
here,
but wasn't able to find it on the site... then once I found it's
site it
didn't really instruct me what to do. So now I'm doing the open
source
thing and looking to patch it up and though it's had releases, it
doesn't have it's own JIRA project and there are quite a number
of open
issues for it in the group project. As a contributor I'm faced with
either a lot of work or a high risk of my issue getting lost in the
noise. I think this story might apply to a number of plugins -
and it
drags the reputation of Mojo as a whole down, despite the fact that
there's definitely some gold in here.
I think we need to recognise Mojo as a collective rather than a
project
- and each plugin is basically independent. Each should make or
break
itself based on its own quality without affecting the perception
of the
collective as a whole. Mojo should offer the facilities to make
it easy
to fit in, but not try and tie everything together.
So, here's what I propose:
1) give every released plugin it's own trunk, and separate the
parent
POM (much like Maven's parent POM).
We can still have externals to pull down everything, but I think
we have
no need for a "build everything" POM in general use (we can still
add
one as a convenience, but it would not be the parent of the
mojos). This
recognises each plugin has it's own development cycle and can be
more
easily tracked.
2) Make a separate module for the site
This will not have releases, as it's just the website (and we may
wish
to switch to using confluence export?). It houses living
documents about
the project and links to / info about the various plugins.
3) create a separate sandbox with no tags/branches/trunk
This is a collection of plugins that have just been started and
never
released. This will be what the generic MOJO JIRA project will be
used
for (component per plugin, as now - but no releases so no
versions).
Plugins can have a site under /sandbox/plugin-name.
4) Split all other plugins into two groups: production and pre-
release
(both in SVN and on the site)
I see this as key in the clean up - basically where we change the
perception by making the high quality stuff the most visible, and
set
the right expectations on the rest.
Here are the criteria I envisage:
i) anything that is not yet consistently licensed is pre-release
(there
a number of plugins suffering from this - such as those marked
with the
ASF's header by accident). Mojo only has a license type
preference, not
a restriction (other than it must be open source, as Codehaus
dictates)
- but it does have to be properly licensed under the one it has
chosen.
ii) anything with an alpha, beta, gamma, omega or RC in the
version is
pre-release. I'm not sure what to do with something that is
currently
production and then goes into a pre-release cycle on trunk -
maybe it
would be displayed separately in the two sections of the site. But
anything that has not yet reached final can not be in the
production area.
iii) anything without a docck compliant site is pre-release.
iv) every project in either group must have a JIRA project, with a
complete set of versions
We may even want to increase this criteria in future to encompass
certain quality levels like javadoc and test coverage - but I
think the
above is a good start.
5) Anything with submodules should have it's own group Id
(including the
plugin)
So, I'm happy to start working on this (consider it my Christmas
present
to you all :D) - are there any objections?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
