I've been talking to Joe S. on #asfinfra about this; rather than using a test site infra would prefer we request the CMS site, just not exposed to commons.a.o until we're satisfied with it. Do we want to use the CMS a la Apache Logging, or do we want to explore keeping the main site Maven-generated? The Maven guys, particularly Olivier Lamy (do you follow Commons MLs?) may be able to help us if we want to go that way. Actually Maven still seems to be using the CMS at some level [1], so I guess we can just request the CMS site and go from there. Issue created. [2]
Matt [1] http://maventest.apache.org [2] https://issues.apache.org/jira/browse/INFRA-5657 On Wed, Dec 12, 2012 at 4:30 PM, Ralph Goers <ralph.go...@dslextreme.com>wrote: > 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 > >
