And now I'm even more confused since I just saw your commits to build the CMS site using Maven.
Ralph On Dec 14, 2012, at 6:35 PM, Ralph Goers wrote: > So now I'm confused. You are proposing to bypass the CMS altogether and only > publish to the live site. Why? Even projects like Flume that use maven for > the site build still do it in the CMS. > > Ralph > > On Dec 14, 2012, at 4:33 PM, Olivier Lamy wrote: > >> 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 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
