[jira] (MASSEMBLY-478) allow overwriting newer files with older files contained within fileset
[
https://jira.codehaus.org/browse/MASSEMBLY-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355975#comment-355975
]
Kristian Rosenvold commented on MASSEMBLY-478:
--
With the "new" phase ordering filesets will always win, and the order of the
filesets should also indicate precedence
> allow overwriting newer files with older files contained within fileset
> ---
>
> Key: MASSEMBLY-478
> URL: https://jira.codehaus.org/browse/MASSEMBLY-478
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 13:16:01-0600)
> Java version: 1.6.0_17
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.17/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.29-bpo.2-amd64" arch: "amd64" Family: "unix"
>Reporter: deckrider
> Fix For: 2.5.2
>
>
> I have a situation where I want to unwind a zip file, and then overlay a few
> files in it with my own.
> I've been using the maven dependency plugin to unwind this zip file and then
> maven assembly plugin to overwrite a few of the extracted files with my own
> (generally text based configuration that I keep under source code control).
> This seems to work until my files have an earlier modification time than the
> files that I want to overwrite, in which case my own files do NOT overwite
> the others (I want my files to ALWAYS replace those in the zip file).
> Thank in advance. Here are the configuration details
> From my pom.xml:
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
> false
> false
> ${project.build.directory}
> solaris
> true
>
> src/main/assembly/bin.xml
>
>
>
>
> overwrite
> process-sources
>
> directory-single
>
>
>
>
> {code}
> From my src/main/assembly/bin.xml:
> {code:xml}
>
>
> dir
>
> false
>
>
> ${basedir}/src/main/bin
> ${prefix}/jboss/bin
>
>
> ${basedir}/src/main/conf
> ${prefix}/jboss/server/wsa/conf
>
>
> ${basedir}/src/main/deploy
> ${prefix}/jboss/server/wsa/deploy
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-558) Assembly does not include runtime-dependency if test-dependency with shorter path exists
[
https://jira.codehaus.org/browse/MASSEMBLY-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355976#comment-355976
]
Kristian Rosenvold commented on MASSEMBLY-558:
--
This would appear to be MASSEMBLY-395
> Assembly does not include runtime-dependency if test-dependency with shorter
> path exists
>
>
> Key: MASSEMBLY-558
> URL: https://jira.codehaus.org/browse/MASSEMBLY-558
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.2
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Java version: 1.5.0_12, vendor: Sun Microsystems Inc.
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
>Reporter: Frank Jakop
> Fix For: 2.5.2
>
>
> In my project there's an artifact, which can be resolved by 2 different paths
> (scopes in brackets)
> {noformat}
> a) Project->projA(compile)->projB(compile)->myArtifact(runtime)
> b) Project->projB(test)->myArtifact(runtime)
> {noformat}
> The relevant part of the distribution descriptor is the following
> {code:xml}
>
> zip
>
>
>
> /lib
> true
> false
> runtime
>
>
> {code}
> So when I run assembly:assembly I wonder, why myArtifact isn't included in my
> zip. I now think, that assembly favours the shorter path b) despite the
> test-scope over the longer but correct path a).
> Since test-scope dependencies should have nothing to do with distribution (if
> not included explicitly) myArtifact should have be included in my zip.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHADE-182) ServicesResourceTransformer incorrectly ignores given Relocators
[ https://jira.codehaus.org/browse/MSHADE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trask Stalnaker updated MSHADE-182: --- Attachment: MSHADE-182.patch I just ran into this issue also, please see proposed patch. Thanks. > ServicesResourceTransformer incorrectly ignores given Relocators > > > Key: MSHADE-182 > URL: https://jira.codehaus.org/browse/MSHADE-182 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Thomas Kielbus > Attachments: MSHADE-182.patch > > > When using the ServicesResourceTransformer in conjunction with relocators for > classes that have META-INF/services/ entries, the behavior of the Shade > Plugin is unexpected because those services files entries do not get > relocated. > For example: > Relocator: org.foo.Clazz to org.foo.shaded.Clazz > Services files: META-INF/services/org.foo.Clazz > We would expect a services file at META-INF/services/org.foo.shaded.Clazz in > the shaded jar, but that does not happen (the file remains at > META-INF/services/org.foo.Clazz) since the ServicesResourceTransformer > ignores the given Relocators. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1115) StringIndexOutOfBoundsException: String index out of range: 26
[ https://jira.codehaus.org/browse/SUREFIRE-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355978#comment-355978 ] Tibor Digana commented on SUREFIRE-1115: Hi Andreas, It looks like our build fails after changing the internal surifire plugin from 2.12.4 to 2.18. The forking mechanism fails. BR, Tibor > StringIndexOutOfBoundsException: String index out of range: 26 > -- > > Key: SUREFIRE-1115 > URL: https://jira.codehaus.org/browse/SUREFIRE-1115 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.18 > Environment: JDK 7, Maven 3.2.1 >Reporter: Tibor Digana >Priority: Critical > Attachments: log.txt > > > Changed the property shadedVersion=2.18 in the POM of Maven-Surefire-Project. > Launched the project build with mvn install. > Caused by: java.lang.RuntimeException: > java.lang.StringIndexOutOfBoundsException: String index out of range: 26 > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.close(ThreadedStreamConsumer.java:124) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:491) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:378) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:165) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1019) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:853) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:751) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1115) StringIndexOutOfBoundsException: String index out of range: 26
Tibor Digana created SUREFIRE-1115: -- Summary: StringIndexOutOfBoundsException: String index out of range: 26 Key: SUREFIRE-1115 URL: https://jira.codehaus.org/browse/SUREFIRE-1115 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.18 Environment: JDK 7, Maven 3.2.1 Reporter: Tibor Digana Priority: Critical Attachments: log.txt Changed the property shadedVersion=2.18 in the POM of Maven-Surefire-Project. Launched the project build with mvn install. Caused by: java.lang.RuntimeException: java.lang.StringIndexOutOfBoundsException: String index out of range: 26 at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.close(ThreadedStreamConsumer.java:124) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:491) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:378) at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:165) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1019) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:853) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:751) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-437) Provide an option to log to the console on every test method
[ https://jira.codehaus.org/browse/SUREFIRE-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355979#comment-355979 ] Tibor Digana commented on SUREFIRE-437: --- What JUnit provider in surefire do you use? Do you want to log a test method or test case? Personally I am using a super class with @Rule with org.junit.rules.TestName; > Provide an option to log to the console on every test method > > > Key: SUREFIRE-437 > URL: https://jira.codehaus.org/browse/SUREFIRE-437 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Dan Fabulich > Fix For: Backlog > > > We already log to the console whenever we regain control from the testing > framework; in JUnit directory suites, that's once per class, which is pretty > often, but if you use JUnit TestSuites or TestNG, we lose control at the > start of the run and don't get it back until the end of the run. > We should provide an option to log to the console after every test case > method. It should probably be off by default...? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1115) StringIndexOutOfBoundsException: String index out of range: 26
[ https://jira.codehaus.org/browse/SUREFIRE-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=355982#comment-355982 ] Tibor Digana commented on SUREFIRE-1115: The exception is not thrown with SUREFIRE 2.15. > StringIndexOutOfBoundsException: String index out of range: 26 > -- > > Key: SUREFIRE-1115 > URL: https://jira.codehaus.org/browse/SUREFIRE-1115 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.18 > Environment: JDK 7, Maven 3.2.1 >Reporter: Tibor Digana >Priority: Critical > Attachments: log.txt > > > Changed the property shadedVersion=2.18 in the POM of Maven-Surefire-Project. > Launched the project build with mvn install. > Caused by: java.lang.RuntimeException: > java.lang.StringIndexOutOfBoundsException: String index out of range: 26 > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.close(ThreadedStreamConsumer.java:124) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:491) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:378) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:165) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1019) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:853) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:751) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-583) DependencySet elements appear not to be able to target the same outputDirectory
[
https://jira.codehaus.org/browse/MASSEMBLY-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-583.
Resolution: Fixed
Assignee: Kristian Rosenvold
Feature fixed in r1637662, testcase added in r1638197. Thanks for the testcase
!
> DependencySet elements appear not to be able to target the same
> outputDirectory
> ---
>
> Key: MASSEMBLY-583
> URL: https://jira.codehaus.org/browse/MASSEMBLY-583
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.2.1
> Environment: Linux, Sun 64-bit JDK 1.6.0_24
>Reporter: Michael
>Assignee: Kristian Rosenvold
> Fix For: 2.5.2
>
> Attachments: map-jira-2.zip
>
>
> Where an assembly descriptor uses two dependencySet elements, both of which
> have the same outputDirectory value, only the first is honoured and the
> second is ignored.
> In the attached ZIP are some test/POC files which demonstrate this issue.
> Project1 contains a .property file in
> src/main/resources
> and some start/stop scripts at
> src/main/resources/bin
> Project2 has a runtime dependency on Project1 and attempts to unpack both the
> scripts and the properties files to the same output-directory, specifying
> execute permissions for the start/stop scripts. However, only the first
> dependencySet is unpacked; to verify this behaviour, follow these steps:
> 1) Unzip the map-jira-2.zip file to the filesystem.
> 2) From the maven-assembly-jira2 directory, execute the mvn package command.
> 3) Verify that in project2/target/project2-0.0.1-SNAPSHOT-deployable.zip the
> contents omits the start/stop scripts:
> {noformat}
> $ unzip -l project2/target/project2-0.0.1-SNAPSHOT-deployable.zip
> Archive: project2/target/project2-0.0.1-SNAPSHOT-deployable.zip
> Length Date TimeName
> 0 11-30-11 10:59 project2-0.0.1-SNAPSHOT/
> 0 11-30-11 10:59 project2-0.0.1-SNAPSHOT/empty.properties
> 0 2 files
> {noformat}
> 4) Edit the descriptor project2/src/main/assembly/assembly.xml and move the
> second dependencySet element above the first.
> 5) Execute mvn package from the maven-assembly-jira2 directory.
> 6) Verify that the ZIP in project2 now omits the empty.properties file but
> does now contain the start/stop scripts:
> {noformat}
> $ unzip -l project2/target/project2-0.0.1-SNAPSHOT-deployable.zip
> Archive: project2/target/project2-0.0.1-SNAPSHOT-deployable.zip
> Length Date TimeName
> 0 11-30-11 11:02 project2-0.0.1-SNAPSHOT/
> 0 11-30-11 11:02 project2-0.0.1-SNAPSHOT/bin/
> 0 11-30-11 10:59 project2-0.0.1-SNAPSHOT/bin/start.sh
> 0 11-30-11 10:59 project2-0.0.1-SNAPSHOT/bin/stop.sh
> 0 4 files
> {noformat}
> Expected behavour would be for all files to be copied to their target
> locations with correct file-permissions.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-655) Archive file resolution does not work as documented
[ https://jira.codehaus.org/browse/MASSEMBLY-655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-655. Resolution: Fixed Assignee: Kristian Rosenvold Docs improved in r1638200. Please read the updated docs. > Archive file resolution does not work as documented > --- > > Key: MASSEMBLY-655 > URL: https://jira.codehaus.org/browse/MASSEMBLY-655 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Martin Lichtin >Assignee: Kristian Rosenvold > Fix For: 2.5.2 > > > On page > http://maven.apache.org/plugins/maven-assembly-plugin/advanced-descriptor-topics.html > it says that: > "one fileSet selects sourceDir1/config.xml and another selects > sourceDir2/config.xml to be archived as config/config.xml. In this case, > assembly plugin archives the source file selected in the latter fileSet." > However, this does not seem true? > It seems like the the file is taken from the first fileSet. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-609) Misbehavior on multi-module projects, outputDirectory not being interpolated properly
[
https://jira.codehaus.org/browse/MASSEMBLY-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-609.
Resolution: Fixed
Assignee: Kristian Rosenvold
Docs updated in r1638201.
The proper expression is the "logical" ${artifact.artifactId} since
${artifactId} always refers to the module artifact.
> Misbehavior on multi-module projects, outputDirectory not being interpolated
> properly
> -
>
> Key: MASSEMBLY-609
> URL: https://jira.codehaus.org/browse/MASSEMBLY-609
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: (attached)
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>Reporter: Alexander Tumin
>Assignee: Kristian Rosenvold
>Priority: Blocker
> Fix For: 2.5.2
>
> Attachments: parent.zip
>
>
> With set to true; tag value is
> not being interpolated on a module-by-module basis as said in
> [documentation|http://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html]
> - instead of substituting ${artifactId} with value of each processed modules
> it is always being substituted with the value of module which calls to the
> assembly plugin.
> In other words, instead of the following desired directory structure:
> distribution/target/distribution-1.0-bin/modules/child1/child1-1.0.jar
> distribution/target/distribution-1.0-bin/modules/child2/child2-1.0.jar
> distribution/target/distribution-1.0-bin/modules/child3/child3-1.0.jar
> i am getting flatenned
> distribution/target/distribution-1.0-bin/modules/distribution/child1-1.0.jar
> distribution/target/distribution-1.0-bin/modules/distribution/child2-1.0.jar
> distribution/target/distribution-1.0-bin/modules/distribution/child3-1.0.jar
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-565) jar-with-dependencies: class from the source in project does NOT override the class in jar dependency
[ https://jira.codehaus.org/browse/MASSEMBLY-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-565. Resolution: Fixed Assignee: Kristian Rosenvold Due to MASSEMBLY-725, module sets will now always override dependency sets. Precedence is now from most specific (file) to least specific (repository) > jar-with-dependencies: class from the source in project does NOT override the > class in jar dependency > - > > Key: MASSEMBLY-565 > URL: https://jira.codehaus.org/browse/MASSEMBLY-565 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: predefined descriptors >Affects Versions: 2.2.1 > Environment: % mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) > Maven home: /home/jmv/apps/apache-maven3 > Java version: 1.6.0_25, vendor: Sun Microsystems Inc. > Java home: /home/jmv/apps/jdk1.6.0_25/jre > Default locale: fr_FR, platform encoding: UTF-8 > OS name: "linux", version: "2.6.38-10-generic", arch: "amd64", family: "unix" >Reporter: Jean-Marc Vanel >Assignee: Kristian Rosenvold > Fix For: 2.5.2 > > Attachments: maven_bug_build_override_class.zip > > > When running plugin maven-assembly-plugin 2.2.1 with jar-with-dependencies, > and there is a class C1 in src/main/java/ that overrides a class C1 in some > dependency, in the resulting XXX-jar-with-dependencies.jar the C1.class comes > from the dependency, not from the source in project. > I would except the class from the source in project to override the > corresponding class in jar dependency, > So the executable jar is not built correctly. This is particularly annoying, > because the tests pass, but the executable jar is not correct. > You can see this in the test project attached, where I override class > TestCase of JUnit , adding a main , and setting this overriden class as the > main class: > % java -jar > target/maven_bug_build_override_class-1.0-SNAPSHOT-jar-with-dependencies.jar > Exception in thread "main" java.lang.NoSuchMethodError: main > ( the original class TestCase of JUnit has no main ). > In the test project attached,I kept all the Maven plugins that are in my > original project, because they might have a relation with the issue. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-728) Assembly plugin >= 2.5 thinks my group ID is too big
[ https://jira.codehaus.org/browse/MASSEMBLY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-728. Resolution: Fixed Assignee: Kristian Rosenvold Added faq entry in r1638205 > Assembly plugin >= 2.5 thinks my group ID is too big > > > Key: MASSEMBLY-728 > URL: https://jira.codehaus.org/browse/MASSEMBLY-728 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Andrew Todd >Assignee: Kristian Rosenvold > Fix For: 2.5.2 > > > My OS X user's primary group ID is quite large, around 110075129. > Up until assembly 2.4.1, I have had no troubles. However, in 2.5, I get this > error when trying to create an assembly: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.5:single > (assemble-command-line) on project crypto-monster: Execution > assemble-command-line of goal > org.apache.maven.plugins:maven-assembly-plugin:2.5:single failed: group id > '110075129' is too big ( > 2097151 ) -> [Help 1] > I am using JDK 7 to build. Have not tested with 8. > I have noticed that the error seems to be specific to assembly of a .tar.gz > artifact. Assembling a .zip file does not cause this error. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-478) allow overwriting newer files with older files contained within fileset
[
https://jira.codehaus.org/browse/MASSEMBLY-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-478.
Resolution: Fixed
Assignee: Kristian Rosenvold
The new ordering is well defined and should make solving this a breeze.
Files, filesets all come before modulesets and dependencysets in precedence.
> allow overwriting newer files with older files contained within fileset
> ---
>
> Key: MASSEMBLY-478
> URL: https://jira.codehaus.org/browse/MASSEMBLY-478
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-06 13:16:01-0600)
> Java version: 1.6.0_17
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.17/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.29-bpo.2-amd64" arch: "amd64" Family: "unix"
>Reporter: deckrider
>Assignee: Kristian Rosenvold
> Fix For: 2.5.2
>
>
> I have a situation where I want to unwind a zip file, and then overlay a few
> files in it with my own.
> I've been using the maven dependency plugin to unwind this zip file and then
> maven assembly plugin to overwrite a few of the extracted files with my own
> (generally text based configuration that I keep under source code control).
> This seems to work until my files have an earlier modification time than the
> files that I want to overwrite, in which case my own files do NOT overwite
> the others (I want my files to ALWAYS replace those in the zip file).
> Thank in advance. Here are the configuration details
> From my pom.xml:
> {code:xml}
>
> org.apache.maven.plugins
> maven-assembly-plugin
>
> false
> false
> ${project.build.directory}
> solaris
> true
>
> src/main/assembly/bin.xml
>
>
>
>
> overwrite
> process-sources
>
> directory-single
>
>
>
>
> {code}
> From my src/main/assembly/bin.xml:
> {code:xml}
>
>
> dir
>
> false
>
>
> ${basedir}/src/main/bin
> ${prefix}/jboss/bin
>
>
> ${basedir}/src/main/conf
> ${prefix}/jboss/server/wsa/conf
>
>
> ${basedir}/src/main/deploy
> ${prefix}/jboss/server/wsa/deploy
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-558) Assembly does not include runtime-dependency if test-dependency with shorter path exists
[
https://jira.codehaus.org/browse/MASSEMBLY-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed MASSEMBLY-558.
Resolution: Fixed
Assignee: Kristian Rosenvold
This has to be MASSEMBLY-395. Please reopen with a small test project if this
turns out not to be the case.
> Assembly does not include runtime-dependency if test-dependency with shorter
> path exists
>
>
> Key: MASSEMBLY-558
> URL: https://jira.codehaus.org/browse/MASSEMBLY-558
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.2
> Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
> Java version: 1.5.0_12, vendor: Sun Microsystems Inc.
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows xp", version: "5.1", arch: "x86", family: "windows"
>Reporter: Frank Jakop
>Assignee: Kristian Rosenvold
> Fix For: 2.5.2
>
>
> In my project there's an artifact, which can be resolved by 2 different paths
> (scopes in brackets)
> {noformat}
> a) Project->projA(compile)->projB(compile)->myArtifact(runtime)
> b) Project->projB(test)->myArtifact(runtime)
> {noformat}
> The relevant part of the distribution descriptor is the following
> {code:xml}
>
> zip
>
>
>
> /lib
> true
> false
> runtime
>
>
> {code}
> So when I run assembly:assembly I wonder, why myArtifact isn't included in my
> zip. I now think, that assembly favours the shorter path b) despite the
> test-scope over the longer but correct path a).
> Since test-scope dependencies should have nothing to do with distribution (if
> not included explicitly) myArtifact should have be included in my zip.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-569) The numbering of the items in the FAQ on the site is messed up
[ https://jira.codehaus.org/browse/MASSEMBLY-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MASSEMBLY-569. Resolution: Fixed Assignee: Kristian Rosenvold Given that the faq is quite small and the groupings did not add too much value, I just removed them. > The numbering of the items in the FAQ on the site is messed up > -- > > Key: MASSEMBLY-569 > URL: https://jira.codehaus.org/browse/MASSEMBLY-569 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: n/a >Reporter: Anders Hammar >Assignee: Kristian Rosenvold >Priority: Trivial > Fix For: 2.5.2 > > > The numbering in the FAQ > (http://maven.apache.org/plugins/maven-assembly-plugin/faq.html) is messed > up. The items are numbered 1,2,3,4,1,1,2,3,1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SCM-784) git add may fail on *nix with *lots and lots* of files
Stephen Connolly created SCM-784:
Summary: git add may fail on *nix with *lots and lots* of files
Key: SCM-784
URL: https://jira.codehaus.org/browse/SCM-784
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-git
Affects Versions: 1.9.2
Reporter: Stephen Connolly
Priority: Minor
SCM-697 has friends in Unix land too
http://stackoverflow.com/questions/19354870/bash-command-line-and-input-limit
So while the limit for most unixes is a lot larger than 8k, e.g. my mac is 256k
and a lot of linux machines have a 128k limit
Aside:
{{$ expr `getconf ARG_MAX` - `env|wc -c` - `env|wc -l` \* 4 - 2048}}
will tell you your limit
There still is a limit, thus it would make sense to batch the add operation
based on the size of the command line. The batch size would ideally be
configurable with a default of 120k characters for unix and 8k characters for
windows so that windows can get some batching benefits too
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5708) Maven dependency resolution inconsistent with multiple excludes
[ https://jira.codehaus.org/browse/MNG-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MNG-5708: Attachment: dependency-bug-3.tar.gz > Maven dependency resolution inconsistent with multiple excludes > --- > > Key: MNG-5708 > URL: https://jira.codehaus.org/browse/MNG-5708 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) > Maven home: /home/henning/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen > Attachments: dependency-bug-2.tar.gz, dependency-bug-3.tar.gz, > dependency-bug.tar.gz > > > This is how to reproduce the problem: > download and unpack the attached tarball. It contains three projects: > proj1 depends on log4j and commons-lang3 > proj2 is a multi module project which uses proj1. But it uses slf4j, so for > proj1 it has an exclusion in the dependency management section which excludes > log4j > module1 depends on proj1 and log4j-over-slf4j > module2 depends on proj1 > proj3 is a project that depends on module1. > enter each project one-by-one and do "mvn clean install". This works fine. So > dependency exclusion etc. works. > Now, remove the comments from the exclude block in proj2/module2/pom.xml > run "mvn clean install" in proj2. Everything still builds fine in proj2. > Same goes for "mvn clean install -pl :module2" (only build module2) and "mvn > clean install -rf :module2" (resume from module2) > now go to proj3. The build fails because there are duplicates on the > classpath. Looking at the dependency tree: > [INFO] group:proj3:jar:1-SNAPSHOT > [INFO] \- group:module1:jar:1-SNAPSHOT:compile > [INFO]+- group:proj1:jar:1-SNAPSHOT:compile > [INFO]| \- log4j:log4j:jar:1.2.7:compile > [INFO]\- org.slf4j:log4j-over-slf4j:jar:1.7.7:compile > [INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile > log4j (which was excluded in the dependencyManagement section) has reappeared! > This only happens if there are excludes in the depMgt section of a parent pom > *and* excludes in the dependency itself in a child project *and* the > dependency is referred from outside the multi module project. For an in-tree > project (such as module2), everything is fine. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5708) Maven dependency resolution inconsistent with multiple excludes
[ https://jira.codehaus.org/browse/MNG-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MNG-5708: Attachment: dependency-bug-2.tar.gz re-uploading, for whatever reason the tar.gz file was gzipped again. > Maven dependency resolution inconsistent with multiple excludes > --- > > Key: MNG-5708 > URL: https://jira.codehaus.org/browse/MNG-5708 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) > Maven home: /home/henning/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen > Attachments: dependency-bug-2.tar.gz, dependency-bug-3.tar.gz, > dependency-bug.tar.gz > > > This is how to reproduce the problem: > download and unpack the attached tarball. It contains three projects: > proj1 depends on log4j and commons-lang3 > proj2 is a multi module project which uses proj1. But it uses slf4j, so for > proj1 it has an exclusion in the dependency management section which excludes > log4j > module1 depends on proj1 and log4j-over-slf4j > module2 depends on proj1 > proj3 is a project that depends on module1. > enter each project one-by-one and do "mvn clean install". This works fine. So > dependency exclusion etc. works. > Now, remove the comments from the exclude block in proj2/module2/pom.xml > run "mvn clean install" in proj2. Everything still builds fine in proj2. > Same goes for "mvn clean install -pl :module2" (only build module2) and "mvn > clean install -rf :module2" (resume from module2) > now go to proj3. The build fails because there are duplicates on the > classpath. Looking at the dependency tree: > [INFO] group:proj3:jar:1-SNAPSHOT > [INFO] \- group:module1:jar:1-SNAPSHOT:compile > [INFO]+- group:proj1:jar:1-SNAPSHOT:compile > [INFO]| \- log4j:log4j:jar:1.2.7:compile > [INFO]\- org.slf4j:log4j-over-slf4j:jar:1.7.7:compile > [INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile > log4j (which was excluded in the dependencyManagement section) has reappeared! > This only happens if there are excludes in the depMgt section of a parent pom > *and* excludes in the dependency itself in a child project *and* the > dependency is referred from outside the multi module project. For an in-tree > project (such as module2), everything is fine. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5708) Maven dependency resolution inconsistent with multiple excludes
[ https://jira.codehaus.org/browse/MNG-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356004#comment-356004 ] Henning Schmiedehausen commented on MNG-5708: - for whatever reason, jira insists on double-gzipping the attached archive. Please unpack it with gzip -dc < dependency-bug.tar.gz | tar xzf - This seems to be a problem with the jira installation. :-( > Maven dependency resolution inconsistent with multiple excludes > --- > > Key: MNG-5708 > URL: https://jira.codehaus.org/browse/MNG-5708 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: Apache Maven 3.2.3 > (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) > Maven home: /home/henning/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen > Attachments: dependency-bug-2.tar.gz, dependency-bug-3.tar.gz, > dependency-bug.tar.gz > > > This is how to reproduce the problem: > download and unpack the attached tarball. It contains three projects: > proj1 depends on log4j and commons-lang3 > proj2 is a multi module project which uses proj1. But it uses slf4j, so for > proj1 it has an exclusion in the dependency management section which excludes > log4j > module1 depends on proj1 and log4j-over-slf4j > module2 depends on proj1 > proj3 is a project that depends on module1. > enter each project one-by-one and do "mvn clean install". This works fine. So > dependency exclusion etc. works. > Now, remove the comments from the exclude block in proj2/module2/pom.xml > run "mvn clean install" in proj2. Everything still builds fine in proj2. > Same goes for "mvn clean install -pl :module2" (only build module2) and "mvn > clean install -rf :module2" (resume from module2) > now go to proj3. The build fails because there are duplicates on the > classpath. Looking at the dependency tree: > [INFO] group:proj3:jar:1-SNAPSHOT > [INFO] \- group:module1:jar:1-SNAPSHOT:compile > [INFO]+- group:proj1:jar:1-SNAPSHOT:compile > [INFO]| \- log4j:log4j:jar:1.2.7:compile > [INFO]\- org.slf4j:log4j-over-slf4j:jar:1.7.7:compile > [INFO] \- org.slf4j:slf4j-api:jar:1.7.7:compile > log4j (which was excluded in the dependencyManagement section) has reappeared! > This only happens if there are excludes in the depMgt section of a parent pom > *and* excludes in the dependency itself in a child project *and* the > dependency is referred from outside the multi module project. For an in-tree > project (such as module2), everything is fine. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5722) maven splills exclude rules from one dependency to another
Henning Schmiedehausen created MNG-5722: --- Summary: maven splills exclude rules from one dependency to another Key: MNG-5722 URL: https://jira.codehaus.org/browse/MNG-5722 Project: Maven Issue Type: Bug Components: Dependencies Affects Versions: 3.2.3 Environment: mvn --version Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 2014-08-11T13:58:10-07:00) Maven home: /home/hschmiedehausen/.apache-maven Java version: 1.7.0_67, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: "unix" Reporter: Henning Schmiedehausen Attachments: exclude-dependency-bug.tar.gz unpack the attached archive (note HAUS-2405 for possible problems here, the file might be double-compressed). It contains four projects: projA - projD for each project run "mvn clean install". All builds succeed However, the resulting project D includes projB -> jcl-over-slf4j projC-component1 -> projC-component2 -> httpclient, which includes commons logging So the resulting project *should* fail with duplicate classes. However, the build succeeds. To make the build fail: - remove the dependency on projB from projD and rebuild. INFO] --- maven-duplicate-finder-plugin:1.0.9:check (default) @ projD --- [INFO] Checking compile classpath [WARNING] Found duplicate and different classes in [commons-logging:commons-logging:1.1.3,org.slf4j:jcl-over-slf4j:1.7.7] : [WARNING] org.apache.commons.logging.Log [WARNING] org.apache.commons.logging.LogConfigurationException [WARNING] org.apache.commons.logging.LogFactory [WARNING] org.apache.commons.logging.impl.NoOpLog [WARNING] org.apache.commons.logging.impl.SimpleLog the separate dependency trees: projB: [INFO] group:projB:jar:1-SNAPSHOT [INFO] \- group:projA:jar:1-SNAPSHOT:compile [INFO]+- commons-lang:commons-lang:jar:2.6:compile [INFO]\- org.apache.httpcomponents:httpclient:jar:4.3.6:compile [INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.3:compile [INFO] \- commons-codec:commons-codec:jar:1.6:compile projC-component1 [INFO] group:projC-component1:jar:1-SNAPSHOT [INFO] \- group:projC-component2:jar:1-SNAPSHOT:compile [INFO]\- org.apache.httpcomponents:httpclient:jar:4.3.6:compile [INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.3:compile [INFO] +- commons-logging:commons-logging:jar:1.1.3:compile [INFO] \- commons-codec:commons-codec:jar:1.6:compile projC-component1 *should* include commons-logging which in turn should clash with jcl-over-slf4j in projD (proojD depends on projB, projC-component1 and jcl-over-slf4j). However, the presence of projB excludes commons-logging from the dependencies in projC-component1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-732) baseDirectory is ignored with files entries
Phil Webb created MASSEMBLY-732:
---
Summary: baseDirectory is ignored with files entries
Key: MASSEMBLY-732
URL: https://jira.codehaus.org/browse/MASSEMBLY-732
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 2.5.1
Reporter: Phil Webb
Priority: Minor
With version 2.4 an assembly like this:
{noformat}
bin
zip
spring-${project.version}
true
${project.build.directory}/${project.artifactId}-${project.version}-full.jar
/lib
${project.build.finalName}.jar
{noformat}
would write the file inside the zip under {{spring-$\{project.version\}/lib}}.
With 2.5.1 the {{baseDir}} is ignored and files are written under {{/lib}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MSHARED-260) FileUtils.copyDirectory issue
[ https://jira.codehaus.org/browse/MSHARED-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356009#comment-356009 ] Karl-Heinz Marbaise commented on MSHARED-260: - Hi Kristian, correct looks exactly like this. > FileUtils.copyDirectory issue > - > > Key: MSHARED-260 > URL: https://jira.codehaus.org/browse/MSHARED-260 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Reporter: Kristian Rosenvold > > http://old.nabble.com/plexus-utils---maven-shared-utils---commons-io-to34671433.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-16) Upgrade maven-archiver to 2.6
Karl-Heinz Marbaise created MACR-16: --- Summary: Upgrade maven-archiver to 2.6 Key: MACR-16 URL: https://jira.codehaus.org/browse/MACR-16 Project: Maven ACR Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: Karl-Heinz Marbaise Priority: Minor Upgrade maven-archiver from 2.5 to 2.6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-16) Upgrade maven-archiver to 2.6
[ https://jira.codehaus.org/browse/MACR-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MACR-16: Fix Version/s: 1.2 > Upgrade maven-archiver to 2.6 > - > > Key: MACR-16 > URL: https://jira.codehaus.org/browse/MACR-16 > Project: Maven ACR Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.2 > > > Upgrade maven-archiver from 2.5 to 2.6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-17) Upgrade plexus-archiver 2.7.1 to 2.8.1
Karl-Heinz Marbaise created MACR-17: --- Summary: Upgrade plexus-archiver 2.7.1 to 2.8.1 Key: MACR-17 URL: https://jira.codehaus.org/browse/MACR-17 Project: Maven ACR Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: Karl-Heinz Marbaise Priority: Minor Upgrade plexus-archiver from 2.7.1 to 2.8.1 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-17) Upgrade plexus-archiver 2.7.1 to 2.8.2
[ https://jira.codehaus.org/browse/MACR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MACR-17: Description: Upgrade plexus-archiver from 2.7.1 to 2.8.2 (was: Upgrade plexus-archiver from 2.7.1 to 2.8.1) > Upgrade plexus-archiver 2.7.1 to 2.8.2 > -- > > Key: MACR-17 > URL: https://jira.codehaus.org/browse/MACR-17 > Project: Maven ACR Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.2 > > > Upgrade plexus-archiver from 2.7.1 to 2.8.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-17) Upgrade plexus-archiver 2.7.1 to 2.8.1
[ https://jira.codehaus.org/browse/MACR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MACR-17: Fix Version/s: 1.2 > Upgrade plexus-archiver 2.7.1 to 2.8.1 > -- > > Key: MACR-17 > URL: https://jira.codehaus.org/browse/MACR-17 > Project: Maven ACR Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.2 > > > Upgrade plexus-archiver from 2.7.1 to 2.8.1 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-17) Upgrade plexus-archiver 2.7.1 to 2.8.2
[ https://jira.codehaus.org/browse/MACR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MACR-17: Summary: Upgrade plexus-archiver 2.7.1 to 2.8.2 (was: Upgrade plexus-archiver 2.7.1 to 2.8.1) > Upgrade plexus-archiver 2.7.1 to 2.8.2 > -- > > Key: MACR-17 > URL: https://jira.codehaus.org/browse/MACR-17 > Project: Maven ACR Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.2 > > > Upgrade plexus-archiver from 2.7.1 to 2.8.1 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-18) Upgrade to maven-plugins version 25 to 26
Karl-Heinz Marbaise created MACR-18: --- Summary: Upgrade to maven-plugins version 25 to 26 Key: MACR-18 URL: https://jira.codehaus.org/browse/MACR-18 Project: Maven ACR Plugin Issue Type: Improvement Affects Versions: 1.2 Reporter: Karl-Heinz Marbaise Priority: Minor Upgrade maven-plugins from 25 to 26 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-18) Upgrade to maven-plugins version 25 to 26
[ https://jira.codehaus.org/browse/MACR-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MACR-18: Fix Version/s: 1.2 > Upgrade to maven-plugins version 25 to 26 > - > > Key: MACR-18 > URL: https://jira.codehaus.org/browse/MACR-18 > Project: Maven ACR Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.2 > > > Upgrade maven-plugins from 25 to 26 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5722) maven splills exclude rules from one dependency to another
[ https://jira.codehaus.org/browse/MNG-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated MNG-5722: Attachment: exclude-dependency-bug.tar.gz slightly updated version of the test > maven splills exclude rules from one dependency to another > -- > > Key: MNG-5722 > URL: https://jira.codehaus.org/browse/MNG-5722 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: mvn --version > Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; > 2014-08-11T13:58:10-07:00) > Maven home: /home/hschmiedehausen/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen > Attachments: exclude-dependency-bug.tar.gz, > exclude-dependency-bug.tar.gz > > > unpack the attached archive (note HAUS-2405 for possible problems here, the > file might be double-compressed). It contains four projects: projA - projD > for each project run "mvn clean install". All builds succeed > However, the resulting project D includes > projB -> jcl-over-slf4j > projC-component1 -> projC-component2 -> httpclient, which includes commons > logging > So the resulting project *should* fail with duplicate classes. However, the > build succeeds. > To make the build fail: > - remove the dependency on projB from projD and rebuild. > INFO] --- maven-duplicate-finder-plugin:1.0.9:check (default) @ projD --- > [INFO] Checking compile classpath > [WARNING] Found duplicate and different classes in > [commons-logging:commons-logging:1.1.3,org.slf4j:jcl-over-slf4j:1.7.7] : > [WARNING] org.apache.commons.logging.Log > [WARNING] org.apache.commons.logging.LogConfigurationException > [WARNING] org.apache.commons.logging.LogFactory > [WARNING] org.apache.commons.logging.impl.NoOpLog > [WARNING] org.apache.commons.logging.impl.SimpleLog > the separate dependency trees: > projB: > [INFO] group:projB:jar:1-SNAPSHOT > [INFO] \- group:projA:jar:1-SNAPSHOT:compile > [INFO]+- commons-lang:commons-lang:jar:2.6:compile > [INFO]\- org.apache.httpcomponents:httpclient:jar:4.3.6:compile > [INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.3:compile > [INFO] \- commons-codec:commons-codec:jar:1.6:compile > projC-component1 > [INFO] group:projC-component1:jar:1-SNAPSHOT > [INFO] \- group:projC-component2:jar:1-SNAPSHOT:compile > [INFO]\- org.apache.httpcomponents:httpclient:jar:4.3.6:compile > [INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.3:compile > [INFO] +- commons-logging:commons-logging:jar:1.1.3:compile > [INFO] \- commons-codec:commons-codec:jar:1.6:compile > projC-component1 *should* include commons-logging which in turn should clash > with jcl-over-slf4j in projD (proojD depends on projB, projC-component1 and > jcl-over-slf4j). However, the presence of projB excludes commons-logging from > the dependencies in projC-component1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5722) maven splills exclude rules from one dependency to another
[ https://jira.codehaus.org/browse/MNG-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356011#comment-356011 ] Henning Schmiedehausen commented on MNG-5722: - This seems to boil down that with projB present, the dependency for httpclient is reduced to [INFO] | \- org.apache.httpcomponents:httpclient:jar:4.3.6:compile [INFO] |+- org.apache.httpcomponents:httpcore:jar:4.3.3:compile [INFO] |\- commons-codec:commons-codec:jar:1.6:compile which then in turn is applied to the dependency loaded from projC-component2 This actually *IS* order dependent, moving the projB dependency at the end of the dependency list for projD will make the build fail, too. > maven splills exclude rules from one dependency to another > -- > > Key: MNG-5722 > URL: https://jira.codehaus.org/browse/MNG-5722 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: mvn --version > Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; > 2014-08-11T13:58:10-07:00) > Maven home: /home/hschmiedehausen/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen > Attachments: exclude-dependency-bug.tar.gz, > exclude-dependency-bug.tar.gz > > > unpack the attached archive (note HAUS-2405 for possible problems here, the > file might be double-compressed). It contains four projects: projA - projD > for each project run "mvn clean install". All builds succeed > However, the resulting project D includes > projB -> jcl-over-slf4j > projC-component1 -> projC-component2 -> httpclient, which includes commons > logging > So the resulting project *should* fail with duplicate classes. However, the > build succeeds. > To make the build fail: > - remove the dependency on projB from projD and rebuild. > INFO] --- maven-duplicate-finder-plugin:1.0.9:check (default) @ projD --- > [INFO] Checking compile classpath > [WARNING] Found duplicate and different classes in > [commons-logging:commons-logging:1.1.3,org.slf4j:jcl-over-slf4j:1.7.7] : > [WARNING] org.apache.commons.logging.Log > [WARNING] org.apache.commons.logging.LogConfigurationException > [WARNING] org.apache.commons.logging.LogFactory > [WARNING] org.apache.commons.logging.impl.NoOpLog > [WARNING] org.apache.commons.logging.impl.SimpleLog > the separate dependency trees: > projB: > [INFO] group:projB:jar:1-SNAPSHOT > [INFO] \- group:projA:jar:1-SNAPSHOT:compile > [INFO]+- commons-lang:commons-lang:jar:2.6:compile > [INFO]\- org.apache.httpcomponents:httpclient:jar:4.3.6:compile > [INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.3:compile > [INFO] \- commons-codec:commons-codec:jar:1.6:compile > projC-component1 > [INFO] group:projC-component1:jar:1-SNAPSHOT > [INFO] \- group:projC-component2:jar:1-SNAPSHOT:compile > [INFO]\- org.apache.httpcomponents:httpclient:jar:4.3.6:compile > [INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.3:compile > [INFO] +- commons-logging:commons-logging:jar:1.1.3:compile > [INFO] \- commons-codec:commons-codec:jar:1.6:compile > projC-component1 *should* include commons-logging which in turn should clash > with jcl-over-slf4j in projD (proojD depends on projB, projC-component1 and > jcl-over-slf4j). However, the presence of projB excludes commons-logging from > the dependencies in projC-component1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5722) maven splills exclude rules from one dependency to another
[ https://jira.codehaus.org/browse/MNG-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356013#comment-356013 ] Henning Schmiedehausen commented on MNG-5722: - at this point I suspect that this has to do with internal dependency resolution caching. That would also explain why it is order dependent. > maven splills exclude rules from one dependency to another > -- > > Key: MNG-5722 > URL: https://jira.codehaus.org/browse/MNG-5722 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.3 > Environment: mvn --version > Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; > 2014-08-11T13:58:10-07:00) > Maven home: /home/hschmiedehausen/.apache-maven > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-1.7.0-sun-1.7.0.67/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.16.6-200.fc20.x86_64", arch: "amd64", family: > "unix" >Reporter: Henning Schmiedehausen > Attachments: exclude-dependency-bug.tar.gz, > exclude-dependency-bug.tar.gz > > > unpack the attached archive (note HAUS-2405 for possible problems here, the > file might be double-compressed). It contains four projects: projA - projD > for each project run "mvn clean install". All builds succeed > However, the resulting project D includes > projB -> jcl-over-slf4j > projC-component1 -> projC-component2 -> httpclient, which includes commons > logging > So the resulting project *should* fail with duplicate classes. However, the > build succeeds. > To make the build fail: > - remove the dependency on projB from projD and rebuild. > INFO] --- maven-duplicate-finder-plugin:1.0.9:check (default) @ projD --- > [INFO] Checking compile classpath > [WARNING] Found duplicate and different classes in > [commons-logging:commons-logging:1.1.3,org.slf4j:jcl-over-slf4j:1.7.7] : > [WARNING] org.apache.commons.logging.Log > [WARNING] org.apache.commons.logging.LogConfigurationException > [WARNING] org.apache.commons.logging.LogFactory > [WARNING] org.apache.commons.logging.impl.NoOpLog > [WARNING] org.apache.commons.logging.impl.SimpleLog > the separate dependency trees: > projB: > [INFO] group:projB:jar:1-SNAPSHOT > [INFO] \- group:projA:jar:1-SNAPSHOT:compile > [INFO]+- commons-lang:commons-lang:jar:2.6:compile > [INFO]\- org.apache.httpcomponents:httpclient:jar:4.3.6:compile > [INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.3:compile > [INFO] \- commons-codec:commons-codec:jar:1.6:compile > projC-component1 > [INFO] group:projC-component1:jar:1-SNAPSHOT > [INFO] \- group:projC-component2:jar:1-SNAPSHOT:compile > [INFO]\- org.apache.httpcomponents:httpclient:jar:4.3.6:compile > [INFO] +- org.apache.httpcomponents:httpcore:jar:4.3.3:compile > [INFO] +- commons-logging:commons-logging:jar:1.1.3:compile > [INFO] \- commons-codec:commons-codec:jar:1.6:compile > projC-component1 *should* include commons-logging which in turn should clash > with jcl-over-slf4j in projD (proojD depends on projB, projC-component1 and > jcl-over-slf4j). However, the presence of projB excludes commons-logging from > the dependencies in projC-component1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-730) jar-with-dependencies : a file in a dependency is overridden by the same file in JDK / JRE
[
https://jira.codehaus.org/browse/MASSEMBLY-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356014#comment-356014
]
Guillaume Husta commented on MASSEMBLY-730:
---
Great work ! Wunderbar ;-)
Thanks
> jar-with-dependencies : a file in a dependency is overridden by the same file
> in JDK / JRE
> --
>
> Key: MASSEMBLY-730
> URL: https://jira.codehaus.org/browse/MASSEMBLY-730
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: predefined descriptors
>Affects Versions: 2.5, 2.5.1
> Environment: JDK 6
> Maven 3.0.4
> Linux / Windows
>Reporter: Guillaume Husta
>Assignee: Kristian Rosenvold
> Fix For: 2.5.2
>
>
> Since version 2.5, when I try to make a "jar-with-dependencies" with the
> "single" goal, I get a strange mistake.
> A file in a dependency (a JDBC driver in my example) is overridden by a file
> with the same path / name included in a dependency from the JDK / JRE (in my
> example jre/lib/resources.jar).
> In my example, I just add the dependency
> _org.postgresql:postgresql:9.3-1102-jdbc4_ to my POM.
> Then I package to make a "jar-with-dependencies".
> I can find the file _META-INF/services/java.sql.Driver_ in this jar.
> But with the version 2.5 of plugin assembly, it contains
> * {{sun.jdbc.odbc.JdbcOdbcDriver}} (originated from JRE : resources.jar)
> and with version 2.4.1 of the plugin, it contains
> * {{org.postgresql.Driver}} (originated from postgresql-9.3-1102-jdbc4.jar),
> what I expect
> In the previous version (2.4.1) there was no problem.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1115) StringIndexOutOfBoundsException: String index out of range: 26
[ https://jira.codehaus.org/browse/SUREFIRE-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1115: -- Assignee: Tibor Digana > StringIndexOutOfBoundsException: String index out of range: 26 > -- > > Key: SUREFIRE-1115 > URL: https://jira.codehaus.org/browse/SUREFIRE-1115 > Project: Maven Surefire > Issue Type: Bug > Components: process forking >Affects Versions: 2.18 > Environment: JDK 7, Maven 3.2.1 >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Critical > Attachments: log.txt > > > Changed the property shadedVersion=2.18 in the POM of Maven-Surefire-Project. > Launched the project build with mvn install. > Caused by: java.lang.RuntimeException: > java.lang.StringIndexOutOfBoundsException: String index out of range: 26 > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer.close(ThreadedStreamConsumer.java:124) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:491) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:378) > at > org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:165) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1019) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:853) > at > org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:751) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1116) Parallel Computer should use ConsoleLogger interface
Tibor Digana created SUREFIRE-1116: -- Summary: Parallel Computer should use ConsoleLogger interface Key: SUREFIRE-1116 URL: https://jira.codehaus.org/browse/SUREFIRE-1116 Project: Maven Surefire Issue Type: Improvement Components: Junit 4.7+ (parallel) support Affects Versions: 2.18 Reporter: Tibor Digana The interface ConsoleLogger should be programatically used instead of System.out. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1116) Parallel Computer should use ConsoleLogger interface
[ https://jira.codehaus.org/browse/SUREFIRE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1116: -- Assignee: Tibor Digana > Parallel Computer should use ConsoleLogger interface > > > Key: SUREFIRE-1116 > URL: https://jira.codehaus.org/browse/SUREFIRE-1116 > Project: Maven Surefire > Issue Type: Improvement > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.18 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > The interface ConsoleLogger should be programatically used instead of > System.out. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1116) Parallel Computer should use ConsoleLogger interface
[ https://jira.codehaus.org/browse/SUREFIRE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1116: --- Fix Version/s: 2.19 > Parallel Computer should use ConsoleLogger interface > > > Key: SUREFIRE-1116 > URL: https://jira.codehaus.org/browse/SUREFIRE-1116 > Project: Maven Surefire > Issue Type: Improvement > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.18 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > The interface ConsoleLogger should be programatically used instead of > System.out. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1116) Parallel Computer should use ConsoleLogger interface
[ https://jira.codehaus.org/browse/SUREFIRE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1116. -- Resolution: Fixed commit 1c34e05bdb5b69a513a8a29bb1018bf3cc8d9c69 > Parallel Computer should use ConsoleLogger interface > > > Key: SUREFIRE-1116 > URL: https://jira.codehaus.org/browse/SUREFIRE-1116 > Project: Maven Surefire > Issue Type: Improvement > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.18 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19 > > > The interface ConsoleLogger should be programatically used instead of > System.out. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-437) Provide an option to log to the console on every test method
[ https://jira.codehaus.org/browse/SUREFIRE-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=356021#comment-356021 ] Tibor Digana commented on SUREFIRE-437: --- Karl, you can switch off the printed summary on console and redirect the logs to a file per test case. This would be enough correlation in my guess. Did you try to change the plugin config? Anyway you can guys provide a solution on GitHub or you can open a discussion at the Maven mailing list with your concrete proposal and we can discuss it there with many developers. > Provide an option to log to the console on every test method > > > Key: SUREFIRE-437 > URL: https://jira.codehaus.org/browse/SUREFIRE-437 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Plugin >Reporter: Dan Fabulich > Fix For: Backlog > > > We already log to the console whenever we regain control from the testing > framework; in JUnit directory suites, that's once per class, which is pretty > often, but if you use JUnit TestSuites or TestNG, we lose control at the > start of the run and don't get it back until the end of the run. > We should provide an option to log to the console after every test case > method. It should probably be off by default...? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-18) Upgrade to maven-plugins version 25 to 26
[ https://jira.codehaus.org/browse/MACR-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MACR-18. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1638681|http://svn.apache.org/r1638681] > Upgrade to maven-plugins version 25 to 26 > - > > Key: MACR-18 > URL: https://jira.codehaus.org/browse/MACR-18 > Project: Maven ACR Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.2 > > > Upgrade maven-plugins from 25 to 26 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-16) Upgrade maven-archiver to 2.6
[ https://jira.codehaus.org/browse/MACR-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MACR-16. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1638682|http://svn.apache.org/r1638682] > Upgrade maven-archiver to 2.6 > - > > Key: MACR-16 > URL: https://jira.codehaus.org/browse/MACR-16 > Project: Maven ACR Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.2 > > > Upgrade maven-archiver from 2.5 to 2.6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MACR-17) Upgrade plexus-archiver 2.7.1 to 2.8.2
[ https://jira.codehaus.org/browse/MACR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MACR-17. --- Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1638683|http://svn.apache.org/r1638683] > Upgrade plexus-archiver 2.7.1 to 2.8.2 > -- > > Key: MACR-17 > URL: https://jira.codehaus.org/browse/MACR-17 > Project: Maven ACR Plugin > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Karl-Heinz Marbaise >Assignee: Karl-Heinz Marbaise >Priority: Minor > Fix For: 1.2 > > > Upgrade plexus-archiver from 2.7.1 to 2.8.2 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MASSEMBLY-732) baseDirectory is ignored with files entries
[
https://jira.codehaus.org/browse/MASSEMBLY-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated MASSEMBLY-732:
-
Fix Version/s: 2.5.2
> baseDirectory is ignored with files entries
> ---
>
> Key: MASSEMBLY-732
> URL: https://jira.codehaus.org/browse/MASSEMBLY-732
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.5.1
>Reporter: Phil Webb
>Priority: Minor
> Fix For: 2.5.2
>
>
> With version 2.4 an assembly like this:
> {noformat}
>
> bin
>
> zip
>
> spring-${project.version}
> true
>
>
>
> ${project.build.directory}/${project.artifactId}-${project.version}-full.jar
> /lib
> ${project.build.finalName}.jar
>
>
>
> {noformat}
> would write the file inside the zip under
> {{spring-$\{project.version\}/lib}}. With 2.5.1 the {{baseDir}} is ignored
> and files are written under {{/lib}}.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-731) Assembly plugin bundles symlinks as emtpy folders
[ https://jira.codehaus.org/browse/MASSEMBLY-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MASSEMBLY-731: - Fix Version/s: 2.5.2 > Assembly plugin bundles symlinks as emtpy folders > - > > Key: MASSEMBLY-731 > URL: https://jira.codehaus.org/browse/MASSEMBLY-731 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.5, 2.5.1 > Environment: linux, ubuntu, OS X >Reporter: Hitanjan Sarkar > Fix For: 2.5.2 > > > The Maven Assembly plugin (v2.5) should bundle symlinks correctly while > assembling resources. > (As per the resolved issue - https://jira.codehaus.org/browse/MASSEMBLY-343) > With v2.4, it was dereferencing and resolving all such symlinks. > With v2.5, it is bundling those symlinks as empty directories. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
