At the very least, someone should file a Jira asking for a commons-test site.
Ralph 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 <phil.ste...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
