[jira] [Commented] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16770398#comment-16770398 ] Tomer Cohen commented on MNG-6236: -- [~michael-o] Yes, I have not encountered the issue since, I believe this can be closed. Thanks! > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen >Priority: Major > Fix For: wontfix-candidate > > Attachments: maven-metadata-local.xml, stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies
[ https://issues.apache.org/jira/browse/MASSEMBLY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16525763#comment-16525763 ] Tomer Cohen commented on MASSEMBLY-675: --- Any ETA on when this version will be released? > Maven Assembly packaging wildcard-excluded dependencies > --- > > Key: MASSEMBLY-675 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-675 > Project: Maven Assembly Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Apache Maven 3.1.1 > Java version: 1.7.0_45, vendor: Oracle Corporation > OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac" >Reporter: Frank Wilson >Assignee: Guillaume Boué >Priority: Major > Fix For: 3.1.1 > > Attachments: massembly-675.zip > > > Version 2.4 ignores wildcard exclusions in POM dependencies > Example (perhaps contrived - but easy to setup): > When a pom declares a dependency such as closure-compiler and for some reason > we do not want to pull its dependencies in we could declare this in our POM, > without having to know what those dependencies are: > > > com.google.javascript > closure-compiler > v20131014 > > > * > * > > > > > This is a valid use of the exclusion feature as per [Maven > Confluence|http://docs.codehaus.org/display/MAVENUSER/wildcard+exclusion+for+artifact+dependencies], > [MNG-3832|https://jira.codehaus.org/browse/MNG-3832]. False warning about > wildcards were > [fixed|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=65c135d5] > in Git about 10 days ago > Here is the assembly descriptor: > > bin > > dir > > false > > > > > We expect to only find the current project artifact and the closure-compiler > JAR in our directory assembly. However the assembly plugin ignores our POM > directive and includes the closure-compilers dependencies anyway! > Steps to reproduce are: > $ unzip massembly-675.zip > $ cd massembly-675 > $ mvn clean install > $ ls target/massembly-675-1-bin > args4j-2.0.16.jar json-20090211.jar > protobuf-java-2.4.1.jar > closure-compiler-v20131014.jar jsr305-1.3.9.jar > guava-15.0.jar massembly-675-1.jar > *Notice that the excluded jars are included in the assembly* > I would expect to only see the following JARs. > * closure-compiler-v20131014.jar > * massembly-675-1.jar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MINVOKER-224) Unable to set cloneProjectsTo to null
[
https://issues.apache.org/jira/browse/MINVOKER-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16475719#comment-16475719
]
Tomer Cohen commented on MINVOKER-224:
--
[~olamy] Is there an ETA for when the version (which I see right now is stamped
as 3.1.0) is to be released? Thanks!
> Unable to set cloneProjectsTo to null
> -
>
> Key: MINVOKER-224
> URL: https://issues.apache.org/jira/browse/MINVOKER-224
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0, 3.0.1
>Reporter: Phillip Webb
>Assignee: Olivier Lamy (*$^¨%`£)
>Priority: Major
> Fix For: 3.1.0
>
>
> [MINVOKER-219|https://issues.apache.org/jira/browse/MINVOKER-219] changed the
> default value of {{cloneProjectsTo}} to {{target/its}}. This change
> unfortunately now makes it impossible to have a {{null}} value, meaning that
> in-place invocation is no longer supported. From the Javadoc:
> {quote}Directory to which projects should be cloned prior to execution. If
> set to null, each integration test will be run in the directory in which the
> corresponding IT POM was found. In this case, you most likely want to
> configure your SCM to ignore target and build.log in the test's base
> directory.{quote}
> Is it possible to revert this change, or to provide a alternative property to
> allow cloning to be skipped?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025220#comment-16025220 ] Tomer Cohen commented on MNG-6236: -- It happens randomly (mostly depends on the number if concurrent builds). I've set the log level as you asked, next time it happens I will attach the debug log. > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen > Attachments: maven-metadata-local.xml, stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16025080#comment-16025080 ] Tomer Cohen commented on MNG-6236: -- oye vey my bad! I corrected it with the proper corruct file. Throwing away does work, but since it happens spontaneously it can be quite annoying. > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen > Attachments: maven-metadata-local.xml, stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomer Cohen updated MNG-6236: - Attachment: maven-metadata-local.xml > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen > Attachments: maven-metadata-local.xml, stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomer Cohen updated MNG-6236: - Attachment: (was: maven-metadata-local.xml) > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen > Attachments: maven-metadata-local.xml, stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomer Cohen updated MNG-6236: - Attachment: maven-metadata-local.xml > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen > Attachments: maven-metadata-local.xml, stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
[ https://issues.apache.org/jira/browse/MNG-6236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16021045#comment-16021045 ] Tomer Cohen commented on MNG-6236: -- Shalom! The goals are "clean install" (from multiple jobs that may run simultaneously). Attached is the offending file, with information sanitized. > maven-metadata-local.xml polluted with whitespaces > -- > > Key: MNG-6236 > URL: https://issues.apache.org/jira/browse/MNG-6236 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0 >Reporter: Tomer Cohen > Attachments: stacktrace.txt > > > After starting to use Maven 3.5.0 multiple instances of the attached > exceptions started occurring when multiple builds are using and installing > modules of the same reactor. I sanitized the module name. > Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
Tomer Cohen created MNG-6236: Summary: maven-metadata-local.xml polluted with whitespaces Key: MNG-6236 URL: https://issues.apache.org/jira/browse/MNG-6236 Project: Maven Issue Type: Bug Affects Versions: 3.5.0 Reporter: Tomer Cohen Attachments: stacktrace.txt After starting to use Maven 3.5.0 multiple instances of the attached exceptions started occurring when multiple builds are using and installing modules of the same reactor. I sanitized the module name. Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MJAR-223) classpathLayoutType is not taken into account when building the classpath attribute in the manifest
[ https://issues.apache.org/jira/browse/MJAR-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15295552#comment-15295552 ] Tomer Cohen commented on MJAR-223: -- I've attached a sample project that illustrates this problem. If the version of the jar plugin is changed between 3.0.0 and 2.6 and a clean install is run, the classpath attribute in the manifest is different (the 2.6 version is the correct result). Also, I've not changed the customClasspathLayout (never had to) > classpathLayoutType is not taken into account when building the classpath > attribute in the manifest > --- > > Key: MJAR-223 > URL: https://issues.apache.org/jira/browse/MJAR-223 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Tomer Cohen > Attachments: jar-test.zip > > > After upgrading to version 3.0.0 of the jar plugin, the "classpathLayoutType" > is not taken into account and is always of type "repository" even if set > differently (e.g. "simple). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MJAR-223) classpathLayoutType is not taken into account when building the classpath attribute in the manifest
[ https://issues.apache.org/jira/browse/MJAR-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomer Cohen updated MJAR-223: - Attachment: jar-test.zip > classpathLayoutType is not taken into account when building the classpath > attribute in the manifest > --- > > Key: MJAR-223 > URL: https://issues.apache.org/jira/browse/MJAR-223 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Tomer Cohen > Attachments: jar-test.zip > > > After upgrading to version 3.0.0 of the jar plugin, the "classpathLayoutType" > is not taken into account and is always of type "repository" even if set > differently (e.g. "simple). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MJAR-223) classpathLayoutType is not taken into account when building the classpath attribute in the manifest
[ https://issues.apache.org/jira/browse/MJAR-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15290006#comment-15290006 ] Tomer Cohen commented on MJAR-223: -- [~khmarbaise] I upgraded from version 2.6. The configuration is within the maven archiver as documented here: https://maven.apache.org/shared/maven-archiver/ > classpathLayoutType is not taken into account when building the classpath > attribute in the manifest > --- > > Key: MJAR-223 > URL: https://issues.apache.org/jira/browse/MJAR-223 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Tomer Cohen > > After upgrading to version 3.0.0 of the jar plugin, the "classpathLayoutType" > is not taken into account and is always of type "repository" even if set > differently (e.g. "simple). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MJAR-223) classpathLayoutType is not taken into account when building the classpath attribute in the manifest
Tomer Cohen created MJAR-223: Summary: classpathLayoutType is not taken into account when building the classpath attribute in the manifest Key: MJAR-223 URL: https://issues.apache.org/jira/browse/MJAR-223 Project: Maven JAR Plugin Issue Type: Bug Affects Versions: 3.0.0 Reporter: Tomer Cohen After upgrading to version 3.0.0 of the jar plugin, the "classpathLayoutType" is not taken into account and is always of type "repository" even if set differently (e.g. "simple). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-762) Assembly plugin doesn't exclude transitive dependencies when excluded by wildcards in dependencies section
[
https://issues.apache.org/jira/browse/MASSEMBLY-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15152392#comment-15152392
]
Tomer Cohen commented on MASSEMBLY-762:
---
Hi Team,
Will a fix for this be included in the next version of the plugin?
The problem is when there are many exclusions for a certain artifact, the pom
can become quite verbose, and a wildcard is a much neater solution.
Thanks! :)
> Assembly plugin doesn't exclude transitive dependencies when excluded by
> wildcards in dependencies section
> --
>
> Key: MASSEMBLY-762
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-762
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.3
>Reporter: Denis Goihburg
>
> On goal assembly:single with pom file:
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> MyTests
> Tests
> pom
> 1.0-SNAPSHOT
>
>
> org.springframework
> spring-core
> 4.1.0.RELEASE
>
>
> *
> *
>
>
>
>
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.5.3
>
>
> jar-with-dependencies
>
>
>
>
>
>
> {code}
> transitive dependency commons-logging appears in resulting jar.
> When wildcard is replaced with specific dependency:
> {code:xml}
>
>
> org.springframework
> spring-core
> 4.1.0.RELEASE
>
>
> commons-logging
> commons-logging
>
>
>
>
>
> {code}
> the plugin works as expected and doesn't add this dependency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MASSEMBLY-675) Maven Assembly packaging wildcard-excluded dependencies
[ https://issues.apache.org/jira/browse/MASSEMBLY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14491824#comment-14491824 ] Tomer Cohen commented on MASSEMBLY-675: --- +1 for this issue Maven Assembly packaging wildcard-excluded dependencies --- Key: MASSEMBLY-675 URL: https://issues.apache.org/jira/browse/MASSEMBLY-675 Project: Maven Assembly Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Apache Maven 3.1.1 Java version: 1.7.0_45, vendor: Oracle Corporation OS name: mac os x, version: 10.8.4, arch: x86_64, family: mac Reporter: Frank Wilson Assignee: John Casey Attachments: massembly-675.zip Version 2.4 ignores wildcard exclusions in POM dependencies Example (perhaps contrived - but easy to setup): When a pom declares a dependency such as closure-compiler and for some reason we do not want to pull its dependencies in we could declare this in our POM, without having to know what those dependencies are: dependencies dependency groupIdcom.google.javascript/groupId artifactIdclosure-compiler/artifactId versionv20131014/version exclusions exclusion artifactId*/artifactId groupId*/groupId /exclusion /exclusions /dependency /dependencies This is a valid use of the exclusion feature as per [Maven Confluence|http://docs.codehaus.org/display/MAVENUSER/wildcard+exclusion+for+artifact+dependencies], [MNG-3832|https://jira.codehaus.org/browse/MNG-3832]. False warning about wildcards were [fixed|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h=65c135d5] in Git about 10 days ago Here is the assembly descriptor: assembly idbin/id formats formatdir/format /formats includeBaseDirectoryfalse/includeBaseDirectory dependencySets dependencySet/ /dependencySets /assembly We expect to only find the current project artifact and the closure-compiler JAR in our directory assembly. However the assembly plugin ignores our POM directive and includes the closure-compilers dependencies anyway! Steps to reproduce are: $ unzip massembly-675.zip $ cd massembly-675 $ mvn clean install $ ls target/massembly-675-1-bin args4j-2.0.16.jar json-20090211.jar protobuf-java-2.4.1.jar closure-compiler-v20131014.jar jsr305-1.3.9.jar guava-15.0.jar massembly-675-1.jar *Notice that the excluded jars are included in the assembly* I would expect to only see the following JARs. * closure-compiler-v20131014.jar * massembly-675-1.jar -- This message was sent by Atlassian JIRA (v6.3.4#6332)
