[jira] Commented: (MCLEAN-49) Preserve build directory after cleaning
[
https://jira.codehaus.org/browse/MCLEAN-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274108#comment-274108
]
Benjamin Bentmann commented on MCLEAN-49:
-
It might be worth to check the example configuration given in MCLEAN-44 and the
parameter {{excludeDefaultDirectories}}
> Preserve build directory after cleaning
> ---
>
> Key: MCLEAN-49
> URL: https://jira.codehaus.org/browse/MCLEAN-49
> Project: Maven 2.x Clean Plugin
> Issue Type: Improvement
>Affects Versions: 2.4.1
>Reporter: Björn Michael
>Priority: Minor
>
> I feel the need to preserve e.g. project.build.directory folder after
> deleting all files and folders within this folder by clean:clean.
> Currently these default output folders are deleted entirely instead of beeing
> cleared.
> This could be configured by configuration section in pom or by a property.
> Thanks in advance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MCLEAN-49) Preserve build directory after cleaning
[ https://jira.codehaus.org/browse/MCLEAN-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274111#comment-274111 ] Björn Michael edited comment on MCLEAN-49 at 7/25/11 5:49 AM: -- This is a solution indeed but a clear flag would be much more comfortable. It's up to you, I can live with this 'workaround'. was (Author: daobi): This is a solution indeed but a clear flag would be more comfortable. It's up to you, I can live with this 'workaround'. > Preserve build directory after cleaning > --- > > Key: MCLEAN-49 > URL: https://jira.codehaus.org/browse/MCLEAN-49 > Project: Maven 2.x Clean Plugin > Issue Type: Improvement >Affects Versions: 2.4.1 >Reporter: Björn Michael >Priority: Minor > > I feel the need to preserve e.g. project.build.directory folder after > deleting all files and folders within this folder by clean:clean. > Currently these default output folders are deleted entirely instead of beeing > cleared. > This could be configured by configuration section in pom or by a property. > Thanks in advance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLEAN-49) Preserve build directory after cleaning
[ https://jira.codehaus.org/browse/MCLEAN-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274111#comment-274111 ] Björn Michael commented on MCLEAN-49: - This is a solution indeed but a clear flag would be more comfortable. It's up to you, I can live with this 'workaround'. > Preserve build directory after cleaning > --- > > Key: MCLEAN-49 > URL: https://jira.codehaus.org/browse/MCLEAN-49 > Project: Maven 2.x Clean Plugin > Issue Type: Improvement >Affects Versions: 2.4.1 >Reporter: Björn Michael >Priority: Minor > > I feel the need to preserve e.g. project.build.directory folder after > deleting all files and folders within this folder by clean:clean. > Currently these default output folders are deleted entirely instead of beeing > cleared. > This could be configured by configuration section in pom or by a property. > Thanks in advance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JXR-54) Discuss about Forrestdoc and JXR
[ https://jira.codehaus.org/browse/JXR-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274114#comment-274114 ] Vincent Siveton commented on JXR-54: No specials addons during the last year. If every body are happy with this, we could release 3.0 version as alpha or beta. > Discuss about Forrestdoc and JXR > > > Key: JXR-54 > URL: https://jira.codehaus.org/browse/JXR-54 > Project: Maven JXR > Issue Type: Improvement > Components: jxr >Reporter: Vincent Siveton > > http://www.nabble.com/Forrestdoc-and-Maven-JXR-tf3864888s177.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-149) NullPointerException in maven-resources-plugin
NullPointerException in maven-resources-plugin
--
Key: MRESOURCES-149
URL: https://jira.codehaus.org/browse/MRESOURCES-149
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Components: copy
Affects Versions: 2.5, 2.4.3
Environment: centos 5.x
maven 3.0.3
TeamCity Enterprise Version 6.5.2 (build 17935)
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)
Reporter: Eran Harel
About twice a day we get a NullPointerException in our build:
{code}
[06:44:23]: [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-resources-plugin:2.5:resources
(default-resources) on project spring-lib: Execution default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:2.5:resources failed.
NullPointerException -> [Help 1]
[06:44:23]: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-resources-plugin:2.5:resources
(default-resources) on project spring-lib: Execution default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:2.5:resources failed.
[06:44:23]: at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
[06:44:23]: at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[06:44:23]: at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[06:44:23]: at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
[06:44:23]: at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
[06:44:23]: at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164)
[06:44:23]: at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[06:44:23]: at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[06:44:23]: at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
[06:44:23]: at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[06:44:23]: at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[06:44:23]: at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[06:44:23]: at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[06:44:23]: at java.lang.Thread.run(Thread.java:619)
[06:44:23]: Caused by: org.apache.maven.plugin.PluginExecutionException:
Execution default-resources of goal
org.apache.maven.plugins:maven-resources-plugin:2.5:resources failed.
[06:44:23]: at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
[06:44:23]: at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
[06:44:23]: ... 13 more
[06:44:23]: Caused by: java.lang.NullPointerException
[06:44:23]: at java.util.ArrayList.(ArrayList.java:131)
[06:44:23]: at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filteredFileExtension(DefaultMavenResourcesFiltering.java:115)
[06:44:23]: at
org.apache.maven.shared.filtering.DefaultMavenResourcesFiltering.filterResources(DefaultMavenResourcesFiltering.java:264)
[06:44:23]: at
org.apache.maven.plugin.resources.ResourcesMojo.execute(ResourcesMojo.java:310)
[06:44:23]: at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
[06:44:23]: ... 14 more
{code}
This comes at random times, and the next build doesn't fail.
I've googled for this failure and found nothing. I have this gut feeling that
this may be caused by a concurrency issue in the maven-resources-plugin.
We got this error with maven-resources-plugin 2.4.3, and now with 2.5. Our
maven version is 3.0.3.
We execute the build on TeamCity with the following parameters:
{code}
Goals: install
Additional Maven command line parameters: -T 2C -e -P!releasex,integration
-Dmaven.test.failure.ignore=true -Dmaven.test.error.ignore=true
-Dmaven.test.haltafterfailure=false -Dmaven.junit.timeout=100
-DwarProject.packaging=jar
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5129) Maven struggles while resolving locked snapshots by two or more simultaneously used projects.
[
https://jira.codehaus.org/browse/MNG-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274133#comment-274133
]
Benjamin Bentmann commented on MNG-5129:
You can set the system property
{{aether.artifactResolver.snapshotNormalization=false}} on the commandline or
via MAVEN_OPTS, but whether all Maven plugins out there properly deal with this
situation, is a different story. Good luck.
> Maven struggles while resolving locked snapshots by two or more
> simultaneously used projects.
> -
>
> Key: MNG-5129
> URL: https://jira.codehaus.org/browse/MNG-5129
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.3
>Reporter: Christopher Klewes
>Priority: Blocker
> Attachments: maven-dependency-issue.zip
>
>
> This has to be explained with an easy example. Given that we have three
> projects (A, B and C). Both projects B and C has a dependency to a locked
> snapshot of project A.
> {code:title=Project B requires build number #2}
>
> org.codehaus
> A
> 1.0.0-20110705.132520-2
>
> {code}
> {code:title=Project C requires build number #1}
>
> org.codehaus
> A
> 1.0.0-20110705.132120-1
>
> {code}
> We now call {{dependency:resolve}} on each projects to resolve their
> dependencies from the repositories. As we can see in our local repository
> both versions are fetched and downloaded from their respective repository
> server. Unfortunately a last one wins conflict occurs. The project on which
> {{dependency:resolve}} is called last wins the race. Maven typically copies
> the latest fetched snapshot version (even if it's locked!) to the default
> version. Let's have a look at the folder structure:
> {code:title=Folder listing of the artifact dependency A
> (repository/org/codehaus/A/)}
> maven-metadata-local.xml
> maven-metadata-opensaga.xml
> maven-metadata-opensaga.xml.sha1
> A-1.0.0-20110705.132120-1.jar
> A-1.0.0-20110705.132120-1.pom
> A-1.0.0-20110705.132520-2.jar
> A-1.0.0-20110705.132520-2.pom
>
> A-1.0.0-SNAPSHOT.jar (the last fetched snapshot version)
> A-1.0.0-SNAPSHOT.pom
> {code}
> The last version will be copied to the file {{A-1.0.0-SNAPSHOT.jar}}. Maven
> references their dependencies to the file without the exactt
> timestamp/buildnumber. This fact make it impossible to develop the project B
> and C or even run them simultaneously, because only the last one wins.
> It would be mandatory to exactly reference the file with the timestamp of
> each project!
> What do you think on this issue? I submitted the project structure so you can
> easily reproduce this issue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5136) Not all dependency are included in WAR
Not all dependency are included in WAR -- Key: MNG-5136 URL: https://jira.codehaus.org/browse/MNG-5136 Project: Maven 2 & 3 Issue Type: Bug Components: General Affects Versions: 3.0.3 Environment: Windows Vista 32 Bit, apache maven 3.0.3, java version "1.6.0_21" Java(TM) SE Runtime Environment (build 1.6.0_21-b07) Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing) Reporter: luca preziati Priority: Blocker Attachments: Lib dir.txt When I launch mvn dependency:tree i found logback-core, when I build War the lib isn't include. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5136) Not all dependency are included in WAR
[ https://jira.codehaus.org/browse/MNG-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274135#comment-274135 ] luca preziati commented on MNG-5136: Also javassint miss, It's like all second level dependency are excluded. > Not all dependency are included in WAR > -- > > Key: MNG-5136 > URL: https://jira.codehaus.org/browse/MNG-5136 > Project: Maven 2 & 3 > Issue Type: Bug > Components: General >Affects Versions: 3.0.3 > Environment: Windows Vista 32 Bit, apache maven 3.0.3, java version > "1.6.0_21" > Java(TM) SE Runtime Environment (build 1.6.0_21-b07) > Java HotSpot(TM) Client VM (build 17.0-b17, mixed mode, sharing) >Reporter: luca preziati >Priority: Blocker > Attachments: Lib dir.txt > > > When I launch mvn dependency:tree i found logback-core, when I build War the > lib isn't include. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5121) maven seems to lose transitive dependencies from the list of compilation dependencies
[ https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274137#comment-274137 ] Benjamin Bentmann commented on MNG-5121: This likely requires a runnable test project for proper analysis and fixing. > maven seems to lose transitive dependencies from the list of compilation > dependencies > - > > Key: MNG-5121 > URL: https://jira.codehaus.org/browse/MNG-5121 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.1, 3.0.2, 3.0.3 > Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK > 1.6.0_24 >Reporter: Henning Schmiedehausen >Priority: Blocker > Attachments: build_failed.log, build_successful.log, maven-pom.xml > > > See the attached build logs "build_failed.log" and "build_succesful.log". > They were both created from using the attached POM. The only difference is > that in the successful build the dependency > > > com.google.inject > > guice > > 3.0 > > > is moved to the very top of the dependency list. When diffing the two build > logs, the most important difference is that in the failed log maven picks up > these dependencies: > [DEBUG]com.google.inject:guice:jar:3.0:compile > while in the successful build, the same dependency looks like this: > [DEBUG]com.google.inject:guice:jar:3.0:compile > > [DEBUG] javax.inject:javax.inject:jar:1:compile > > [DEBUG] aopalliance:aopalliance:jar:1.0: > This translates for the successful build into: > [DEBUG] Classpath: > [/Users/henning/private/source/services/thetargetproject/target/classes > > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar > > [...] > and for the failed build: > [DEBUG] Classpath: [...] > /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar > > > [...] > (note that even for the successful build, the aopalliance dependency still > got dropped). > This behaviour started with maven 3.x, all permutations of the dependencies > build fine with maven 2.2.1 > This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3). > In both cases, the transitive dependencies of guice 3.0 > (javax.inject:javax.inject and aopalliance:aopalliance) should always be > present. > The same behaviour occurs in the exec-maven-plugin which uses the runtime > dependency path to execute java code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5136) Not all dependency are included in WAR
[ https://jira.codehaus.org/browse/MNG-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274140#comment-274140 ] luca preziati commented on MNG-5136: Build from eclipse, with Embedded Maven 3.0-SNAPSHOT works well... List of dependencies files: 25/07/2011 17.26 . 25/07/2011 17.26 .. 23/09/2010 11.5669.409 activation-1.1.1.jar 15/10/2010 16.24 443.432 antlr-2.7.6.jar 23/09/2010 11.53 4.467 aopalliance-1.0.jar 19/11/2010 18.17 345.048 apache-mime4j-0.6.jar 08/01/2011 22.39 116.226 aspectjrt-1.6.10.jar 05/07/2011 15.17 610.790 c3p0-0.9.1.2.jar 23/09/2010 11.5256.660 castor-core-1.3.1.jar 23/09/2010 11.52 800.767 castor-xml-1.3.1.jar 24/01/2011 16.27 232.019 commons-beanutils-1.8.3.jar 13/10/2010 11.2058.160 commons-codec-1.4.jar 28/09/2010 17.05 575.389 commons-collections-3.2.1.jar 01/10/2010 09.48 160.519 commons-dbcp-1.4.jar 03/02/2011 12.57 159.509 commons-io-2.0.1.jar 03/02/2011 12.42 284.220 commons-lang-2.6.jar 23/09/2010 11.5160.686 commons-logging-1.1.1.jar 20/12/2010 14.0796.221 commons-pool-1.5.4.jar 23/09/2010 11.58 313.898 dom4j-1.6.1.jar 23/09/2010 11.52 205.734 dozer-5.2.2.jar 15/04/2011 16.07 650.466 ehcache-core-2.2.0.jar 15/04/2011 16.06 123.994 ehcache-spring-annotations-1.1.3.jar 11/11/2010 11.03 142.626 emc-bpm-services-remote-6.6.jar 11/11/2010 11.0322.887 emc-ci-services-remote-6.6.jar 11/11/2010 11.0329.464 emc-collaboration-services-remote-6.6.ja 11/11/2010 11.03 907.807 emc-dfs-rt-remote-6.6.jar 11/11/2010 11.03 171.206 emc-dfs-services-remote-6.6.jar 11/11/2010 11.0428.552 emc-search-services-remote-6.6.jar 14/04/2011 11.5783.423 envelope-client-1.2.1.jar 23/09/2010 11.56 291.834 FastInfoset-1.2.7.jar 07/07/2011 12.4423.310 foundation-ext-pec-core-0.4.0-SNAPSHOT.j 21/07/2011 10.04 9.942 gedi-commons-context-2.2.0-SNAPSHOT.jar 21/07/2011 10.0454.768 gedi-commons-model-2.2.0-SNAPSHOT.jar 21/07/2011 10.0412.895 gedi-commons-utils-2.2.0-SNAPSHOT.jar 21/07/2011 17.1255.192 gedi-foundation-api-1.1.0-SNAPSHOT.jar 21/07/2011 17.13 412.400 gedi-foundation-core-1.1.0-SNAPSHOT.jar 21/07/2011 10.0295.847 gedi-platform-core-2.2.0-SNAPSHOT.jar 25/07/2011 16.54 161.607 gfs-adapters-3.1.0-SNAPSHOT.jar 25/07/2011 16.5429.178 gfs-adapters-api-3.1.0-SNAPSHOT.jar 18/10/2010 12.54 283.436 hessian-3.2.0.jar 08/01/2011 20.1271.283 hibernate-commons-annotations-3.2.0.Fina r 04/05/2011 17.41 3.111.916 hibernate-core-3.6.3.Final.jar 08/01/2011 20.12 100.884 hibernate-jpa-2.0-api-1.0.0.Final.jar 19/11/2010 18.14 291.037 httpclient-4.0.1.jar 04/10/2010 14.42 172.888 httpcore-4.0.1.jar 19/11/2010 18.1725.443 httpmime-4.0.1.jar 05/07/2011 16.22 228.835 int-core-0.4.0-SNAPSHOT.jar 03/02/2011 12.56 207.271 jackson-core-asl-1.7.1.jar 03/02/2011 12.57 622.174 jackson-mapper-asl-1.7.1.jar 17/12/2010 12.41 597.476 javassist-3.9.0.GA.jar 23/09/2010 11.5689.967 jaxb-api-2.1.jar 23/09/2010 11.56 849.219 jaxb-impl-2.1.4.jar 23/09/2010 11.56 980.264 jaxb1-impl-2.2.jar 23/09/2010 11.5633.428 jaxws-api-2.1.jar 23/09/2010 11.56 1.284.131 jaxws-rt-2.1.4.jar 23/09/2010 11.3417.308 jcl-over-slf4j-1.6.1.jar 23/09/2010 11.52 153.115 jdom-1.1.jar 23/09/2010 11.56 7.989 jsr181-api-1.0-MR1.jar 23/09/2010 11.56 5.848 jsr250-api-1.0.jar 17/12/2010 12.4115.071 jta-1.1.jar 23/09/2010 11.56 367.444 log4j-1.2.14.jar 03/02/2011 12.42 244.115 logback-classic-0.9.28.jar 03/02/2011 12.42 312.931 logback-core-0.9.28.jar 14/03/2011 11.38 447.676 mail-1.4.1.jar 23/09/2010 11.5638.683 mimepull-1.3.jar 14/04/2011 10.5111.382 nacon-commons-utils-1.1.0.jar 05/10/2010 16.53 1.352.918 ojdbc-14.jar 23/09/2010 11.5668.177 resolver-20050927.jar 23/09/2010 11.5618.817 saaj-api-1.3.jar 14/03/2011 11.59 274.208 saaj-impl-1.3.jar 11/11/2010 11.04 331.011 sjsxp-1.0-DCTM.jar 23/09/2010 11.3425.496 slf4j-api-1.6.1.jar 18/10/2010 09.38 321.005 spring-aop-3.0.4.RELEASE.jar 14/10/2010 09.1853.082 spring-asm-3.0.4.RELEASE.jar 18/10/2010 09.38 555.574 spring-beans-3.0.4.RELEASE.jar 18/10/2010 09.38 665.772 spring-context-3.0.4.RELEASE.jar 28/09/2010 16.13 100.860 spring-context-support
[jira] Commented: (MASSEMBLY-561) Encoding is broken when filtering is enabled
[
https://jira.codehaus.org/browse/MASSEMBLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274147#comment-274147
]
John Casey commented on MASSEMBLY-561:
--
Hi Julien,
It seems like the ISO-8859-1 test you added in your patch doesn't work, at
least not on my machine (OS X 10.6.8, US English [default?] language settings).
The output from the verification script is:
iso88591.config was not filtered with correct encoding
I'll try to poke around some more later, but for now I just wanted to let you
know.
> Encoding is broken when filtering is enabled
>
>
> Key: MASSEMBLY-561
> URL: https://jira.codehaus.org/browse/MASSEMBLY-561
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Julien HENRY
>Priority: Critical
> Attachments: MASSEMBLY-561.patch
>
>
> My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
> {code}ISO-8859-1{code}
> I have written a custom assembly file and I am using resource filtering.
> {code}...
>
> ${project.basedir}/src/main/resources/
> /
> true
>
> ...{code}
> As a result all the french characters are broken in the resulting zip
> assembly. My platform is Linux so the default platform encoding is UTF-8.
> I have checked plugin code and I think I found the issue. This is in
> FileFormatter.java, method doFileFilter():
> {code}
> configSource.getMavenFileFilter().copyFile( source, target, true,
> configSource.getProject(),
> configSource.getFilters(), isPropertiesFile, null,
> configSource.getMavenSession() );
> {code}
> You can see that enconding is set to null, so I think it means using default
> platform encoding... Would it be possible to use value of
> project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-561) Encoding is broken when filtering is enabled
[
https://jira.codehaus.org/browse/MASSEMBLY-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274153#comment-274153
]
Julien HENRY commented on MASSEMBLY-561:
Hi John,
The difficulty here is that the encoding of the test file should be ISO-8859-1
where all other files are UTF-8. I'm not sure applying svn patch is safe in
this case. Could you please chech that encoding of
src/it/projects/filtering-feature/filter-encoding-iso88591/src/main/config/iso88591.config
is ISO-8859-1 and that the french character was not corrupted by making
patch/uploading on JIRA//applying patch.
Thanks
> Encoding is broken when filtering is enabled
>
>
> Key: MASSEMBLY-561
> URL: https://jira.codehaus.org/browse/MASSEMBLY-561
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Julien HENRY
>Priority: Critical
> Attachments: MASSEMBLY-561.patch
>
>
> My resources are encoded in ISO-8859-1. I have specified encoding in the pom:
> {code}ISO-8859-1{code}
> I have written a custom assembly file and I am using resource filtering.
> {code}...
>
> ${project.basedir}/src/main/resources/
> /
> true
>
> ...{code}
> As a result all the french characters are broken in the resulting zip
> assembly. My platform is Linux so the default platform encoding is UTF-8.
> I have checked plugin code and I think I found the issue. This is in
> FileFormatter.java, method doFileFilter():
> {code}
> configSource.getMavenFileFilter().copyFile( source, target, true,
> configSource.getProject(),
> configSource.getFilters(), isPropertiesFile, null,
> configSource.getMavenSession() );
> {code}
> You can see that enconding is set to null, so I think it means using default
> platform encoding... Would it be possible to use value of
> project.build.sourceEncoding instead?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5137) Reactor resolution does not work for forked multi module builds
Reactor resolution does not work for forked multi module builds
---
Key: MNG-5137
URL: https://jira.codehaus.org/browse/MNG-5137
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0.3, 2.2.1
Reporter: Benjamin Bentmann
Attachments: test.zip
Running {{mvn clean package site}} on the attached multi-module test project
fails with a dependency resolution issue. While the main build still builds the
aggregator module, an aggregator (report) mojo forks the lifecycle and despite
this forked lifecycle executing up to "package" phase, reactor resolution
inside this forked lifecycle fails since the wrong project instances (those
from the main build instead of the forked build) are searched for build output.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-598) Maven Site Plugin 3.x ignores Wagon extensions
[
https://jira.codehaus.org/browse/MSITE-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MSITE-598.
---
Resolution: Fixed
Fix Version/s: 3.0
Assignee: Herve Boutemy
providers removed in
[r1150887|http://svn.apache.org/viewvc?rev=1150887&view=rev], now that we have
a useful message added in MSITE-599
> Maven Site Plugin 3.x ignores Wagon extensions
> --
>
> Key: MSITE-598
> URL: https://jira.codehaus.org/browse/MSITE-598
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Improvement
> Components: site:deploy
>Affects Versions: 3.0-beta-3
>Reporter: Robert Scholte
>Assignee: Herve Boutemy
>Priority: Critical
> Fix For: 3.0
>
>
> The Wagon extensions are ignores if you try to do a site deployment.
> Reason is that they are defined as dependency in the plugin.
> {code:xml}
>
>
> org.apache.maven.wagon
> wagon-provider-api
> ${wagonVersion}
>
>
> org.apache.maven.wagon
> wagon-file
> ${wagonVersion}
>
>
> org.apache.maven.wagon
> wagon-http-lightweight
> ${wagonVersion}
>
>
> org.apache.maven.wagon
> wagon-ssh
> ${wagonVersion}
>
>
> org.apache.maven.wagon
> wagon-ssh-external
> ${wagonVersion}
>
>
> org.apache.maven.wagon
> wagon-ftp
> ${wagonVersion}
>
>
> org.apache.maven.wagon
> wagon-webdav-jackrabbit
> ${wagonVersion}
>
>
> org.slf4j
> slf4j-nop
>
>
>
>
> org.apache.maven.wagon
> wagon-scm
> ${wagonVersion}
>
> {code}
> The only way to override them is to add the specific wagon-impl as a
> dependency to the plugin.
> Right now this just leads to unexpected usage of extensions.
> I suggest to remove these specific impl's, try to catch exceptions on missing
> wagons if they occur and advice to use extensions.
> Btw, it seems like they are already removed from the maven-site-plugin-2.x
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-567) Support for git-svn
[ https://jira.codehaus.org/browse/SCM-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-567. Resolution: Fixed Assignee: Olivier Lamy duplicate SCM-623 > Support for git-svn > --- > > Key: SCM-567 > URL: https://jira.codehaus.org/browse/SCM-567 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-provider-git >Reporter: Marius Kotsbak >Assignee: Olivier Lamy >Priority: Minor > > Neither git or svn plugin can be used with release plugin on a svn repository > checked out using git-svn, so we need probably another > maven-scm-provider-git-svn or support for that in one of them. > It will probably need to execute a mix of the two, using "git svn tag" for > tagging after "git svn dcommit" etc. > As it is used against a svn repository, it would be best if no configuration > needs to be changed. Thus either add a command line parameter to enable > git-svn mode, or better, in plugin for svn, detect that the checkout is done > using git-svn (the directory .git?), and use that module instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-374) Unable to upload to the site using sftp
[
https://jira.codehaus.org/browse/MSITE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSITE-374:
Description:
Unable to connect to remote repository using sftp or scp. Conecting to
shell.sourceforge.net. Tried to connect using Putty before the using mvn
site:deploy without success. Tried to connect using ssh in Cygwin and then
copied the file "known_hosts" to "C:\Users\jpgravel\.ssh" without success too.
* Note that my private key have been exported to the OpenSSH format using Putty.
The following error occurs:
Using private key: C:\Users\jpgravel\.ssh\sourceforge_priv
sftp://web.sourceforge.net/home/groups/b/bt/btb/htdocs - Session: Disconnecting
sftp://web.sourceforge.net/home/groups/b/bt/btb/htdocs - Session: Disconnected
[ERROR]
The following mojo encountered an error while executing:
Group-Id: org.apache.maven.plugins
Artifact-Id: maven-site-plugin
Version: 2.0-beta-7
Mojo: deploy
brought in via: Direct invocation
While building project:
Group-Id: net.sf.btb
Artifact-Id: bridge
Version: 1.1.0
>From file: C:\Users\jpgravel\workspace\java\BridgeToBabylon\pom.xml
Reason: Error uploading site
When run wih "-e" I get the following exception:
{noformat}org.apache.maven.wagon.providers.ssh.knownhost.UnknownHostException:
The host was not known and was not accepted by the configuration:
web.sourceforge.net
at
org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:178)
at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143)
at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106)
at
org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
at
org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
at
org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
at
org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
at
org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:52)
Caused by: com.jcraft.jsch.JSchException: reject HostKey: web.sourceforge.net
at com.jcraft.jsch.Session.checkHost(Unknown Source)
at com.jcraft.jsch.Session.connect(Unknown Source)
at com.jcraft.jsch.Session.connect(Unknown Source)
at
org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158)
... 17 more{noformat}
Error stacktrace:
{noformat}org.apache.maven.lifecycle.LifecycleExecutionException: Internal
error in the plugin manager executing goal
'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:deploy': Mojo execution
failed.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
at
org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
at
org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
at
org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
at
org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:63)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:52)
Caused by: org.apache.maven.plugin.PluginExecutionExce
[jira] Created: (SCM-626) TfsChangeLogCommand fails when ScmFileSet contains only basedir
TfsChangeLogCommand fails when ScmFileSet contains only basedir --- Key: SCM-626 URL: https://jira.codehaus.org/browse/SCM-626 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-tfs Affects Versions: 1.5 Reporter: Evgeny Mandrikov See SONARPLUGINS-1291 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-5117) UnresolvableModelException in aggregator POM when parent POM is separate and not yet built
[ https://jira.codehaus.org/browse/MNG-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-5117. -- Resolution: Not A Bug Assignee: Benjamin Bentmann Please recheck the error message: bq. The project com.example:com.example.module1:0.1.0-SNAPSHOT [...] and 'parent.relativePath' points at wrong local POM @ line which is exactly the case. All modules that refer to a parent need to have the proper relativePath, not just one of them. > UnresolvableModelException in aggregator POM when parent POM is separate and > not yet built > -- > > Key: MNG-5117 > URL: https://jira.codehaus.org/browse/MNG-5117 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build, Command Line, POM >Affects Versions: 3.0.3 >Reporter: Jonathan Whitall >Assignee: Benjamin Bentmann > Attachments: com.example.zip, maven2.log, maven3.log > > > I get the following error when attempting to build an aggregator POM who > references an external parent (but locally specified by parent.relativePath): > Non-resolvable parent POM: Could not find artifact > com.example:com.example.parent:pom:0.1.0-SNAPSHOT and 'parent.relativePath' > points at wrong local POM @ line 4, column 10 > Example is attached as well as two log files (one for Maven 2.2.1 which works > correctly, one for Maven 3.0.3 which does not) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-2261) Automatic upload of mockito versions.
[ https://jira.codehaus.org/browse/MAVENUPLOAD-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Brakkee reopened MAVENUPLOAD-2261: --- We have seen that the mockito rsync has stopped working. The last successful rsync was last year on 29th of December. Now we want to get a new release out. Can you re-enable the rsync again (at least once to get the release out)? > Automatic upload of mockito versions. > - > > Key: MAVENUPLOAD-2261 > URL: https://jira.codehaus.org/browse/MAVENUPLOAD-2261 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Erik Brakkee >Assignee: Carlos Sanchez > > Authenticity > = > Please contact Szczepan Faber for information about the authenticity of this > request. He is the owner of the mockito.org domain. > Also, my name will appear shortly on the mockito wiki at > http://code.google.com/p/mockito/. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-201) order of reports is not preserved
order of reports is not preserved - Key: MSHARED-201 URL: https://jira.codehaus.org/browse/MSHARED-201 Project: Maven Shared Components Issue Type: Bug Components: maven-reporting-exec Affects Versions: maven-reporting-exec-1.0 Reporter: Herve Boutemy see MSITE-402 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSHARED-201) order of reports is not preserved
[ https://jira.codehaus.org/browse/MSHARED-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSHARED-201. - Resolution: Fixed Fix Version/s: maven-reporting-exec-1.0.1 Assignee: Herve Boutemy fixed in [r1150944|http://svn.apache.org/viewvc?rev=1150944&view=rev] > order of reports is not preserved > - > > Key: MSHARED-201 > URL: https://jira.codehaus.org/browse/MSHARED-201 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-reporting-exec >Affects Versions: maven-reporting-exec-1.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy > Fix For: maven-reporting-exec-1.0.1 > > > see MSITE-402 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-402) Execution order of report plugins is arbitrary if inheritance is involved
[ https://jira.codehaus.org/browse/MSITE-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274193#comment-274193 ] Herve Boutemy commented on MSITE-402: - first level of fix in [r1150948|http://svn.apache.org/viewvc?rev=1150948&view=rev]: now it is ok for Maven 3, but not Maven 2 for the moment > Execution order of report plugins is arbitrary if inheritance is involved > - > > Key: MSITE-402 > URL: https://jira.codehaus.org/browse/MSITE-402 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0 > Environment: ubuntu 8.10 > maven 2.10 > /opt/development/tools/apache-maven-2.1.0/bin/mvn --version > Warning: JAVA_HOME environment variable is not set. > Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100) > Java version: 1.6.0_10 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.10/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.27-11-generic" arch: "i386" Family: "unix" >Reporter: Luca > Attachments: Regression.tgz, sitefull.log.tgz > > > this issue is the clone of http://jira.codehaus.org/browse/MNG-3808 > the output of > /opt/development/tools/apache-maven-2.1.0/bin/mvn clean install site -X > > sitefull.log > is in attachment with the whole project. > the command was executed in Regression/ComponentB > Feel free to ask more info! > thanks -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2261) Automatic upload of mockito versions.
[ https://jira.codehaus.org/browse/MAVENUPLOAD-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274195#comment-274195 ] Brett Porter commented on MAVENUPLOAD-2261: --- Unfortunately the syncs have been taken out of our control. You will probably get a response here: https://issues.sonatype.org/browse/MVNCENTRAL > Automatic upload of mockito versions. > - > > Key: MAVENUPLOAD-2261 > URL: https://jira.codehaus.org/browse/MAVENUPLOAD-2261 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Erik Brakkee >Assignee: Carlos Sanchez > > Authenticity > = > Please contact Szczepan Faber for information about the authenticity of this > request. He is the owner of the mockito.org domain. > Also, my name will appear shortly on the mockito wiki at > http://code.google.com/p/mockito/. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5117) UnresolvableModelException in aggregator POM when parent POM is separate and not yet built
[ https://jira.codehaus.org/browse/MNG-5117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=274219#comment-274219 ] Jonathan Whitall commented on MNG-5117: --- So explain to me why this isn't fully backward compatible with Maven 2? > UnresolvableModelException in aggregator POM when parent POM is separate and > not yet built > -- > > Key: MNG-5117 > URL: https://jira.codehaus.org/browse/MNG-5117 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Bootstrap & Build, Command Line, POM >Affects Versions: 3.0.3 >Reporter: Jonathan Whitall >Assignee: Benjamin Bentmann > Attachments: com.example.zip, maven2.log, maven3.log > > > I get the following error when attempting to build an aggregator POM who > references an external parent (but locally specified by parent.relativePath): > Non-resolvable parent POM: Could not find artifact > com.example:com.example.parent:pom:0.1.0-SNAPSHOT and 'parent.relativePath' > points at wrong local POM @ line 4, column 10 > Example is attached as well as two log files (one for Maven 2.2.1 which works > correctly, one for Maven 3.0.3 which does not) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
