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 Wed, 12 Dec 2012 22:30:54 GMT
At the very least, someone should file a Jira asking for a commons-test site.


On Dec 10, 2012, at 10:14 PM, Phil Steitz wrote:

> 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.
> Phil
>>> 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:

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

View raw message