commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [all] Maven, help or hinderance?
Date Sun, 11 Dec 2005 14:42:44 GMT
On Sun, 2005-12-04 at 17:34 +1100, Brett Porter wrote:
> :)
> Phil Steitz wrote:
> > On 12/3/05, Stephen Colebourne <> wrote:
> >>  >>Hate to be an "old fart" here but was ant really all that bad?

ant's very good

the problem is standardisation: it's a PITA to have to change the build
scripts for lots of simple components.

> I had to laugh seeing this topic crop up. The problems were with site
> generation, as mentioned in another thread - something that wouldn't
> exist in Ant without another tool that would likely come with its own
> set of problems.


the real question is: can we work more productively with maven in the
future than by switching to some other platform. IMHO this comes down to
communities. i don't think that we can go forward with the same
relationship that we've had in the past but there seems to be enough
good will (on both sides) to give it a chance.  

IMO the critical issues are releases and the site. look's like hen's on
top of the site issue but i'd like to pick up on the releases issue.

i've never been happy with the maven dist and try to avoid using it. the
commons has ended up with lots of shared customization. this is now
getting too much. ensuring that commons releases are up to the required
standard is taking far too much energy. i think that this needs to
change: we need a new strategy. we need to invest time in automation to
save time later and maven is a good match for this problem.

we're increasingly finding that we have quite exacting requirements for
both the site and (especially) for releases. these requirements are
becoming less and less negotiable. 

in theory, it would be better to work by feeding back our requirements
into maven. in practise, this hasn't been all that effective so far. i
suppose that the question is whether the maven community would be
willing to accept patches to allow dist to do what we need it to do or
whether it would make more sense for a jakarta-dist to be created. we're
also likely to need quick release cycles or ask that people build from
source and install locally.


> > I would not recommend a wholesale move to maven 2 at this time, as the
> > plugins are still getting completed and I am afraid the frustration
> > level would actually get worse if we started going there immediately. 
> > I think that if we solve a few simple problems with maven 1 and update
> > the docs, we can make things easy enough for RMs and volunteers both.
> I think the main reason not to move to Maven 2 yet is that it would
> fragment commons, which would be an issue. At the least there should be
> parallel builds.

could you expand on this a little?
> > At apachecon, Brett and I are going to work on finding a better way to
> > share navigation structures across sites.  The current XML entities
> > approach is going to break in maven 1.1 and is also a bit confusing. 
> > All are welcome to join us, or obviously to post ideas on how to do
> > this.


at the time, entities seemed like a quick and cheap way of achieving our
goals. maven was in flux and it would have been a big political and
personal commitment to change maven to meet our goals.

but times change and the time seems right to adopt a more permanent
solution. we're probably also at the stage where we're going to need to
be a bit more prescriptive so that the process can be documented and
disseminated more easily.

> Indeed. I was actually going to discuss with relation to Maven 2.0,
> though, as its a much better platform for achieving the goals. I was
> already thinking I'd use commons as the test platform for multiproject
> site support. Hopefully this will also give me the chance to inject some
> effort into site-dev.
> As for nightly builds and site publishing - I'm more than happy to drop
> any commons builds that don't extend commons-build into continuum on our
> zone and publish jars and/or sites, and grant access to people who are
> interested in working with it. I hadn't extended that offer yet as I'm
> still waiting on an official answer on the permanency of the zone setup
> - but I think that AC will see that come to pass too.

i've been wondering recently whether it's time to use svn:external to
copy the directories required. would this change be helpful? 

- robert

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

View raw message