You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Olivier Lamy <ol...@apache.org> on 2013/03/01 23:43:31 UTC
Re: svn commit: r1451672 - /commons/proper/ognl/trunk/pom.xml
2013/3/1 <lu...@apache.org>:
> Author: lukaszlenart
> Date: Fri Mar 1 18:13:17 2013
> New Revision: 1451672
>
> URL: http://svn.apache.org/r1451672
> Log:
> Excludes files from rat report
>
> Modified:
> commons/proper/ognl/trunk/pom.xml
>
> Modified: commons/proper/ognl/trunk/pom.xml
> URL: http://svn.apache.org/viewvc/commons/proper/ognl/trunk/pom.xml?rev=1451672&r1=1451671&r2=1451672&view=diff
> ==============================================================================
> --- commons/proper/ognl/trunk/pom.xml (original)
> +++ commons/proper/ognl/trunk/pom.xml Fri Mar 1 18:13:17 2013
> @@ -178,7 +178,7 @@ limitations under the License.
> <maven.compile.source>1.5</maven.compile.source>
> <maven.compile.target>1.5</maven.compile.target>
>
> - <commons.scmPubCheckoutDirectory>site-content</commons.scmPubCheckoutDirectory>
> + <commons.scmPubCheckoutDirectory>${project.build.directory}/site-content</commons.scmPubCheckoutDirectory>
so if you use mvn clean. You will checkout again the content from svn.
The goal with using site-content directory is to do only update rather
than a full checkout even when using clean.
> </properties>
>
> <dependencies>
> @@ -408,6 +408,16 @@ limitations under the License.
> <sonarHostURL>https://analysis.apache.org/</sonarHostURL>
> </configuration>
> </plugin>
> + <plugin>
> + <groupId>org.apache.rat</groupId>
> + <artifactId>apache-rat-plugin</artifactId>
> + <configuration>
> + <useDefaultExcludes>true</useDefaultExcludes>
> + <includes>
> + <include>src/**/*</include>
> + </includes>
<excludes>
<exclude>site-content</exclude>
</excludes>
> + </configuration>
> + </plugin>
> </plugins>
> </reporting>
> </profile>
> @@ -496,7 +506,7 @@ limitations under the License.
> <id>setup-checkout</id>
> <activation>
> <file>
> - <missing>site-content</missing>
> + <missing>${project.build.directory}/site-content</missing>
Doesn't work for maven 3.0.x versions. See
https://jira.codehaus.org/browse/MNG-5418
> </file>
> </activation>
> <build>
>
>
--
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
Re: svn commit: r1451672 - /commons/proper/ognl/trunk/pom.xml
Posted by Lukasz Lenart <lu...@apache.org>.
2013/3/2 Olivier Lamy <ol...@apache.org>:
> 2013/3/2 Lukasz Lenart <lu...@apache.org>:
>> 2013/3/1 Olivier Lamy <ol...@apache.org>:
>>>> - <commons.scmPubCheckoutDirectory>site-content</commons.scmPubCheckoutDirectory>
>>>> + <commons.scmPubCheckoutDirectory>${project.build.directory}/site-content</commons.scmPubCheckoutDirectory>
>>> so if you use mvn clean. You will checkout again the content from svn.
>>> The goal with using site-content directory is to do only update rather
>>> than a full checkout even when using clean.
>>
>> Yes, I know and I thought about that a bit, either solution wasn't
>> good for me. I don't know how the Commons' release process looks like,
>> but in the Struts project we always perform release and site deploy
>> base on clear checkout, which means we must checkout the site anyway.
>
> Default from parent is
> <!-- scm publish plugin configuration -->
> <commons.site.cache>${user.home}/commons-sites</commons.site.cache>
> <!-- value modules can override it -->
> <commons.site.path>${project.artifactId}</commons.site.path>
> <commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
>
> IMHO it's better value.Note I added the hack with some antrun for
> sites which contains old javadocs which we don't modifiy so no need to
> checkout those paths.
> With your change as you checkout content to
> ${project.build.directory}/site-content, it means running mvn clean
> site twice you will checkout the content twice. Is it very helpful to
> checkout content twice because you're just building the site for
> testing purpose ?
I'm still a bit confused as I thought the site-content will be checked
out only when I want to make a new release and update the site. I see
how the profile is defined but I don't understand the flow :\
That said I'm going to revert the change :-)
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r1451672 - /commons/proper/ognl/trunk/pom.xml
Posted by Olivier Lamy <ol...@apache.org>.
2013/3/2 Lukasz Lenart <lu...@apache.org>:
> 2013/3/1 Olivier Lamy <ol...@apache.org>:
>>> - <commons.scmPubCheckoutDirectory>site-content</commons.scmPubCheckoutDirectory>
>>> + <commons.scmPubCheckoutDirectory>${project.build.directory}/site-content</commons.scmPubCheckoutDirectory>
>> so if you use mvn clean. You will checkout again the content from svn.
>> The goal with using site-content directory is to do only update rather
>> than a full checkout even when using clean.
>
> Yes, I know and I thought about that a bit, either solution wasn't
> good for me. I don't know how the Commons' release process looks like,
> but in the Struts project we always perform release and site deploy
> base on clear checkout, which means we must checkout the site anyway.
Default from parent is
<!-- scm publish plugin configuration -->
<commons.site.cache>${user.home}/commons-sites</commons.site.cache>
<!-- value modules can override it -->
<commons.site.path>${project.artifactId}</commons.site.path>
<commons.scmPubCheckoutDirectory>${commons.site.cache}/${commons.site.path}</commons.scmPubCheckoutDirectory>
IMHO it's better value.Note I added the hack with some antrun for
sites which contains old javadocs which we don't modifiy so no need to
checkout those paths.
With your change as you checkout content to
${project.build.directory}/site-content, it means running mvn clean
site twice you will checkout the content twice. Is it very helpful to
checkout content twice because you're just building the site for
testing purpose ?
>
> It would be better to keep site content in a separate folder eg.
> ../commons-ognl-site-content or in user home folder - I don't what is
> better.
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> 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
Re: svn commit: r1451672 - /commons/proper/ognl/trunk/pom.xml
Posted by Lukasz Lenart <lu...@apache.org>.
2013/3/1 Olivier Lamy <ol...@apache.org>:
>> - <commons.scmPubCheckoutDirectory>site-content</commons.scmPubCheckoutDirectory>
>> + <commons.scmPubCheckoutDirectory>${project.build.directory}/site-content</commons.scmPubCheckoutDirectory>
> so if you use mvn clean. You will checkout again the content from svn.
> The goal with using site-content directory is to do only update rather
> than a full checkout even when using clean.
Yes, I know and I thought about that a bit, either solution wasn't
good for me. I don't know how the Commons' release process looks like,
but in the Struts project we always perform release and site deploy
base on clear checkout, which means we must checkout the site anyway.
It would be better to keep site content in a separate folder eg.
../commons-ognl-site-content or in user home folder - I don't what is
better.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org