On Sun, 2005-12-04 at 17:34 +1100, Brett Porter wrote: > :) > > Phil Steitz wrote: > > On 12/3/05, Stephen Colebourne <[EMAIL PROTECTED]> 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. +1 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. opinions? > > 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. +1 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
