I still don't understand why you are committing the subprojects to svn. That is not required. Just use stage-deploy to deploy to a local directory on your computer, then copy that under where you have the production web site checked out and check it in. See http://wiki.apache.org/logging/ManagingTheWebSite
Ralph On Dec 18, 2012, at 3:20 AM, Olivier Lamy wrote: > 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 >
