Brett Porter wrote:
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.
+1
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.
+1
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.
+1 for more separation. This is the way is has always supposed to be.
4) Split all other plugins into two groups: production and pre-release
(both in SVN and on the site)
Currently the plugins list is separated into a "Released Plugins" list
and a "Sandboxed Plugins" list. What do you want to change here? Two
separate pages?
I wouldn't mind moving the most popular plugins to a separate page. From
the dev and user lists you can clearly see which plugins are the most
popular.
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.
So you want to a difference between sandbox and 1.0 too? Where pre 1.0
is pre-release? Might be useful.
iii) anything without a docck compliant site is pre-release.
+1
iv) every project in either group must have a JIRA project, with a
complete set of versions
If you by groups mean anything that has done a "dev" release (alpha,
beta, ...) and "full" releases (1.0, ...).
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.
Javadoc requirements for any objects used as arguments might be a useful
requirement. Makes it easier for the documentation to point to the
(probably) most up to date source of information, the Java code.
5) Anything with submodules should have it's own group Id (including the
plugin)
+1, but perhaps all plugins should have its own group id to make stuff
clearer? I clearly see that a whole lot of the plugins should be split
up to make them easier to re-use in an IDE context for example.
So, I'm happy to start working on this (consider it my Christmas present
to you all :D) - are there any objections?
You said on IRC that you had done something similar with Archiva's site.
How do they relate to the kind of changes you are proposing there?
--
Trygve
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
