commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <gil...@harfang.homelinux.org>
Subject Re: We will not be able to update our websites...
Date Fri, 14 Dec 2012 21:40:54 GMT
Hi.

On Fri, Dec 14, 2012 at 03:12:31PM -0600, Matt Benson wrote:
> 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]

Is the new (empty, I guess) cms-web site accessible?

Regards,
Gilles

> 
> 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.goers@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.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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >

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


Mime
View raw message