You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@zenior.no> on 2012/12/22 04:41:50 UTC
Fwd: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13:
./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/
maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Svnsubpub is just ridiculously inefficient and we need to do something
about it...
(insert mandatory rant about how this would be a piece of cake with git
here ->.<- )
Would it be possible to use svn copy to clone some initial structure and
then just synchronize with the generated site ??
Kristian
Videresendt melding:
*Fra:* krosenvold@apache.org
*Dato:* 22. desember 2012 02:18:53 GMT+07:00
*Til:* commits@maven.apache.org
*Emne:* *svn commit: r843406 - in
/websites/production/maven/content/surefire-archives/surefire-2.13: ./
maven-failsafe-plugin/ maven-failsafe-plugin/css/
maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/
maven-failsafe-plugin/images/profiles/ m...*
*Svar til:* dev@maven.apache.org
Author: krosenvold
Date: Fri Dec 21 19:18:35 2012
New Revision: 843406
Log:
Apache Maven Surefire site deployment
[This commit notification would consist of 104 parts,
which exceeds the limit of 50 ones, so it was shortened to the summary.]
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Hervé BOUTEMY <he...@free.fr>.
exactly
with or without Maven automation like the one Brett shown us
Regards,
Hervé
Le vendredi 25 janvier 2013 00:20:19 Olivier Lamy a écrit :
> 2013/1/20 Hervé BOUTEMY <he...@free.fr>:
> > Le dimanche 20 janvier 2013 05:21:14 Hervé BOUTEMY a écrit :
> >> So if we change our documentation release process to update a fixed
> >> "-latest" place and svn copy on release, svnpubsub should be bearable
> >> IMHO
> >
> > need to rephrase
> >
> > if we change our documentation release process to update a fixed
> > "-latest" place and svn copy on release, svnpubsub should give us the
> > expected service, ie a faster site publication process than previous
> > scp+rsync
> you mean always deploying to something like
> https://svn.apache.org/repos/infra/websites/production/maven/content/surefir
> e-archives/surefire-latest then on release
> svn rm
> https://svn.apache.org/repos/infra/websites/production/maven/content/surefi
> re &&
> svn cp
> https://svn.apache.org/repos/infra/websites/production/maven/content/surefi
> re-archives/surefire-latest
> https://svn.apache.org/repos/infra/websites/production/maven/content/surefi
> re ?
>
> > Regards,
> >
> > Hervé
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13:
./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/
maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Olivier Lamy <ol...@apache.org>.
2013/1/20 Hervé BOUTEMY <he...@free.fr>:
> Le dimanche 20 janvier 2013 05:21:14 Hervé BOUTEMY a écrit :
>> So if we change our documentation release process to update a fixed
>> "-latest" place and svn copy on release, svnpubsub should be bearable IMHO
> need to rephrase
>
> if we change our documentation release process to update a fixed
> "-latest" place and svn copy on release, svnpubsub should give us the expected
> service, ie a faster site publication process than previous scp+rsync
you mean always deploying to something like
https://svn.apache.org/repos/infra/websites/production/maven/content/surefire-archives/surefire-latest
then on release
svn rm https://svn.apache.org/repos/infra/websites/production/maven/content/surefire
&&
svn cp https://svn.apache.org/repos/infra/websites/production/maven/content/surefire-archives/surefire-latest
https://svn.apache.org/repos/infra/websites/production/maven/content/surefire
?
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 20 janvier 2013 05:21:14 Hervé BOUTEMY a écrit :
> So if we change our documentation release process to update a fixed
> "-latest" place and svn copy on release, svnpubsub should be bearable IMHO
need to rephrase
if we change our documentation release process to update a fixed
"-latest" place and svn copy on release, svnpubsub should give us the expected
service, ie a faster site publication process than previous scp+rsync
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Hervé BOUTEMY <he...@free.fr>.
just for the record: I updated Maven 3.1-SNAPSHOT site, there were little
modifications in the code since last update (1 new package private class)
and here is the result:
[INFO] Publish files: 2 addition(s), 9373 update(s), 0 delete(s)
...
[INFO] Checked in 757 file(s) to revision: 847301
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Maven ...................................... SUCCESS
[25:18.042s]
25 minutes: not ideal, but bearable
as expected, the new package private class caused 2 new files (jxr and
aggregated jxr, no javadoc)
as I see the commit log, 2 causes of content change without change in source =
the vast majority of 757 modifications:
1. the "Last Published" date: IMHO, this info is useful, so we have to live
with it
2. timestamp in Modello generated content: I opened a Jira issue [1]
So if we change our documentation release process to update a fixed "-latest"
place and svn copy on release, svnpubsub should be bearable IMHO
Regards,
Hervé
[1] http://jira.codehaus.org/browse/MODELLO-265
Le lundi 7 janvier 2013 17:39:14 Brett Porter a écrit :
> -Copyright © 2001-2012 <a href="http://www.apache.org/">The Apache
> Software Foundation</a>. All Rights Reserved. +Copyright © 2001-2013
> <a href="http://www.apache.org/">The Apache Software Foundation</a>. All
> Rights Reserved.
>
>
> Looks like a once a year hit :)
>
> - Brett
>
> On 07/01/2013, at 5:25 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> > ok, thanks for the tips: will be useful to improve our configurations
> >
> > FYI, I published latest Maven core 3.1-SNAPSHOT site as an update from
> > 2012-12-16 state:
> > [INFO] Updating the pub tree from
> > scm:svn:https://svn.apache.org/repos/infra/websites/production/maven/conte
> > nt/ref/3.1- SNAPSHOT ...
> > ...
> > [INFO] Updating content...
> > [INFO] Publish files: 94 addition(s), 9295 update(s), 9 delete(s)
> > ...
> > [INFO] Checked in 8608 file(s) to revision: 845276
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] BUILD SUCCESS
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Total time: 4:19:44.415s
> > [INFO] Finished at: Mon Jan 07 04:25:02 CET 2013
> > [INFO] Final Memory: 16M/284M
> > [INFO]
> > ------------------------------------------------------------------------
> >
> > More than 4 hours: still not really good.
> >
> > I'll hunt the unuseful modifications checked-in: help welcome.
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 6 janvier 2013 00:54:12 Brett Porter a écrit :
> >> On 05/01/2013, at 10:57 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> >>> ok, that was my first attempts back in july, not based on performance
> >>> expectations but simply logic
> >>> but the release procedure wasn't easy to automate in Maven: I don't see
> >>> in
> >>> Continuum instrusction where the "svn cp xxx/latest to
> >>> xxx/<release-version>" is done. Is it in a Unix shell script?
> >>
> >> Pretty much, exec-maven-plugin:
> >> http://svn.apache.org/viewvc/continuum/trunk/continuum-docs/pom.xml?r1=14
> >> 27
> >> 648&r2=1427649&
> >>
> >> scm:tag didn't support what was needed - but this could be added to the
> >> scm-publish plugin as an option.
> >>
> >>> At that time, the intent was pure logic ("clean work" idea), with impact
> >>> on
> >>> the way to import history: see
> >>> http://maven.apache.org/plugins/maven-scm-
> >>> publish-plugin/examples/importing-maven-site.html
> >>> But when Olivier came in to help me, we chose to drop this part and make
> >>> simple ("brute force"?) content import and drop this "latest" idea which
> >>> was hard to explain
> >>>
> >>> It seems we need to get back to this latest idea since it is really a
> >>> strong performance requirement (and efficiency: yes, between 2 maven
> >>> release, not much content has changed in the 131 MB)
> >>
> >>> I had a look at Continuum and I didn't find some thing we do in maven:
> >> Continuum's site structure is a bit confused, but it has 3 parts: a
> >> single
> >> site set of versioned documentation, a single main top-level site, and
> >> then
> >> a multi-module generated documentation set.
> >>
> >>> - multi-modules sites
> >>> - content generation from sources (javadoc, jxr, plugin documentation)
> >>> Did I miss something?
> >>
> >> Both of these are in the top level POM:
> >> http://svn.apache.org/viewvc/continuum/trunk/pom.xml?revision=1428315&vie
> >> w=m arkup
> >>
> >> It was reduced to project-info-reports and javadoc:aggregate +
> >> jxr:aggregate (+tests)
> >>
> >> The multi-module site uses the "site site:stage scm-publish:publish-scm"
> >> technique, while continuum-docs and the main site just use site-deploy.
> >>
> >> - Brett
> >>
> >> --
> >> Brett Porter
> >> brett@apache.org
> >> http://brettporter.wordpress.com/
> >> http://au.linkedin.com/in/brettporter
> >> http://twitter.com/brettporter
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13:
./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/
maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Olivier Lamy <ol...@apache.org>.
we have aggregated javadoc.
Why generate one per module too ?
cpd/pmd/findbugs are already in sonar.
2013/1/7 Hervé BOUTEMY <he...@free.fr>:
> ok, thanks for the tips: will be useful to improve our configurations
>
> FYI, I published latest Maven core 3.1-SNAPSHOT site as an update from
> 2012-12-16 state:
> [INFO] Updating the pub tree from
> scm:svn:https://svn.apache.org/repos/infra/websites/production/maven/content/ref/3.1-
> SNAPSHOT ...
> ...
> [INFO] Updating content...
> [INFO] Publish files: 94 addition(s), 9295 update(s), 9 delete(s)
> ...
> [INFO] Checked in 8608 file(s) to revision: 845276
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 4:19:44.415s
> [INFO] Finished at: Mon Jan 07 04:25:02 CET 2013
> [INFO] Final Memory: 16M/284M
> [INFO]
> ------------------------------------------------------------------------
>
> More than 4 hours: still not really good.
>
> I'll hunt the unuseful modifications checked-in: help welcome.
>
> Regards,
>
> Hervé
>
>
> Le dimanche 6 janvier 2013 00:54:12 Brett Porter a écrit :
>> On 05/01/2013, at 10:57 PM, Hervé BOUTEMY <he...@free.fr> wrote:
>> > ok, that was my first attempts back in july, not based on performance
>> > expectations but simply logic
>> > but the release procedure wasn't easy to automate in Maven: I don't see in
>> > Continuum instrusction where the "svn cp xxx/latest to
>> > xxx/<release-version>" is done. Is it in a Unix shell script?
>>
>> Pretty much, exec-maven-plugin:
>> http://svn.apache.org/viewvc/continuum/trunk/continuum-docs/pom.xml?r1=1427
>> 648&r2=1427649&
>>
>> scm:tag didn't support what was needed - but this could be added to the
>> scm-publish plugin as an option.
>> > At that time, the intent was pure logic ("clean work" idea), with impact
>> > on
>> > the way to import history: see http://maven.apache.org/plugins/maven-scm-
>> > publish-plugin/examples/importing-maven-site.html
>> > But when Olivier came in to help me, we chose to drop this part and make
>> > simple ("brute force"?) content import and drop this "latest" idea which
>> > was hard to explain
>> >
>> > It seems we need to get back to this latest idea since it is really a
>> > strong performance requirement (and efficiency: yes, between 2 maven
>> > release, not much content has changed in the 131 MB)
>>
>> > I had a look at Continuum and I didn't find some thing we do in maven:
>> Continuum's site structure is a bit confused, but it has 3 parts: a single
>> site set of versioned documentation, a single main top-level site, and then
>> a multi-module generated documentation set.
>> > - multi-modules sites
>> > - content generation from sources (javadoc, jxr, plugin documentation)
>> > Did I miss something?
>>
>> Both of these are in the top level POM:
>> http://svn.apache.org/viewvc/continuum/trunk/pom.xml?revision=1428315&view=m
>> arkup
>>
>> It was reduced to project-info-reports and javadoc:aggregate + jxr:aggregate
>> (+tests)
>>
>> The multi-module site uses the "site site:stage scm-publish:publish-scm"
>> technique, while continuum-docs and the main site just use site-deploy.
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>> http://twitter.com/brettporter
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Brett Porter <br...@apache.org>.
-Copyright © 2001-2012 <a href="http://www.apache.org/">The Apache Software Foundation</a>. All Rights Reserved.
+Copyright © 2001-2013 <a href="http://www.apache.org/">The Apache Software Foundation</a>. All Rights Reserved.
Looks like a once a year hit :)
- Brett
On 07/01/2013, at 5:25 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> ok, thanks for the tips: will be useful to improve our configurations
>
> FYI, I published latest Maven core 3.1-SNAPSHOT site as an update from
> 2012-12-16 state:
> [INFO] Updating the pub tree from
> scm:svn:https://svn.apache.org/repos/infra/websites/production/maven/content/ref/3.1-
> SNAPSHOT ...
> ...
> [INFO] Updating content...
> [INFO] Publish files: 94 addition(s), 9295 update(s), 9 delete(s)
> ...
> [INFO] Checked in 8608 file(s) to revision: 845276
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 4:19:44.415s
> [INFO] Finished at: Mon Jan 07 04:25:02 CET 2013
> [INFO] Final Memory: 16M/284M
> [INFO]
> ------------------------------------------------------------------------
>
> More than 4 hours: still not really good.
>
> I'll hunt the unuseful modifications checked-in: help welcome.
>
> Regards,
>
> Hervé
>
>
> Le dimanche 6 janvier 2013 00:54:12 Brett Porter a écrit :
>> On 05/01/2013, at 10:57 PM, Hervé BOUTEMY <he...@free.fr> wrote:
>>> ok, that was my first attempts back in july, not based on performance
>>> expectations but simply logic
>>> but the release procedure wasn't easy to automate in Maven: I don't see in
>>> Continuum instrusction where the "svn cp xxx/latest to
>>> xxx/<release-version>" is done. Is it in a Unix shell script?
>>
>> Pretty much, exec-maven-plugin:
>> http://svn.apache.org/viewvc/continuum/trunk/continuum-docs/pom.xml?r1=1427
>> 648&r2=1427649&
>>
>> scm:tag didn't support what was needed - but this could be added to the
>> scm-publish plugin as an option.
>>> At that time, the intent was pure logic ("clean work" idea), with impact
>>> on
>>> the way to import history: see http://maven.apache.org/plugins/maven-scm-
>>> publish-plugin/examples/importing-maven-site.html
>>> But when Olivier came in to help me, we chose to drop this part and make
>>> simple ("brute force"?) content import and drop this "latest" idea which
>>> was hard to explain
>>>
>>> It seems we need to get back to this latest idea since it is really a
>>> strong performance requirement (and efficiency: yes, between 2 maven
>>> release, not much content has changed in the 131 MB)
>>
>>> I had a look at Continuum and I didn't find some thing we do in maven:
>> Continuum's site structure is a bit confused, but it has 3 parts: a single
>> site set of versioned documentation, a single main top-level site, and then
>> a multi-module generated documentation set.
>>> - multi-modules sites
>>> - content generation from sources (javadoc, jxr, plugin documentation)
>>> Did I miss something?
>>
>> Both of these are in the top level POM:
>> http://svn.apache.org/viewvc/continuum/trunk/pom.xml?revision=1428315&view=m
>> arkup
>>
>> It was reduced to project-info-reports and javadoc:aggregate + jxr:aggregate
>> (+tests)
>>
>> The multi-module site uses the "site site:stage scm-publish:publish-scm"
>> technique, while continuum-docs and the main site just use site-deploy.
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://brettporter.wordpress.com/
>> http://au.linkedin.com/in/brettporter
>> http://twitter.com/brettporter
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Hervé BOUTEMY <he...@free.fr>.
ok, thanks for the tips: will be useful to improve our configurations
FYI, I published latest Maven core 3.1-SNAPSHOT site as an update from
2012-12-16 state:
[INFO] Updating the pub tree from
scm:svn:https://svn.apache.org/repos/infra/websites/production/maven/content/ref/3.1-
SNAPSHOT ...
...
[INFO] Updating content...
[INFO] Publish files: 94 addition(s), 9295 update(s), 9 delete(s)
...
[INFO] Checked in 8608 file(s) to revision: 845276
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 4:19:44.415s
[INFO] Finished at: Mon Jan 07 04:25:02 CET 2013
[INFO] Final Memory: 16M/284M
[INFO]
------------------------------------------------------------------------
More than 4 hours: still not really good.
I'll hunt the unuseful modifications checked-in: help welcome.
Regards,
Hervé
Le dimanche 6 janvier 2013 00:54:12 Brett Porter a écrit :
> On 05/01/2013, at 10:57 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> > ok, that was my first attempts back in july, not based on performance
> > expectations but simply logic
> > but the release procedure wasn't easy to automate in Maven: I don't see in
> > Continuum instrusction where the "svn cp xxx/latest to
> > xxx/<release-version>" is done. Is it in a Unix shell script?
>
> Pretty much, exec-maven-plugin:
> http://svn.apache.org/viewvc/continuum/trunk/continuum-docs/pom.xml?r1=1427
> 648&r2=1427649&
>
> scm:tag didn't support what was needed - but this could be added to the
> scm-publish plugin as an option.
> > At that time, the intent was pure logic ("clean work" idea), with impact
> > on
> > the way to import history: see http://maven.apache.org/plugins/maven-scm-
> > publish-plugin/examples/importing-maven-site.html
> > But when Olivier came in to help me, we chose to drop this part and make
> > simple ("brute force"?) content import and drop this "latest" idea which
> > was hard to explain
> >
> > It seems we need to get back to this latest idea since it is really a
> > strong performance requirement (and efficiency: yes, between 2 maven
> > release, not much content has changed in the 131 MB)
>
> > I had a look at Continuum and I didn't find some thing we do in maven:
> Continuum's site structure is a bit confused, but it has 3 parts: a single
> site set of versioned documentation, a single main top-level site, and then
> a multi-module generated documentation set.
> > - multi-modules sites
> > - content generation from sources (javadoc, jxr, plugin documentation)
> > Did I miss something?
>
> Both of these are in the top level POM:
> http://svn.apache.org/viewvc/continuum/trunk/pom.xml?revision=1428315&view=m
> arkup
>
> It was reduced to project-info-reports and javadoc:aggregate + jxr:aggregate
> (+tests)
>
> The multi-module site uses the "site site:stage scm-publish:publish-scm"
> technique, while continuum-docs and the main site just use site-deploy.
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Brett Porter <br...@apache.org>.
On 05/01/2013, at 10:57 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> ok, that was my first attempts back in july, not based on performance
> expectations but simply logic
> but the release procedure wasn't easy to automate in Maven: I don't see in
> Continuum instrusction where the "svn cp xxx/latest to xxx/<release-version>"
> is done. Is it in a Unix shell script?
Pretty much, exec-maven-plugin: http://svn.apache.org/viewvc/continuum/trunk/continuum-docs/pom.xml?r1=1427648&r2=1427649&
scm:tag didn't support what was needed - but this could be added to the scm-publish plugin as an option.
>
> At that time, the intent was pure logic ("clean work" idea), with impact on
> the way to import history: see http://maven.apache.org/plugins/maven-scm-
> publish-plugin/examples/importing-maven-site.html
> But when Olivier came in to help me, we chose to drop this part and make
> simple ("brute force"?) content import and drop this "latest" idea which was
> hard to explain
>
> It seems we need to get back to this latest idea since it is really a strong
> performance requirement (and efficiency: yes, between 2 maven release, not much
> content has changed in the 131 MB)
>
>
> I had a look at Continuum and I didn't find some thing we do in maven:
Continuum's site structure is a bit confused, but it has 3 parts: a single site set of versioned documentation, a single main top-level site, and then a multi-module generated documentation set.
> - multi-modules sites
> - content generation from sources (javadoc, jxr, plugin documentation)
> Did I miss something?
Both of these are in the top level POM:
http://svn.apache.org/viewvc/continuum/trunk/pom.xml?revision=1428315&view=markup
It was reduced to project-info-reports and javadoc:aggregate + jxr:aggregate (+tests)
The multi-module site uses the "site site:stage scm-publish:publish-scm" technique, while continuum-docs and the main site just use site-deploy.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mercredi 2 janvier 2013 23:43:52 Brett Porter a écrit :
> On 02/01/2013, at 10:45 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> > Le lundi 24 décembre 2012 14:17:02 Brett Porter a écrit :
> >> I had the same feeling pushing up Continuum's Maven site recently...
> >>
> >> On 23/12/2012, at 9:36 AM, Olivier Lamy <ol...@apache.org> wrote:
> >>> 2012/12/22 Kristian Rosenvold <kr...@zenior.no>:
> >>>> Svnsubpub is just ridiculously inefficient and we need to do something
> >>>> about it...
> >>>
> >>> That remember me old time when pushing maven sites to sourceforge tru
> >>> wagon ftp ... :-)
> >>
> >> Is the main problem the file-by-file nature, or something else (such as
> >> the
> >> size)?
> >
> > I tried to measure and find facts about this: my conclusion is that it is
> > the file-by-file nature
> > exactly like webdav
> > notice that we have really a bunch of generated files: did you realize
> > that
> > maven-scm site has more files than maven core? that it represents 131 MB,
> > tens of thousand of files?
>
> Yes, similar size in Continuum which I've been working on migrating to
> svnpubsub recently.
> > IMHO, if we stored zip files of documentations (or tar, the archive format
> > can be discussed) and httpd could serve their content on the fly like if
> > they were unzipped, this would be awesome
> > Apparently, coding an lua script could do the job: just need to find
> > somebody able to do it :)
>
> I've raised this topic and that thread on #asfinfra and will try and follow
> up - I know this was flagged by them some time ago.
> > any other idea?
>
> For now I'm just focusing on reducing the number of changes each site
> deployment to make it a smaller checkin.
>
> See: http://continuum.apache.org/development/publishing-site.html
>
> What I'm doing there is deploying to /docs/latest each time, then copying
> that to the versioned location on the server-side. That way, the next
> version is just the diff against the last, not a whole new one.
ok, that was my first attempts back in july, not based on performance
expectations but simply logic
but the release procedure wasn't easy to automate in Maven: I don't see in
Continuum instrusction where the "svn cp xxx/latest to xxx/<release-version>"
is done. Is it in a Unix shell script?
At that time, the intent was pure logic ("clean work" idea), with impact on
the way to import history: see http://maven.apache.org/plugins/maven-scm-
publish-plugin/examples/importing-maven-site.html
But when Olivier came in to help me, we chose to drop this part and make
simple ("brute force"?) content import and drop this "latest" idea which was
hard to explain
It seems we need to get back to this latest idea since it is really a strong
performance requirement (and efficiency: yes, between 2 maven release, not much
content has changed in the 131 MB)
I had a look at Continuum and I didn't find some thing we do in maven:
- multi-modules sites
- content generation from sources (javadoc, jxr, plugin documentation)
Did I miss something?
>
> There are a few things that cause changes across generation runs:
> - the javadocs generate a timestamp, and this is the biggest culprit as it
> is the largest number of files. I'm going to add -notimestamp tomorrow and
> see if I can get sequential deploys to remain unmodified - most skins
> incorporated a timestamp that changes each build (I've removed that in
> Continuum's skin). The publish date is still there, but it doesn't seem to
> be a big problem. - the dependencies report seems to change between runs
>
> For other reports the change more frequently, I've stopped publishing them
> to the main site. There is Sonar for most of it at
> http://analysis.apache.org/, or you can publish them to a filesystem
> staging in CI and view them through the workspace.
>
> With these sorts of improvements, incremental deployments will actually be
> better than shipping up a large ZIP that gets unpacked, even though it is
> mostly unchanged.
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: lotsa files and svnpubsub was: svn commit: r843406
Posted by Brett Porter <br...@apache.org>.
On 02/01/2013, at 11:43 PM, Brett Porter <br...@apache.org> wrote:
>
> On 02/01/2013, at 10:45 AM, Hervé BOUTEMY <he...@free.fr> wrote:
>
>> Le lundi 24 décembre 2012 14:17:02 Brett Porter a écrit :
>>> I had the same feeling pushing up Continuum's Maven site recently...
>>>
>>> On 23/12/2012, at 9:36 AM, Olivier Lamy <ol...@apache.org> wrote:
>>>> 2012/12/22 Kristian Rosenvold <kr...@zenior.no>:
>>>>> Svnsubpub is just ridiculously inefficient and we need to do something
>>>>> about it...
>>>>
>>>> That remember me old time when pushing maven sites to sourceforge tru
>>>> wagon ftp ... :-)
>>>
>>> Is the main problem the file-by-file nature, or something else (such as the
>>> size)?
>> I tried to measure and find facts about this: my conclusion is that it is the
>> file-by-file nature
>> exactly like webdav
>> notice that we have really a bunch of generated files: did you realize that
>> maven-scm site has more files than maven core? that it represents 131 MB, tens
>> of thousand of files?
>
> Yes, similar size in Continuum which I've been working on migrating to svnpubsub recently.
>
>>
>> IMHO, if we stored zip files of documentations (or tar, the archive format can
>> be discussed) and httpd could serve their content on the fly like if they were
>> unzipped, this would be awesome
>> Apparently, coding an lua script could do the job: just need to find somebody
>> able to do it :)
>
> I've raised this topic and that thread on #asfinfra and will try and follow up - I know this was flagged by them some time ago.
See my response to your mail over there today - this may already be possible: http://www.apache.org/dev/cmsref.html#generated-docs
But aside from that...
>
>>
>> any other idea?
>
> For now I'm just focusing on reducing the number of changes each site deployment to make it a smaller checkin.
>
> See: http://continuum.apache.org/development/publishing-site.html
>
> What I'm doing there is deploying to /docs/latest each time, then copying that to the versioned location on the server-side. That way, the next version is just the diff against the last, not a whole new one.
>
> There are a few things that cause changes across generation runs:
> - the javadocs generate a timestamp, and this is the biggest culprit as it is the largest number of files. I'm going to add -notimestamp tomorrow and see if I can get sequential deploys to remain unmodified
> - most skins incorporated a timestamp that changes each build (I've removed that in Continuum's skin). The publish date is still there, but it doesn't seem to be a big problem.
> - the dependencies report seems to change between runs
By addressing those 3 things, I got down to either no, or very few, changes between commits (it seems Javadoc doesn't consistently order some elements on the page), e.g.: http://svn.apache.org/r1428378
The dependencies issue was fixed in MPIR-266 (which may need a release). Making the skin timestamp configurable is another task.
I added a few tips to the ASF site: http://www.staging.apache.org/dev/project-site.html#generated
>
> For other reports the change more frequently, I've stopped publishing them to the main site. There is Sonar for most of it at http://analysis.apache.org/, or you can publish them to a filesystem staging in CI and view them through the workspace.
>
> With these sorts of improvements, incremental deployments will actually be better than shipping up a large ZIP that gets unpacked, even though it is mostly unchanged.
Does this help?
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Brett Porter <br...@apache.org>.
On 02/01/2013, at 10:45 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> Le lundi 24 décembre 2012 14:17:02 Brett Porter a écrit :
>> I had the same feeling pushing up Continuum's Maven site recently...
>>
>> On 23/12/2012, at 9:36 AM, Olivier Lamy <ol...@apache.org> wrote:
>>> 2012/12/22 Kristian Rosenvold <kr...@zenior.no>:
>>>> Svnsubpub is just ridiculously inefficient and we need to do something
>>>> about it...
>>>
>>> That remember me old time when pushing maven sites to sourceforge tru
>>> wagon ftp ... :-)
>>
>> Is the main problem the file-by-file nature, or something else (such as the
>> size)?
> I tried to measure and find facts about this: my conclusion is that it is the
> file-by-file nature
> exactly like webdav
> notice that we have really a bunch of generated files: did you realize that
> maven-scm site has more files than maven core? that it represents 131 MB, tens
> of thousand of files?
Yes, similar size in Continuum which I've been working on migrating to svnpubsub recently.
>
> IMHO, if we stored zip files of documentations (or tar, the archive format can
> be discussed) and httpd could serve their content on the fly like if they were
> unzipped, this would be awesome
> Apparently, coding an lua script could do the job: just need to find somebody
> able to do it :)
I've raised this topic and that thread on #asfinfra and will try and follow up - I know this was flagged by them some time ago.
>
> any other idea?
For now I'm just focusing on reducing the number of changes each site deployment to make it a smaller checkin.
See: http://continuum.apache.org/development/publishing-site.html
What I'm doing there is deploying to /docs/latest each time, then copying that to the versioned location on the server-side. That way, the next version is just the diff against the last, not a whole new one.
There are a few things that cause changes across generation runs:
- the javadocs generate a timestamp, and this is the biggest culprit as it is the largest number of files. I'm going to add -notimestamp tomorrow and see if I can get sequential deploys to remain unmodified
- most skins incorporated a timestamp that changes each build (I've removed that in Continuum's skin). The publish date is still there, but it doesn't seem to be a big problem.
- the dependencies report seems to change between runs
For other reports the change more frequently, I've stopped publishing them to the main site. There is Sonar for most of it at http://analysis.apache.org/, or you can publish them to a filesystem staging in CI and view them through the workspace.
With these sorts of improvements, incremental deployments will actually be better than shipping up a large ZIP that gets unpacked, even though it is mostly unchanged.
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Hervé BOUTEMY <he...@free.fr>.
Le lundi 24 décembre 2012 14:17:02 Brett Porter a écrit :
> I had the same feeling pushing up Continuum's Maven site recently...
>
> On 23/12/2012, at 9:36 AM, Olivier Lamy <ol...@apache.org> wrote:
> > 2012/12/22 Kristian Rosenvold <kr...@zenior.no>:
> >> Svnsubpub is just ridiculously inefficient and we need to do something
> >> about it...
> >
> > That remember me old time when pushing maven sites to sourceforge tru
> > wagon ftp ... :-)
>
> Is the main problem the file-by-file nature, or something else (such as the
> size)?
I tried to measure and find facts about this: my conclusion is that it is the
file-by-file nature
exactly like webdav
notice that we have really a bunch of generated files: did you realize that
maven-scm site has more files than maven core? that it represents 131 MB, tens
of thousand of files?
IMHO, if we stored zip files of documentations (or tar, the archive format can
be discussed) and httpd could serve their content on the fly like if they were
unzipped, this would be awesome
Apparently, coding an lua script could do the job: just need to find somebody
able to do it :)
any other idea?
Olivier's idea of a service to get zip file then store unzipped content in svn
would be less efficient (storing so much generated files in svn is inefficient
IMHO), but better than actual situation
> >> (insert mandatory rant about how this would be a piece of cake with git
> >> here ->.<- )
> >>
> >> Would it be possible to use svn copy to clone some initial structure and
> >> then just synchronize with the generated site ??
> >
> > The issue is we create a new path for each release so we need to add
> > all files. (at least when updating an existing path it's faster).
>
> I wonder if it is time to revisit that decision - since we seem to only link
> to the main docs anyway and have been pretty good about annotating "@since"
> in the docs. In particular, the javadoc and similar reports like xref and
> emma tend to take up the largest chunk of the site deployments, and they
> have less value over multiple versions for plugins, etc. than they might
> for a reusable library.
>
> If we were to have multiple versions, perhaps the best way to do that is
> publish to a canonical location, then svn cp that server-side to the
> versioned equivalent.
>
> Ultimately, you really just want to transport diffs.
>
> > I have propose (on infra@) to have a service to put the zipped site
> > and then in async mode the zipped file will be unzipped then
> > committed.
> > But still no response....
>
> I don't recall this, do you have a pointer?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13:
./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/
maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/24 Brett Porter <br...@apache.org>:
> I had the same feeling pushing up Continuum's Maven site recently...
>
> On 23/12/2012, at 9:36 AM, Olivier Lamy <ol...@apache.org> wrote:
>
>> 2012/12/22 Kristian Rosenvold <kr...@zenior.no>:
>>> Svnsubpub is just ridiculously inefficient and we need to do something
>>> about it...
>>>
>> That remember me old time when pushing maven sites to sourceforge tru
>> wagon ftp ... :-)
>
> Is the main problem the file-by-file nature, or something else (such as the size)?
size of the commit (especially for first commit of a huge site)
>
>>> (insert mandatory rant about how this would be a piece of cake with git
>>> here ->.<- )
>>>
>>> Would it be possible to use svn copy to clone some initial structure and
>>> then just synchronize with the generated site ??
>> The issue is we create a new path for each release so we need to add
>> all files. (at least when updating an existing path it's faster).
>
> I wonder if it is time to revisit that decision - since we seem to only link to the main docs anyway and have been pretty good about annotating "@since" in the docs. In particular, the javadoc and similar reports like xref and emma tend to take up the largest chunk of the site deployments, and they have less value over multiple versions for plugins, etc. than they might for a reusable library.
>
+1
> If we were to have multiple versions, perhaps the best way to do that is publish to a canonical location, then svn cp that server-side to the versioned equivalent.
>
> Ultimately, you really just want to transport diffs.
>
>>
>> I have propose (on infra@) to have a service to put the zipped site
>> and then in async mode the zipped file will be unzipped then
>> committed.
>> But still no response....
>
> I don't recall this, do you have a pointer?
See Topic "svnpubsub and publication of component documentations" on infra@
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13: ./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Brett Porter <br...@apache.org>.
I had the same feeling pushing up Continuum's Maven site recently...
On 23/12/2012, at 9:36 AM, Olivier Lamy <ol...@apache.org> wrote:
> 2012/12/22 Kristian Rosenvold <kr...@zenior.no>:
>> Svnsubpub is just ridiculously inefficient and we need to do something
>> about it...
>>
> That remember me old time when pushing maven sites to sourceforge tru
> wagon ftp ... :-)
Is the main problem the file-by-file nature, or something else (such as the size)?
>> (insert mandatory rant about how this would be a piece of cake with git
>> here ->.<- )
>>
>> Would it be possible to use svn copy to clone some initial structure and
>> then just synchronize with the generated site ??
> The issue is we create a new path for each release so we need to add
> all files. (at least when updating an existing path it's faster).
I wonder if it is time to revisit that decision - since we seem to only link to the main docs anyway and have been pretty good about annotating "@since" in the docs. In particular, the javadoc and similar reports like xref and emma tend to take up the largest chunk of the site deployments, and they have less value over multiple versions for plugins, etc. than they might for a reusable library.
If we were to have multiple versions, perhaps the best way to do that is publish to a canonical location, then svn cp that server-side to the versioned equivalent.
Ultimately, you really just want to transport diffs.
>
> I have propose (on infra@) to have a service to put the zipped site
> and then in async mode the zipped file will be unzipped then
> committed.
> But still no response....
I don't recall this, do you have a pointer?
- Brett
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: svn commit: r843406 - in /websites/production/maven/content/surefire-archives/surefire-2.13:
./ maven-failsafe-plugin/ maven-failsafe-plugin/css/ maven-failsafe-plugin/images/
maven-failsafe-plugin/images/logos/ maven-failsafe-plugin/images/profiles/ m...
Posted by Olivier Lamy <ol...@apache.org>.
2012/12/22 Kristian Rosenvold <kr...@zenior.no>:
> Svnsubpub is just ridiculously inefficient and we need to do something
> about it...
>
That remember me old time when pushing maven sites to sourceforge tru
wagon ftp ... :-)
> (insert mandatory rant about how this would be a piece of cake with git
> here ->.<- )
>
> Would it be possible to use svn copy to clone some initial structure and
> then just synchronize with the generated site ??
The issue is we create a new path for each release so we need to add
all files. (at least when updating an existing path it's faster).
I have propose (on infra@) to have a service to put the zipped site
and then in async mode the zipped file will be unzipped then
committed.
But still no response....
>
> Kristian
>
>
> Videresendt melding:
>
> *Fra:* krosenvold@apache.org
> *Dato:* 22. desember 2012 02:18:53 GMT+07:00
> *Til:* commits@maven.apache.org
> *Emne:* *svn commit: r843406 - in
> /websites/production/maven/content/surefire-archives/surefire-2.13: ./
> maven-failsafe-plugin/ maven-failsafe-plugin/css/
> maven-failsafe-plugin/images/ maven-failsafe-plugin/images/logos/
> maven-failsafe-plugin/images/profiles/ m...*
> *Svar til:* dev@maven.apache.org
>
> Author: krosenvold
> Date: Fri Dec 21 19:18:35 2012
> New Revision: 843406
>
> Log:
> Apache Maven Surefire site deployment
>
>
> [This commit notification would consist of 104 parts,
> which exceeds the limit of 50 ones, so it was shortened to the summary.]
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org