Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of gudnabrsam@gmail.com designates
 209.85.212.43 as permitted sender)
MIME-Version: 1.0
Reply-To: gudnabrsam@gmail.com
In-Reply-To: <20121214220725.GH20488@dusk.harfang.homelinux.org>
References: 
 <CAE9L6G28XspybPGWDrEvQp5Aszum5fu4xKpPw36zXz_Ui0Ffuw@mail.gmail.com>
	<CFA6D1CF-926B-48A8-B152-551053D2EF11@dslextreme.com>
	<50C659E6.7000802@gmail.com>
	<CAOGo0VaX1Tm5GW=NzGk5gSWQLTE0M2ZG1OCDDQm8OfMer+S6CA@mail.gmail.com>
	<ED7F5960-123F-48A5-BBA1-84099574D450@dslextreme.com>
	<50C6CF2A.7070308@gmail.com>
	<21A6010E-0FE8-45A1-8F46-AED897650031@dslextreme.com>
	<CAE9L6G2eeYa0v-86gL-XAxVpWhFJo-SJHrZeAtqveRTDE=kDAQ@mail.gmail.com>
	<20121214214054.GF20488@dusk.harfang.homelinux.org>
	<CAE9L6G0DxhweWVaDkkRUdJ_mNAp+oAtC9k_9xT+J4MFXKtUT3w@mail.gmail.com>
	<20121214220725.GH20488@dusk.harfang.homelinux.org>
Date: Fri, 14 Dec 2012 16:35:07 -0600
Message-ID: 
 <CAE9L6G3ZvgC4kH9Nd-nmqKxyC4dNg9mH7ZNWMnb5tvn_Vdma2w@mail.gmail.com>
Subject: Re: We will not be able to update our websites...
From: Matt Benson <gudnabrsam@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=bcaec53aeccebd16a604d0d7a4e8

--bcaec53aeccebd16a604d0d7a4e8
Content-Type: text/plain; charset=ISO-8859-1

I never questioned that the individual components would most likely
continue with the Maven-generated content.  I do question whether we want
to bother laying out the main site when we have something that works.

br,
Matt


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

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

--bcaec53aeccebd16a604d0d7a4e8--