commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: We will not be able to update our websites...
Date Tue, 11 Dec 2012 01:10:50 GMT

On Dec 10, 2012, at 4:12 PM, sebb wrote:

> On 10 December 2012 21:53, Phil Steitz <> wrote:
>> On 12/10/12 1:27 PM, Ralph Goers wrote:
>>> Yes, I think you are missing something fundamental.
>>> If you check in "the whole mess" you will never again be able to properly build
a sub-project's site with Maven.  This is because the process of updating the site would require
first doing a diff and then deleting items that are not included in the new version. Someone
created a Maven plugin to try to do this but it is not the way I would want to go at all.
>> Sorry, I don't get it.  Why won't the following work:
>> 0) Grab all of, say p.a.o/www/
>> 1) check all of that into an svn repo
>> 2) when I want to update, say, math, I generate the content locally,
>> copy it to the /math subtree and check it in.
> There would need to be some extra work done to ensure that stale files
> are deleted.
> For some projects, it would be possible to just delete the existing
> sub-tree and check the whole new site in.
> [This can be done as one transaction in svnmucc]
> However, for sites that retain Javadoc etc. for older releases, one
> would need to re-instate that part of the tree somehow.
> Given that svnpubsub immediately publishes what is checked in, it
> might be sensible to have a parallel staging directory tree where
> files can be updated piecemeal if necessary, and then use svnmucc to
> replace the live component subtree with the staging component subtree
> as part of a single transaction.
> There would need to be some co-ordination between committers when
> updating commons parent, as that would affect the whole tree.

Yes. This is why Logging used the extpath approach where each subproject commits directly
to production. Each release goes to a release subdirectory under each subproject's directory.
 Then you can just perform your maven site build to a local directory, copy that into the
production svn location, and commit it.

See "Managing the subproject sites" at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message