commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
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 <phil.steitz@gmail.com> 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/commons.apache.org
>>> 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 http://wiki.apache.org/logging/ManagingTheWebSite
>
> Ralph


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message