2012/12/15 Olivier Lamy <ol...@apache.org>: > 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. >
Done. > 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 -- 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
