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 < gil...@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 < > > gil...@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.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 > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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 > >
