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 ? 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 -- 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
