2012/12/18 Ralph Goers <ralph.go...@dslextreme.com>: > 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 > As I can see in section "Managing Sub-project Sites" this doc says "Make sure all that is added to svn and commit it." So subsites must be checked in (here I configure this to be done tru a maven plugin and not manually) Infra will be able to use as production web site: http://svn.apache.org/repos/asf/commons/cms-site/trunk/ (or https://svn.apache.org/repos/infra/websites/production/commons/content/ but this one still doesn't exist, I will ping infra on the jira entry for their preference).
So if you want sub-project sites available AFAIK this (check in all content) must be done (or I misunderstand something: -)). Makes sense ? > > 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 >> > -- 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
