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 22:07:25 GMT
On Fri, Dec 14, 2012 at 03:52:17PM -0600, Matt Benson wrote:
> 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.

If I interpret correctly what I see, the "logging" site has both: The
top-level site is "powered by Twitter Bootstrap" while the "components" are
"built by maven".
That looks like a nice starting point. I.e. we should have the top-level web
CMS-site set up to replace the "Commons" homepage, and every "sub-sites"
button would point to the corresponding legacy site (until the components'
sites themselves are ready).


Gilles

> 
> 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
> >
> >

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


Mime
View raw message