commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: We will not be able to update our websites...
Date Tue, 11 Dec 2012 06:14:02 GMT
On 12/10/12 5:10 PM, Ralph Goers wrote:
> 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.

I get it now.  In practice, with maven sites, is this a big deal?  I
don't remember seeing lots of cruft accumulating on p.a.o, which
would happen if this were common.  If it is not that common, then
manual svn rm's would not be that onerous.

>> 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
> Ralph

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

View raw message