2012/12/18 Olivier Lamy <ol...@apache.org>: > 2012/12/18 Phil Steitz <phil.ste...@gmail.com>: >> On 12/17/12 5:55 AM, Olivier Lamy wrote: >>> ETA of the migration: >>> collections and lang done. >>> >>> results: >>> * http://people.apache.org/~olamy/commons/lang/ >>> * http://people.apache.org/~olamy/commons/collections/ >>> >>> As Gary suggested old javadocs are >>> http://people.apache.org/~olamy/commons/lang/javadocs >>> >>> NOTE I didn't import all previous versions. Does it make sense ? >> >> Makes sense to me. Older javadocs can be retrieved from the archives. >> >> THANKS for jumping on this, Olivier! >> >> Other than helping getting site builds working where they may be >> broken, what can the rest of us do to help? > Help me a bit on other components :-). > There are a lot to do (end of proper then sandbox then dormant. > What I can do is to import content manually for sandbox and dormant if > folks want to redeploy website due to code/documentation change they > will need to fix the pom (at least that will work for the migration) > Changes are easy to apply. > > What about releasing the parent ? (I don't know what is the procedure > for that here). > > Something else is the size of sites due to a lot of reporting > (cobertura, findbug, pmd, etc..) and that make svn commit very long. > What about using sonar ? We have an instance for asf projects > (https://analysis.apache.org). I can at least setup this for proper > projects. > > WDYT ?
I have added 4 for testing (collections, cli, lang and ognl). See result: https://analysis.apache.org/dashboard/index/org.apache.commons:commons-proper-aggregator I missed to explain how to configure svnpubsub for site publication. Use last parent pom 28-SNAPSHOT add a property to define site path: <commons.site.path>ognl</commons.site.path> (http://commons.apache.org/ognl) That will commit site content to http://svn.apache.org/repos/asf/commons/cms-site/trunk/ognl/ Then test it :-) mvn clean site site:stage scm-publish:publish-scm To pass your svn authz: -Dusername=asf id -Dpassword=asf password Once is done add the new path to http://svn.apache.org/repos/asf/commons/proper/commons-site/trunk/content/resources/extpaths.txt > > >> >> Phil >>> >>> digester I have issues while building trunk >>> [ERROR] Failed to execute goal >>> org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile >>> (default-testCompile) on project commons-digester3-ap: Compilation >>> failure: Compilation failure: >>> [ERROR] error: Impossible to generate class >>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: >>> Attempt to recreate a file for type >>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule >>> [ERROR] error: Impossible to generate class >>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: >>> Attempt to recreate a file for type >>> org.apache.commons.digester3.annotations.processor.GeneratedRulesModule >>> [ERROR] -> [Help 1] >>> [ERROR] >>> [ERROR] To see the full stack trace of the errors, re-run Maven with >>> the -e switch. >>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>> >>> So I stop for it as no idea on WTF here >>> >>> 2012/12/15 Olivier Lamy <ol...@apache.org>: >>>> 2012/12/15 Olivier Lamy <ol...@apache.org>: >>>>> 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/. >>>> I will start with digester and collections. >>>> As I can see there is a lot of content deployed manually. I think >>>> about versionned documentation >>>> (http://commons.apache.org/digester/commons-digester-3.1) so this will >>>> need to be imported manually 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 >>>>>> >>>> >>>> >>>> -- >>>> 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
