commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: We will not be able to update our websites...
Date Fri, 14 Dec 2012 21:52:17 GMT
I've just added the directory to our svn tree so that there would be
someplace at which to point it.  I think the next step is to determine
whether we want a "normal" CMS site like Logging has, in which case we
could prop something up with e.g. Twitter bootstrap as is becoming quite
popular among ASF TLPs.  If we like to keep a Maven-generated look, we'd
probably be best advised to consult the Maven folks on how they're doing
this.

Matt


On Fri, Dec 14, 2012 at 3:40 PM, Gilles Sadowski <
gilles@harfang.homelinux.org> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message