commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: We will not be able to update our websites...
Date Tue, 18 Dec 2012 17:10:34 GMT
2012/12/18 Ralph Goers <ralph.goers@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 <olamy@apache.org>:
>>> 2012/12/18 Phil Steitz <phil.steitz@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 <olamy@apache.org>:
>>>>>> 2012/12/15 Olivier Lamy <olamy@apache.org>:
>>>>>>> 2012/12/15 Ralph Goers <ralph.goers@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 <olamy@apache.org>:
>>>>>>>>>>> 2012/12/15 Matt Benson <gudnabrsam@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 <olamy@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 <gudnabrsam@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 <
>>>>>>>>>>>>>> gilles@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 <
>>>>>>>>>>>>>>>> gilles@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.goers@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.steitz@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-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>>> For additional
commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> To unsubscribe,
e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>>>> For additional
commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>>>> For additional commands,
e-mail: dev-help@commons.apache.org
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
dev-help@commons.apache.org
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Olivier Lamy
>>>>>>>>>>>>> Talend: http://coders.talend.com
>>>>>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message