commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <>
Subject Re: Commons, Maven, Site, Release
Date Thu, 22 Dec 2005 22:32:47 GMT
Brett Porter wrote:
> 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.
> 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.

I'm certainly interested. Let me know where I can lend a helping hand.

Dennis Lundberg

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

View raw message