Hi, I've been tracking a lot of the discussion on commons-dev and there are lots of points to reply to, so I thought it was appropriate that I do a brain dump to get everything up to date. Apologies for length.
First, it seems clear that Maven 2 is a better choice to use than to do significant work on Maven 1.x. A lot of things have been proposed for a Maven 1.x plugin for commons that are already possible out of the box in Maven 2. There are some gotchas. - Some plugins may not be available. At this point, I am not aware of anywhere that this is the case in Commons, but I will do a check over this shortly and report back. - Some services are not yet available. Specifically I am thinking of Gump and the automated repository sync. I am working with Leo on the gump stuff, and I think it will be all ready by the time Gump 3 is done. there is always the ability to generate a reasonable ant build script to use here. The repository sync will be available early in the new year and is much improved. - It's a change, and any change is disruptive. I had planned to get everything working at least to the level it already does in M1 for some sandbox components before even bringing it up, so this thread was rather timely. Now, some specific thoughts on what is needed. Inheritence - I believe the common parent is a good way to go, and Maven 2 facilitates this by allowing it to be in the repository, avoiding a bizarre checkout structure. This should avoid the need for externals that has been under discussion. I am currently working on site inheritence. The descriptor goes in the repository, facilitating the same as above. I am adding breadcrumbs, top/bottom navigation inheritence (to prevent the need for the entities used previously), skins (css + images in a jar that can be shared among projects), and documenting/facilitating best practices about separation of different releases and separating developer information from user information. If the site layout + CSS is still not good enough, a single velocity template should be able to be added to the skin as well. While on the site, most people love the APT format in Maven 2, which is a definite advantage of using that. Some might want to look into the i18n aspects as well. http://docs.codehaus.org/display/MAVEN/Sites+and+Inheritence Unfortunately this didn't land during the hackathon as I had hoped, but I'll get it together very soon. Plugin versions - Maven 2 always treats plugins as dependencies. It has discovery for versions and by prefix to reduce the burden during development, but you can always enforce a particular version (or range of versions) from the POM, and the release plugin locks it in to make builds reproducible. Custom plugin - should be easy to write on of these and tie it into the Maven 2 lifecycle for annotating JARs with extra information. We will also accept bug reports and patches as mentioned to the core plugins where it might make more sense to adopt the same practices in general. Distributions - this is customisable by a descriptor in Maven 2, so a shared commons descriptor might be appropriate here. I actually think the defaults can work for what commons distributes now. If individual commons components need to use a different descriptor they can always override it - no messy hacking on the goals. Releases - this is all being captured in the shopping list on the wiki. A lot of this is above and beyond what anything does right now so may be a little bit more towards the long term, but all seems achievable under the Maven 2 framework. Converting POMs - while we do have a tool to help, I would never recommend doing this blind as there are a lot of simplifications that can be made to dependencies and inheritence along the way. The commons poms are actually quite simple and should just end up as a set of dependencies and basic information with most inherited so I don't see this being a big issue. I hope that covers everything. Sorry I hadn't done more on this earlier, but if folks are interested in contributing to this effort through more requirements or even some code, please let me know and we can start some discussion on the maven dev list for the parts relevant there. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
