2012/12/15 Matt Benson <gudnabr...@gmail.com>: > Olivier, > Thanks for your response and offer to contribute! We do have a few > multi-module components here. Of "proper" components, there is only [jci] > that I know of, but [proxy]'s 2.0 branch is multimodule, and we had > intended to take [functor] multimodule before a release is made. I'm > perusing your wiki link now. >
Maybe you can update the jira entry to say you want a solution "à la" maven ? and website content from https://svn.apache.org/repos/infra/websites/production/commons/content/ I will update commons-site now to get it working for cms. For deploying I can try make configuration easy if you accept to use something like: mvn site site:stage scm-publish:publish-scm rather than mvn site-deploy (btw that won't be possible for multi modules :-) ). Note that will need a release of your parent pom. > Matt > > > On Fri, Dec 14, 2012 at 5:10 PM, Olivier Lamy <ol...@apache.org> wrote: > >> /me listening here >> >> Note maven.apache.org has been migrated this week. >> >> If you want to mix cms and maven site generation, we do that. >> Note: even the main site is generated with a maven build but we can >> edit files (apt/xdoc/markdown) with the cms editor >> >> The source tree need some modifications: see >> https://svn.apache.org/repos/asf/maven/site/trunk/ and a bit of >> documentation here: http://apache.org/dev/cmsadoption#maven . >> >> Let me know if you need some help (I think I have karma here so I can >> do a bit of pom.xml stuff :-) ) >> >> Maybe instead of https://svn.apache.org/repos/asf/commons/cms-site/trunk/ >> you could use https://svn.apache.org/repos/infra/websites/production/ >> which is dedicated to this purpose. >> >> As I can see you are using this module >> https://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/ >> for main site ? >> If you want I can do the necessary changes to make it working with >> both cms and mvn site. >> >> For sub projects, that's easy if all are mono modules projects (in >> this case mvn site-deploy works) >> For multi modules, it's a bit different. Is there any multi modules >> projects here ? >> >> -- >> Olivier >> >> 2012/12/14 Matt Benson <gudnabr...@gmail.com>: >> > 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 >> >> >> >> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
