2012/12/15 Ralph Goers <ralph.go...@dslextreme.com>: > And now I'm even more confused since I just saw your commits to build the CMS > site using Maven. I started with main site and as I'm in eu I wanted to sleep a bit :-). I will try to work on sub projects today (it's only a matter of configuring parent pom normally) And test with deploying to http://svn.apache.org/repos/asf/commons/cms-site/trunk/.
> > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
