robert burrell donkin wrote:
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.
I totally agree. The Maven2 assembly plugin allows simpler customisation
of the distribution goals, and the other manual steps like signing the
release are being addressed (see commons-openpgp).
I'm happy to use commons as a test case for both site and release
improvements.
in theory, it would be better to work by feeding back our requirements
into maven.
+1
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?
I just expected that people would not like to have different ways to
build different components, so introducing parallel builds might be the
best way to start introducing m2. But as far as what commons needs,
Maven 2 should cover more than what m1 does now.
i've been wondering recently whether it's time to use svn:external to
copy the directories required. would this change be helpful?
Maven 2 has solved the inheritence problem by using the repository as an
intermediatary, while still being able to discover local changes without
having to constantly publish there.
I'm not inclined to make svn:externals essential for anything. Its a
great convenience, but I think too limited for that sort of use.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
