[jira] Commented: (SUREFIRE-770) persistence.xml in src/test/resources/META-INF is not taken into account
[ https://jira.codehaus.org/browse/SUREFIRE-770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280705#comment-280705 ] Kristian Rosenvold commented on SUREFIRE-770: - Which issue/solutuion are you referring to ? > persistence.xml in src/test/resources/META-INF is not taken into account > > > Key: SUREFIRE-770 > URL: https://jira.codehaus.org/browse/SUREFIRE-770 > Project: Maven Surefire > Issue Type: Bug > Components: classloading >Affects Versions: 2.9 > Environment: Windows XP >Reporter: Wolfgang Grossinger > > When i have a persistence.xml in /src/main/resources/META-INF and in > /src/test/resources/META-INF the xml for the test is never used. I found a > few issues how to fix this but nobody had an explanation why this behavior is > as it is. For me this behavior is really strange (and I couldn't believe that > this is not my fault and is really not working). It seem this has to do with > classloading - in my opinion, the test classes and the test resources should > have priority, otherwise the whole separation of main/test is useless. I > hope, that there is no real reason why this is so at the moment, because this > behavior is really strange and absolutely against what the normal user would > expect. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-188) .NoSuchMethodError: org.apache.maven.settings.RuntimeInfo.(Lorg/apache/maven/settings/Settings
.NoSuchMethodError: org.apache.maven.settings.RuntimeInfo.(Lorg/apache/maven/settings/Settings Key: MPLUGIN-188 URL: https://jira.codehaus.org/browse/MPLUGIN-188 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: Plugin Plugin Affects Versions: 2.3 Environment: D:\OSI\maven-jaxb2-plugin>mvn -version Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: C:\Program Files\Apache Software Foundation\apache-maven-3.0.3\bin\.. Java version: 1.6.0_26, vendor: Sun Microsystems Inc. Java home: C:\Progra~1\Java\jdk1.6.0_26\jre Default locale: fr_FR, platform encoding: Cp1252 OS name: "windows xp", version: "5.1", arch: "x86", family: "windows" Reporter: zosrothko Hi Got this NoSuchMethodError when building the maven-jax2b-plugin [INFO] Reactor Summary: [INFO] [INFO] Maven JAXB 2.x Plugin Project . SUCCESS [2.782s] [INFO] Maven JAXB 2.x Plugin Core SUCCESS [11.031s] [INFO] Maven JAXB 2.0.x Plugin ... FAILURE [2.094s] [INFO] Maven JAXB 2.1.x Plugin ... SKIPPED [INFO] Maven JAXB 2.2.x Plugin ... SKIPPED [INFO] Maven JAXB 2.x Plugin . SKIPPED [INFO] Maven JAXB 2.x Plugin Testing . SKIPPED [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 16.735s [INFO] Finished at: Thu Oct 06 04:43:12 CEST 2011 [INFO] Final Memory: 8M/23M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-plugin-plugin:2.3:descriptor (default-descriptor) on proje ct maven-jaxb20-plugin: Execution default-descriptor of goal org.apache.maven.plugins:maven-plugin-plugin:2.3:descriptor failed: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-plugin-plugin:2.3:descrip tor: java.lang.NoSuchMethodError: org.apache.maven.settings.RuntimeInfo.(Lorg/apache/maven/settings/Settings;)V [ERROR] - [ERROR] realm =plugin>org.apache.maven.plugins:maven-plugin-plugin:2.3 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy [ERROR] urls[0] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/org/apache/maven/plugins/maven-plugin- plugin/2.3/maven-plugin-plugin-2.3.jar [ERROR] urls[1] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/org/jfrog/maven/annomojo/maven-plugin- tools-anno/1.3.1/maven-plugin-tools-anno-1.3.1.jar [ERROR] urls[2] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/org/jfrog/maven/annomojo/maven-plugin- anno/1.3.1/maven-plugin-anno-1.3.1.jar [ERROR] urls[3] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/p lexus-utils-1.1.jar [ERROR] urls[4] = file:/C:/Progra~1/Java/jdk1.6.0_26/jre/../lib/tools.jar [ERROR] urls[5] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar [ERROR] urls[6] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/org/apache/maven/maven-plugin-tools-ap i/2.1/maven-plugin-tools-api-2.1.jar [ERROR] urls[7] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/org/apache/maven/maven-plugin-tools-ja va/2.1/maven-plugin-tools-java-2.1.jar [ERROR] urls[8] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/qdox/qdox/1.6.1/qdox-1.6.1.jar [ERROR] urls[9] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/org/apache/maven/maven-plugin-tools-be anshell/2.1/maven-plugin-tools-beanshell-2.1.jar [ERROR] urls[10] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/bsh/bsh/1.3.0/bsh-1.3.0.jar [ERROR] urls[11] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/org/apache/maven/reporting/maven-repo rting-impl/2.0/maven-reporting-impl-2.0.jar [ERROR] urls[12] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/commons-validator/commons-validator/1 .1.4/commons-validator-1.1.4.jar [ERROR] urls[13] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/oro/oro/2.0.7/oro-2.0.7.jar [ERROR] urls[14] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/org/apache/maven/reporting/maven-repo rting-api/2.0/maven-reporting-api-2.0.jar [ERROR] urls[15] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/doxia/doxia-sink-api/1.0-alpha-4/doxi a-sink-api-1.0-alpha-4.jar [ERROR] urls[16] = file:/C:/Documents%20and%20Settings/FrancisANDRE/.m2/repository/doxia/doxia-core/1.0-alpha-4/doxia-co re-1.0-alpha-4.jar [ERROR] Number of foreign
[jira] Updated: (MJAVADOC-330) Ability to exclude specific classes
[ https://jira.codehaus.org/browse/MJAVADOC-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MJAVADOC-330: -- Summary: Ability to exclude specific classes (was: Ability to exclude speciifc classes) > Ability to exclude specific classes > --- > > Key: MJAVADOC-330 > URL: https://jira.codehaus.org/browse/MJAVADOC-330 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.8 >Reporter: Gili > > I'd like to be able to specify specific classes to include or exclude in a > project's Javadoc. See > http://stackoverflow.com/questions/1195647/maven-javadoc-plugin-how-can-i-include-only-certain-classes > for a related discussion (this was posted by another user). > I am only personally interested in the ability to exclude specific classes in > a package but allowing others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-330) Ability to exclude speciifc classes
[ https://jira.codehaus.org/browse/MJAVADOC-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280700#comment-280700 ] Gili commented on MJAVADOC-330: --- Please correct the title of this issue. I mistakenly misspelled "specific". > Ability to exclude speciifc classes > --- > > Key: MJAVADOC-330 > URL: https://jira.codehaus.org/browse/MJAVADOC-330 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.8 >Reporter: Gili > > I'd like to be able to specify specific classes to include or exclude in a > project's Javadoc. See > http://stackoverflow.com/questions/1195647/maven-javadoc-plugin-how-can-i-include-only-certain-classes > for a related discussion (this was posted by another user). > I am only personally interested in the ability to exclude specific classes in > a package but allowing others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-330) Ability to exclude speciifc classes
Ability to exclude speciifc classes --- Key: MJAVADOC-330 URL: https://jira.codehaus.org/browse/MJAVADOC-330 Project: Maven 2.x Javadoc Plugin Issue Type: New Feature Affects Versions: 2.8 Reporter: Gili I'd like to be able to specify specific classes to include or exclude in a project's Javadoc. See http://stackoverflow.com/questions/1195647/maven-javadoc-plugin-how-can-i-include-only-certain-classes for a related discussion (this was posted by another user). I am only personally interested in the ability to exclude specific classes in a package but allowing others. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280688#comment-280688
]
Steven Schlansker commented on MCOMPILER-120:
-
Ref:
http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-compiler/1.8.2/plexus-compiler-1.8.2.pom
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280687#comment-280687
]
Steven Schlansker commented on MCOMPILER-120:
-
Kristian commented above that the Plexus compiler was fixed and that 1.8.2 was
released... I can confirm that I see 1.8.2 on various Maven mirrors. Is that
not sufficient? (Sorry, I don't know too much about the dependencies here, I
just want to offer to go bug whoever is blocking this from getting out so I can
use it!)
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280686#comment-280686
]
Robert Scholte commented on MCOMPILER-120:
--
It's not that hard, but we've provided some other patches for the
plexus-compiler-javac. Would be nice if that one is released first before
releasing the next m-compiler-p.
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-388) Correct classpath ordering in .classpath
[
https://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280684#comment-280684
]
Robert Scholte commented on MECLIPSE-388:
-
Jean-Noël,
this is *not* the order Maven will use to compile. So to stay as close as
possible to Maven it should be:
{{a;a1;a2;a3;b;b1;b2;b3;c;c1;c2;c3;}}
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: https://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Assignee: Barrie Treloar
>Priority: Critical
> Fix For: 2.9
>
> Attachments: ideal.classpath, MECLIPSE-388-it-test.patch,
> MECLIPSE-388.patch, MECLIPSE-388.patch, Test.zip
>
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-388) Correct classpath ordering in .classpath
[
https://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280682#comment-280682
]
Jean-Noel Rouvignac edited comment on MECLIPSE-388 at 10/5/11 3:35 PM:
---
Hi Barrie,
Many thanks for your help on this issue.
I had a think about what would make sense as a .classpath file to me on this
example. I based myself on the dependency tree as it is the only way users can
change how maven will order the jars.
I reached the conclusion that a breadth-first search, ordered by the position
in the dependencies is what I want. First of all you want to see your top level
dependencies being included in the classpath in the order they are declared,
then come the second level dependencies also following the order of the top
level dependencies, etc.
So if you have the folowing dependencies:
{noformat}
myproject
+- a
+- a1
+- a2
+- a3
+- b
+- b1
+- b2
+- b3
+- c
+- c1
+- c2
+- c3
{noformat}
Then I would expect to see the following classpath being generated:
{noformat}myproject classes;a;b;c;a1;a2;a3;b1;b2;b3;c1;c2;c3{noformat}
I attached the corresponding .classpath for the little test I previously
attached.
Thanks,
Jean-Noël
was (Author: jnrouvignac):
Hi Barrie,
Many thanks for your help on this issue.
I had a think about what would make sense as a .classpath file to me on this
example. I based myself on the dependency tree as it is the only way users can
change how maven will order the jars.
I reached the conclusion that a breadth-first search, ordered by the position
in the dependencies is what I want. First of all you want to see your top level
dependencies being included in the classpath in the order they are declared,
then come the second level dependencies also following the order of the top
level dependencies, etc.
So if you have the folowing dependencies:
myproject
+- a
+- a1
+- a2
+- a3
+- b
+- b1
+- b2
+- b3
+- c
+- c1
+- c2
+- c3
Then I would expect to see the following classpath being generated:
myproject classes;a;b;c;a1;a2;a3;b1;b2;b3;c1;c2;c3
I attached the corresponding .classpath for the little test I previously
attached.
Thanks,
Jean-Noël
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: https://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Assignee: Barrie Treloar
>Priority: Critical
> Fix For: 2.9
>
> Attachments: ideal.classpath, MECLIPSE-388-it-test.patch,
> MECLIPSE-388.patch, MECLIPSE-388.patch, Test.zip
>
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-388) Correct classpath ordering in .classpath
[
https://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Noel Rouvignac updated MECLIPSE-388:
-
Attachment: ideal.classpath
Hi Barrie,
Many thanks for your help on this issue.
I had a think about what would make sense as a .classpath file to me on this
example. I based myself on the dependency tree as it is the only way users can
change how maven will order the jars.
I reached the conclusion that a breadth-first search, ordered by the position
in the dependencies is what I want. First of all you want to see your top level
dependencies being included in the classpath in the order they are declared,
then come the second level dependencies also following the order of the top
level dependencies, etc.
So if you have the folowing dependencies:
myproject
+- a
+- a1
+- a2
+- a3
+- b
+- b1
+- b2
+- b3
+- c
+- c1
+- c2
+- c3
Then I would expect to see the following classpath being generated:
myproject classes;a;b;c;a1;a2;a3;b1;b2;b3;c1;c2;c3
I attached the corresponding .classpath for the little test I previously
attached.
Thanks,
Jean-Noël
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: https://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Assignee: Barrie Treloar
>Priority: Critical
> Fix For: 2.9
>
> Attachments: ideal.classpath, MECLIPSE-388-it-test.patch,
> MECLIPSE-388.patch, MECLIPSE-388.patch, Test.zip
>
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3472) configuration possibilities to limit size of local repository
[ https://jira.codehaus.org/browse/MNG-3472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280678#comment-280678 ] Lo-Tan commented on MNG-3472: - I also think this should be a configured responsibility of Maven. Maven is the only client that knows how the repository should look, especially if it ever evolves and changes the structure. Leaving it up to external tools could corrupt repositories. I know right now the repository is straight forward, but still. The tool that generated it should know how to handle it. > configuration possibilities to limit size of local repository > - > > Key: MNG-3472 > URL: https://jira.codehaus.org/browse/MNG-3472 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.8 >Reporter: manuel aldana > > it would be great to make repository-size configurable, for instance by > setting the maximum number of downloads of a snapshot-version to be kept. > thus the explosion of local repository size can be reduced. > especially when you are working with many in-house multi-module projects > which are marked as snapshots before released , can increase repository size > significantly. > see mailing-list discussion: > http://www.nabble.com/limit-size-of-local-repository%2C-limit-number-of-snapshots-td16147475s177.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-105) Classes processed by the relocator still have references to the original classes in their constant pools
Classes processed by the relocator still have references to the original classes in their constant pools Key: MSHADE-105 URL: https://jira.codehaus.org/browse/MSHADE-105 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.4 Reporter: Andreas Veithen Priority: Minor Attachments: constant-pool.patch, javap2.txt, javap.txt DefaultShader uses the ClassWriter(ClassReader, int) constructor instead of ClassWriter(int). According to the ASM Javadoc, this has the following effects: "- The constant pool from the original class is copied as is in the new class, which saves time. New constant pool entries will be added at the end if necessary, but unused constant pool entries won't be removed. - Methods that are not transformed are copied as is in the new class, directly from the original class bytecode (i.e. without emitting visit events for all the method instructions), which saves a lot of time. Untransformed methods are detected by the fact that the ClassReader receives MethodVisitor objects that come from a ClassWriter (and not from a custom ClassAdapter or any other ClassVisitor instance)." The second item is actually not applicable in the case of DefaultShader because the entire class needs to be transformed anyway. On the other hand, the first item implies that the constant pool of the transformed class will still have references to the original classes. This can be seen from the attached "javap.txt" file (produced by javap on a class relocated by maven-shade-plugin): the relocation adds new entries at the end of the constant pool, but the original entries are still present. Since the original entries are no longer referenced anywhere in the class, this has no consequences at runtime. However, some tools such as Felix' maven-bundle-plugin use the constant pool to determine the dependencies of a class. The effect is that if such a shaded JAR is embedded into a bundle using maven-bundle-plugin, it will generate spurious Import-Package instructions referring to the original package names. An example of this is described in AXIS2-5145. The solution to this problem is simply not to pass the ClassReader object to the ClassWriter constructor. With this change, the constant pool is properly cleaned up (see the attached "javap2.txt" file). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
duplicate class error with symbolic liked folder
Hi, Each folder in my project has a symbolic link to the folder where the backed files exists. Maven happens to compile the files in the current directory as well as the symbolically linked directory and hence throws "duplicate class" error. I have tried using in the plugins configuration, but looks like it works for only the sources under main. The sources under the test directory struction still faces the same issue.. Is there a way to tell maven to ignore all the folders with a specific name/ ignore symbolic linked folders. Could you also be a little specific with the solution as I am new to maven. Thanks -- rajaram -- rajaram
[jira] Commented: (SCM-634) Clearcase provider status keeps displaying "Can't load the scm provider. You need to define a connectionUrl parameter" but connection node is defined.
[
https://jira.codehaus.org/browse/SCM-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280669#comment-280669
]
Robert Scholte commented on SCM-634:
https://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-api/src/main/java/org/apache/maven/scm/manager/AbstractScmManager.java
In the {{public ScmRepository makeScmRepository( String scmUrl )}} the URL is
split up.
First part must be scm, second part picks up the right provider, third part is
passed as the {{scmSpecificUrl}}
> Clearcase provider status keeps displaying "Can't load the scm provider. You
> need to define a connectionUrl parameter" but connection node is defined.
> --
>
> Key: SCM-634
> URL: https://jira.codehaus.org/browse/SCM-634
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.5
> Environment: Windows
>Reporter: Justin Bleach
> Attachments: SCM-634-test.patch
>
>
> POM has been defined correctly:
>
> ..
>
>
> scm|clearcase|c:\views\tempview\configSpec.txt
>
> scm|clearcase|c:\views\tempview\configSpec.txt
>
> ..
>
> Plugin configuration points to "connection". When doing a 'mvn scm:status'
> keeps telling me "Can't load the scm provider. You need to define a
> connectionUrl parameter". However I am pointing to a valid configSpec('mvn
> scm:validate' = success) and connection is defined as shown above.
> ConfigSpec (for completeness) is:
> element * CHECKEDOUT
> element -dir * /main/LATEST
> element * /main/release_1.0/tempview/LATEST
> element * /main/release_1.0/LATEST -mkbranch ac42144_r1.0_t0001
> element * /main/R1.0 -mkbranch release_1.0
> element * /main/{created_since(today)} -mkbranch release_1.0
> load c:\views\tempview\WCSF\CustomerService
> Cannot do anything with plugin currently because message prevents code from
> being checked out.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SCM-634) Clearcase provider status keeps displaying "Can't load the scm provider. You need to define a connectionUrl parameter" but connection node is defined.
[
https://jira.codehaus.org/browse/SCM-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280668#comment-280668
]
Justin Bleach edited comment on SCM-634 at 10/5/11 1:24 PM:
Looking at the source:
Is not the ClearCaseScmProviderRepository.java instantiated with with full URL?
(scm|clearcase|c:\views\tempview\configSpec.txt). If that happens you don't
have to worry about putting in the last pipe as the first pipe after "scm"
should do.
When I debug to the "fillDefaultProperties" private method in the class I
mentioned above it appears I have 3 tokens. In this method it assumes if only
one token is available there is no view defined (which I don't have defined). I
don't have a view defined but I have 3 tokens.
I looked at the SCM API as well. Am I missing where the SCM and clearcase part
is stripped off before ClearCaseScmProviderRepository is instantiated? It would
make sense they aren't part of the URL since they are basically telling the API
which provider to use but I can't find where that happens.
was (Author: juicybananas):
Looking at the source:
Is not the ClearCaseScmProviderRepository.java instantiated with with full URL?
(scm|clearcase|c:\views\tempview\configSpec.txt). If that happens you don't
have to worry about putting in the last pipe as the first pipe after scm should
do.
When I debug to the fillDefaultProperties private method in the class I
mentioned above it appears I have 3 tokens. In this method it assumes if only
one token is available there is not view defined. But I don't have a view
defined and I have 3 tokens. I looked at the SCM API as well am I missing where
the SCM and clearcase part is stripped off before
ClearCaseScmProviderRepository is instantiated. It would make sense they aren't
part of the URL since they are basically telling the API which provider to use
but I can't find where.
> Clearcase provider status keeps displaying "Can't load the scm provider. You
> need to define a connectionUrl parameter" but connection node is defined.
> --
>
> Key: SCM-634
> URL: https://jira.codehaus.org/browse/SCM-634
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.5
> Environment: Windows
>Reporter: Justin Bleach
> Attachments: SCM-634-test.patch
>
>
> POM has been defined correctly:
>
> ..
>
>
> scm|clearcase|c:\views\tempview\configSpec.txt
>
> scm|clearcase|c:\views\tempview\configSpec.txt
>
> ..
>
> Plugin configuration points to "connection". When doing a 'mvn scm:status'
> keeps telling me "Can't load the scm provider. You need to define a
> connectionUrl parameter". However I am pointing to a valid configSpec('mvn
> scm:validate' = success) and connection is defined as shown above.
> ConfigSpec (for completeness) is:
> element * CHECKEDOUT
> element -dir * /main/LATEST
> element * /main/release_1.0/tempview/LATEST
> element * /main/release_1.0/LATEST -mkbranch ac42144_r1.0_t0001
> element * /main/R1.0 -mkbranch release_1.0
> element * /main/{created_since(today)} -mkbranch release_1.0
> load c:\views\tempview\WCSF\CustomerService
> Cannot do anything with plugin currently because message prevents code from
> being checked out.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-634) Clearcase provider status keeps displaying "Can't load the scm provider. You need to define a connectionUrl parameter" but connection node is defined.
[
https://jira.codehaus.org/browse/SCM-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280668#comment-280668
]
Justin Bleach commented on SCM-634:
---
Looking at the source:
Is not the ClearCaseScmProviderRepository.java instantiated with with full URL?
(scm|clearcase|c:\views\tempview\configSpec.txt). If that happens you don't
have to worry about putting in the last pipe as the first pipe after scm should
do.
When I debug to the fillDefaultProperties private method in the class I
mentioned above it appears I have 3 tokens. In this method it assumes if only
one token is available there is not view defined. But I don't have a view
defined and I have 3 tokens. I looked at the SCM API as well am I missing where
the SCM and clearcase part is stripped off before
ClearCaseScmProviderRepository is instantiated. It would make sense they aren't
part of the URL since they are basically telling the API which provider to use
but I can't find where.
> Clearcase provider status keeps displaying "Can't load the scm provider. You
> need to define a connectionUrl parameter" but connection node is defined.
> --
>
> Key: SCM-634
> URL: https://jira.codehaus.org/browse/SCM-634
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.5
> Environment: Windows
>Reporter: Justin Bleach
> Attachments: SCM-634-test.patch
>
>
> POM has been defined correctly:
>
> ..
>
>
> scm|clearcase|c:\views\tempview\configSpec.txt
>
> scm|clearcase|c:\views\tempview\configSpec.txt
>
> ..
>
> Plugin configuration points to "connection". When doing a 'mvn scm:status'
> keeps telling me "Can't load the scm provider. You need to define a
> connectionUrl parameter". However I am pointing to a valid configSpec('mvn
> scm:validate' = success) and connection is defined as shown above.
> ConfigSpec (for completeness) is:
> element * CHECKEDOUT
> element -dir * /main/LATEST
> element * /main/release_1.0/tempview/LATEST
> element * /main/release_1.0/LATEST -mkbranch ac42144_r1.0_t0001
> element * /main/R1.0 -mkbranch release_1.0
> element * /main/{created_since(today)} -mkbranch release_1.0
> load c:\views\tempview\WCSF\CustomerService
> Cannot do anything with plugin currently because message prevents code from
> being checked out.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-353) StreamWagon.putFromStream() fails with IllegalStateException
StreamWagon.putFromStream() fails with IllegalStateException
Key: WAGON-353
URL: https://jira.codehaus.org/browse/WAGON-353
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Affects Versions: 2.0
Reporter: Benjamin Bentmann
The following exception arises when aether:1.12+ and wagon-http:2.0 meet:
{noformat}
java.lang.IllegalStateException: Should not be using the streaming wagon for
HTTP PUT
at
org.apache.maven.wagon.shared.http.AbstractHttpClientWagon.fillOutputData(AbstractHttpClientWagon.java:930)
at
org.apache.maven.wagon.StreamWagon.getOutputStream(StreamWagon.java:188)
at
org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:272)
at
org.apache.maven.wagon.StreamWagon.putFromStream(StreamWagon.java:252)
at
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksum(WagonRepositoryConnector.java:885)
at
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.uploadChecksums(WagonRepositoryConnector.java:861)
at
org.sonatype.aether.connector.wagon.WagonRepositoryConnector$PutTask.run(WagonRepositoryConnector.java:818)
at
org.sonatype.aether.connector.wagon.WagonRepositoryConnector.put(WagonRepositoryConnector.java:475)
{noformat}
Despite wagon-http:2.0 implementing {{StreamingWagon}} it fails to provide the
declared functionality. The missing functionality should either be
added/restored or the interface revised to allow clients to detect whether
streaming PUTs are supported or not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-162) when annotation processing is disabled by specifying none, target/generated-sources/annotations and target/generated-sources/test-annotations directories a
when annotation processing is disabled by specifying none, target/generated-sources/annotations and target/generated-sources/test-annotations directories are still created, passed to javac via -s option, and added to project sources dirs -- Key: MCOMPILER-162 URL: https://jira.codehaus.org/browse/MCOMPILER-162 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.3.2 Reporter: Ian Springer To disable annotation processing, I have none in my configuration for the compiler plugin. I also have true, in case that's relevant. When I run 'mvn -X compile', I see the following args as part of the forked javac command line: -s /home/ips/Projects/rhq/modules/core/domain/target/generated-sources/annotations -proc:none I also notice the empty directory target/generated-sources/annotations/ is created. If annotation processing is disabled, these directories need not be created, passed to javac via -s, or added to the set of project source directories. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINVOKER-107) mvn deploy of SNAPSHOT failed with maven3 when invoker:run look for current build dependency
[
https://jira.codehaus.org/browse/MINVOKER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280663#comment-280663
]
Tony Chemit commented on MINVOKER-107:
--
I tried to make a IT but could not reproduce the bug... Still I have the
problem in real life.
> mvn deploy of SNAPSHOT failed with maven3 when invoker:run look for current
> build dependency
>
>
> Key: MINVOKER-107
> URL: https://jira.codehaus.org/browse/MINVOKER-107
> Project: Maven 2.x Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.5
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_22
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.22/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.32-25-generic-pae" arch: "i386" Family: "unix"
>Reporter: ludovic
> Attachments: MINVOKER-107.diff
>
>
> When I build
> http://code.google.com/p/mycila/source/browse/mycila-testing/trunk?r=1448 on
> revision 1448, the build failed. r1449 is a workaround.
> the maven command is : mvn clean deploy
> the build failed when running plugin invoker:run with maven3 BUT succeed with
> maven2
> the failure is due of a missing artifact in the its local repository, the
> searched version is a SNAPSHOT, the present version is a timestamped SNAPSHOT
> the dependency com.mycila.testing:mycila-testing-api:jar:2.6-SNAPSHOT is not
> found because the invoker:install copy the SNAPSHOT with the timestamp during
> deploy. And then after during the test, the dependency could not be found.
> The reason is because maven3 always deploy using a timestamped version.
> @see
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-NonuniqueSnapshotDeployments
> ! workaround
> remove
> ${project.build.directory}/local-repo
> from the invoker configuration
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJARSIGNER-21) jars signed using Java 7 have "invalid SHA1 signature"
jars signed using Java 7 have "invalid SHA1 signature" -- Key: MJARSIGNER-21 URL: https://jira.codehaus.org/browse/MJARSIGNER-21 Project: Maven 2.x Jar Signer Plugin Issue Type: Bug Affects Versions: 1.2 Environment: Java 7, Maven 2.2.1 Reporter: Mike Calmus Priority: Critical Using the plugin with Java 6 works fine. When I use it with Java 7, my applet won't load because the SHA1 signatures are invalid. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-161) Exclude ignored for sources generated during the generate-sources phase
Exclude ignored for sources generated during the generate-sources phase
---
Key: MCOMPILER-161
URL: https://jira.codehaus.org/browse/MCOMPILER-161
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Environment: Win7, JDK 7, maven 3.0.3,
Reporter: Laurent Foret
I try in a pom to excludes an unwanted generated package during the
"generate-sources" phase, but without success.
Indeed according to the following pom.xml :
org.apache.maven.plugins
maven-compiler-plugin
**/generated/*
org.apache.cxf
cxf-codegen-plugin
${cxf.version}
registry
generate-sources
wsdl2java
I expected to have every generated java source file in a package which is
called "*.generated.*" not to be compiled.
Exclusion works for all package in my normal "src/main/java" source directory
but not in my "target/generated-sources/cxf" generated source directory.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-108) Assembly Plugin Implicitly Excludes Empty Directory
[ https://jira.codehaus.org/browse/MASSEMBLY-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280659#comment-280659 ] Julien HENRY commented on MASSEMBLY-108: We are facing the same issue: empty directory in a fileset are not copied to output folder but only when filtered is set to true. > Assembly Plugin Implicitly Excludes Empty Directory > --- > > Key: MASSEMBLY-108 > URL: https://jira.codehaus.org/browse/MASSEMBLY-108 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Sharmarke Aden > > It seems that the inclusion of an empty directory isn't currently possible > with the assembly plugin. This is a problem because I would like to have an > empty "logs" directory included with my zip file assembly. It would be nice > if the assembly plugin gave you the option to add empty directories to an > assembly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-343) wagon-scp should remove target area prior to uploading/unzipping new content
[
https://jira.codehaus.org/browse/WAGON-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=280648#comment-280648
]
Jamal commented on WAGON-343:
-
That sounds reasonable.
> wagon-scp should remove target area prior to uploading/unzipping new content
>
>
> Key: WAGON-343
> URL: https://jira.codehaus.org/browse/WAGON-343
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh-external
>Affects Versions: 1.0
> Environment: Maven 3.0.3
> maven-site-plugin:3.0-beta-3
>Reporter: Jamal
>Priority: Minor
> Attachments: ScpHelper.java
>
>
> Similiar to the request captured in this issue
> (https://jira.codehaus.org/browse/MSITE-250), my problem is that our target
> area gets out of sync when we upload our site generated content frequently
> using CI. When files are moved/deleted, our site deployment target area
> becomes a hassle to keep correct because when noticed, we have to manually
> delete either old files, or the entire folder (because it's easier :)) prior
> to deploying the site. I'd like it if the wagon-scp code could remove the
> files/subfolders in the target area prior to uploading.
> I looked at the code, and a easy fix, which I tested, is to update the
> ScpHelper.putDirectory() method (in wagon-ssh-common) to remove the contents
> of the folder prior to uploading/unzipping the new files:
> ...
> try
> {
> executor.executeCommand( "cd " + path + "; rm -rf * ");
>
> wagon.put( zipFile, getPath( destDir, zipFile.getName() ) );
>
> executor.executeCommand( "cd " + path + "; unzip -q -o " +
> zipFile.getName() + "; rm -f " + zipFile.getName() );
> zipFile.delete();
> ...
> I have attached the version of the file which I updated and tested, and below
> is what the output looks like with my simple test project.
> Password for dev@localhost: XX
> scp://localhost/tmp/site-deploy - Session: Opened
> Executing command: mkdir -p /tmp/site-deploy/.
> Executing command: cd /tmp/site-deploy/.; rm -rf *
> Executing command: mkdir -p /tmp/site-deploy/.
> Executing command: scp -t "/tmp/site-deploy/./wagon3163598898345372687.zip"
> Uploading: ./wagon3163598898345372687.zip to scp://localhost/tmp/site-deploy
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAR-145) Option to automatically seal all packages included in the jar
Option to automatically seal all packages included in the jar - Key: MJAR-145 URL: https://jira.codehaus.org/browse/MJAR-145 Project: Maven 2.x JAR Plugin Issue Type: New Feature Reporter: Paul Gier The current jar plugin requires manual manifest configuration to seal all packages in a jar. There should be an option for the jar plugin to create a list of all packages in the jar, and seal them in the manifest. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-581) Git relative pathing broken with release plugin
[ https://jira.codehaus.org/browse/MRELEASE-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Stabiszewski updated MRELEASE-581: - Attachment: gitexe.zip This is a patch for this issue. It will create relative paths for all files that are added to git. Hope you can add this to the next release. Thanks. > Git relative pathing broken with release plugin > --- > > Key: MRELEASE-581 > URL: https://jira.codehaus.org/browse/MRELEASE-581 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: windows xp, service pack 2 >Reporter: Matthew Sandoz > Attachments: gitexe.zip > > > i have a multimodule project, and when i try to do a release, i get > everything working fine until the end. It seems to think for some reason that > I am at the root of my scm tree. The repo i have to work in has several > projects, and mine is in a subdirectory - domains/redemption. the plugin > appears to try to check in my submodules at my current location instead of my > scm root. > COMMAND: > mvn release:prepare -DpreparationGoals="clean install" -DskipTests > -DautoVersionSubmod > ules=true > END OF OUTPUT: > [INFO] [INFO] Reactor Summary: > [INFO] [INFO] > > [INFO] [INFO] Redemption Parent POM . SUCCESS > [2.595s] > [INFO] [INFO] Redemption Runtime Confguration ... SUCCESS > [3.531s] > [INFO] [INFO] Redemption Service Metadata ... SUCCESS > [18.816s] > [INFO] [INFO] Redemption Model .. SUCCESS > [35.693s] > [INFO] [INFO] Redemption DAO SUCCESS > [41.770s] > [INFO] [INFO] Redemption Service Implementation . SUCCESS > [17.517s] > [INFO] [INFO] crm :: guest :: redemption :: ESB :: Parent POM ... SUCCESS > [0.016s] > [INFO] [INFO] crm :: guest :: redemption :: ESB :: XSLT . SUCCESS > [5.469s] > [INFO] [INFO] crm :: guest :: redemption :: ESB :: EIP .. SUCCESS > [0.343s] > [INFO] [INFO] crm :: guest :: redemption :: ESB :: Version Router ... SUCCESS > [3.157s] > [INFO] [INFO] crm :: guest :: redemption :: ESB :: Binding Component :: > Service Unit SUCCESS [3.656s] > [INFO] [INFO] crm :: guest :: redemption :: ESB :: Service Assembly . SUCCESS > [3.516s] > [INFO] [INFO] > > [INFO] [INFO] > > [INFO] [INFO] BUILD SUCCESSFUL > [INFO] [INFO] > > [INFO] [INFO] Total time: 2 minutes 26 seconds > [INFO] [INFO] Finished at: Tue Jul 27 17:18:02 EDT 2010 > [INFO] [INFO] Final Memory: 116M/254M > [INFO] [INFO] > > [INFO] Checking in modified POMs... > [INFO] Executing: cmd.exe /X /C "git add pom.xml redemption-conf\pom.xml > redemption-metadata\pom.xml redemption-model\pom.xml rede > mption-dao\pom.xml redemption-impl\pom.xml redemption-esb\pom.xml > redemption-esb\redemption-xslt\pom.xml redemption-esb\redemption > -eip\pom.xml redemption-esb\redemption-router\pom.xml > redemption-esb\redemption-bc-su\pom.xml redemption-esb\redemption-sa\pom.xml > " > [INFO] Working directory: D:\workspaces\crm-dev\domains\redemption > [INFO] Executing: cmd.exe /X /C "git status" > [INFO] Working directory: D:\workspaces\crm-dev\domains\redemption > [INFO] Executing: cmd.exe /X /C "git commit --verbose -F > D:\DOCUME~1\sandozm\LOCALS~1\Temp\maven-scm-1862033505.commit pom.xml red > emption-conf\pom.xml redemption-metadata\pom.xml redemption-model\pom.xml > redemption-dao\pom.xml redemption-impl\pom.xml redemptio > n-esb\pom.xml redemption-esb\redemption-xslt\pom.xml > redemption-esb\redemption-eip\pom.xml redemption-esb\redemption-router\pom.xm > l redemption-esb\redemption-bc-su\pom.xml > redemption-esb\redemption-sa\pom.xml" > [INFO] Working directory: D:\workspaces\crm-dev\domains\redemption > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The git-commit command failed. > Command output: > error: pathspec 'redemption-conf\pom.xml' did not match any file(s) known to > git. > error: pathspec 'redemption-metadata\pom.xml' did not match any file(s) known > to git. > error: pathspec 'redemption-model\pom.xml' did not match any file(s) known to > git. > error: pathspec 'redemption-dao\pom.xml' did not match any file(s) known to > git. > e
