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 ? > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
