[jira] [Commented] (MSHARED-494) Impossible to generate a reproducible build due to timestamp in pom.properties

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHARED-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357008#comment-15357008
 ] 

Kristian Rosenvold commented on MSHARED-494:


The archiver uses a default multihtreaded implementation which will also 
guarantee you a race wrt the order of your files.

> Impossible to generate a reproducible build due to timestamp in pom.properties
> --
>
> Key: MSHARED-494
> URL: https://issues.apache.org/jira/browse/MSHARED-494
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-archiver
>Affects Versions: maven-archiver-3.0.0
>Reporter: Emanuele Tagliaferri
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: maven-archiver-3.1.0
>
>
> Try to making a pom for do a reproducible build, meaning by reproducible 
> build the ability to produce the exact same artifact (same checksum) starting 
> from the same code, a two different times, i had some trouble with the files 
> generated in: /META-INF/maven/groupId/artifactId/ 
> in the specific the  /META-INF/maven/groupId/artifactId/pom.properties 
> contains the timestamp.
> digging in the code in the class: 
> http://svn.apache.org/viewvc/maven/shared/tags/maven-archiver-3.0.0/src/main/java/org/apache/maven/archiver/PomPropertiesUtil.java?revision=1708674=markup
> line 86
> is used the java.util.Properties#store which write the timestamp in any case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MDEP-471) Java 8 Method references are not detected

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15268046#comment-15268046
 ] 

Kristian Rosenvold commented on MDEP-471:
-

You should try the latest Snapshot version, it may do the trick for you...

> Java 8 Method references are not detected
> -
>
> Key: MDEP-471
> URL: https://issues.apache.org/jira/browse/MDEP-471
> Project: Maven Dependency Plugin
>  Issue Type: Bug
>  Components: analyze
>Affects Versions: 2.9
> Environment: Mac OSX 
> 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun  3 21:27:35 PDT 2014; 
> root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
>Reporter: Ben Hardy
>
> It is possible to get the depedency plugin to fail to recognize methods 
> references.
> For example, the following function declaration is the only place in its 
> class where the Guava "Lists" class is referenced (apart from imports):
> public static  SequenceMap forStringKeys() {
> return new SequenceMap<>(Lists::charactersOf);
> }
> We choose to fail when declared dependencies are thought to be unused, and 
> this usage is simply not detected, resulting in the following output and 
> exception:
> [WARNING] Unused declared dependencies found:
> [WARNING]com.google.guava:guava:jar:18.0:compile
> [INFO] 
> 
> Caused by: org.apache.maven.plugin.MojoExecutionException: Dependency 
> problems found
>   at 
> org.apache.maven.plugin.dependency.analyze.AbstractAnalyzeMojo.execute(AbstractAnalyzeMojo.java:187)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> Will try to get a test and patch attached to this once I figure out where 
> your test case class file resources are coming from.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MSOURCES-94) Heap space OOM

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSOURCES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15196831#comment-15196831
 ] 

Kristian Rosenvold commented on MSOURCES-94:


How much more memory does it actually require, and how many CPU cores do you 
have ?

> Heap space OOM
> --
>
> Key: MSOURCES-94
> URL: https://issues.apache.org/jira/browse/MSOURCES-94
> Project: Maven Source Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Java version: 1.8.0_74, vendor: Oracle Corporation
> OS name: "linux", version: "3.19.0-32-generic", arch: "amd64", family: "unix"
>Reporter: Stephan Schroevers
>
> After upgrading from version 2.4 to 3.0.0 our aggregate build (comprising 52 
> jar/war modules) started failing when run on Travis CI:
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-source-plugin:3.0.0:jar-no-fork 
> (generate-source-jar) on project etl-executor-impl: Error creating source 
> archive: Problem creating jar: Execution exception: Java heap space -> [Help 
> 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-source-plugin:3.0.0:jar-no-fork 
> (generate-source-jar) on project etl-executor-impl: Error creating source 
> archive: Problem creating jar: Execution exception
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> at 
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating 
> source archive: Problem creating jar: Execution exception
> at 
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:311)
> at 
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:253)
> at 
> org.apache.maven.plugins.source.AbstractSourceJarMojo.execute(AbstractSourceJarMojo.java:216)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 11 more
> Caused by: org.codehaus.plexus.archiver.ArchiverException: Problem creating 
> jar: Execution exception
> at 
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:982)
> at 
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:650)
> at 
> org.apache.maven.plugins.source.AbstractSourceJarMojo.packageSources(AbstractSourceJarMojo.java:303)
> ... 15 more
> Caused by: java.io.IOException: Execution exception
> at 
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.close(AbstractZipArchiver.java:807)
> at 
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:969)
> ... 17 more
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at 
> org.codehaus.plexus.archiver.zip.ByteArrayOutputStream.needNewBuffer(ByteArrayOutputStream.java:121)
> at 
> org.codehaus.plexus.archiver.zip.ByteArrayOutputStream.(ByteArrayOutputStream.java:90)
> at 
> org.codehaus.plexus.archiver.zip.OffloadingOutputStream.(OffloadingOutputStream.java:109)
> at 
> org.codehaus.plexus.archiver.zip.OffloadingOutputStream.(OffloadingOutputStream.java:89)
> at 
> org.codehaus.plexus.archiver.zip.DeferredScatterOutputStream.(DeferredScatterOutputStream.java:28)
> at 
> org.codehaus.plexus.archiver.zip.ConcurrentJarCreator$DeferredSupplier.get(ConcurrentJarCreator.java:47)
> at 
> org.apache.commons.compress.archivers.zip.ParallelScatterZipCreator.createDeferred(ParallelScatterZipCreator.java:75)
> at 
> 

[jira] [Assigned] (MASSEMBLY-774) too many open files

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold reassigned MASSEMBLY-774:


Assignee: Kristian Rosenvold

> too many open files
> ---
>
> Key: MASSEMBLY-774
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-774
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.5.5
>Reporter: Dan Armbrust
>Assignee: Kristian Rosenvold
>
> I ran across this - 
> http://mail-archives.apache.org/mod_mbox/maven-dev/201501.mbox/%3ca2ee0d04-04e3-4c99-8842-673463862...@takari.io%3E
>  - and since I'm making huge zip files, I thought I would give it a try.
> I configured as:
> 
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.5.5
> 
> 
> org.codehaus.plexus
> plexus-archiver
> 3.0.1
> 
> 
> org.codehaus.plexus
> plexus-io
> 2.6
> 
> 
> 
> But this lead to a failure:
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (zip) on project 
> ... sememe/seg.3182.sememe.map (Too many open files) -> [Help 1]
> I certainly could raise my ulimit:
> darmbrust@overkill:/mnt/STORAGE/Work/Apelon/Workspaces/ISAAC-Core-2/va-solor-goods$
>  ulimit -a
> ...
> open files  (-n) 1024
> But it seems it would be better if the zip process limited itself to a 
> reasonable number of open files.  I don't know the algorithm... but it seems 
> that double or triple the processor count would be more than enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076470#comment-15076470
 ] 

Kristian Rosenvold commented on MRESOURCES-171:
---

Aaron is right

> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
>  Issue Type: Bug
>  Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u 
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to 
> be converted into UTF-8 in the jar.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MSHARED-428) maven-dependency-analyzer does not detect method references

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHARED-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15075245#comment-15075245
 ] 

Kristian Rosenvold commented on MSHARED-428:


https://bugs.openjdk.java.net/browse/JDK-7153958


> maven-dependency-analyzer does not detect method references
> ---
>
> Key: MSHARED-428
> URL: https://issues.apache.org/jira/browse/MSHARED-428
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.6
>Reporter: Jonathan Haber
>Assignee: Kristian Rosenvold
> Fix For: maven-dependency-analyzer-1.7
>
>
> maven-dependency-analyzer doesn't seem to pick up on method reference usages. 
> When using the maven-dependency-plugin, if the only usage of a dependency is 
> via a method reference, this causes erroneous unused dependency errors that 
> fail our build. 
> I updated the maven-dependency-analyzer tests to fail and pushed it to our 
> fork:
> https://github.com/HubSpot/maven-shared/commit/d5ffacb808fba01837c644f2045a79eab50fecbf
> Changing from a method reference to a lambda or anonymous class makes the 
> test pass again.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MJAR-205) Compatibility with JDK9 requires an update of plexus-archiver

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MJAR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15052708#comment-15052708
 ] 

Kristian Rosenvold commented on MJAR-205:
-

There's a couple of other issues that need to be fixed in archiver, give it a 
few days :)

> Compatibility with JDK9 requires an update of plexus-archiver
> -
>
> Key: MJAR-205
> URL: https://issues.apache.org/jira/browse/MJAR-205
> Project: Maven JAR Plugin
>  Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Sanne Grinovero
>  Labels: java9
> Fix For: 3.0.0
>
>
> The Maven Jar plugin will fail when running on Java 9 since preview build 95 
> (since inclusion of project Verona) because of a small issue in the used 
> version of plexus-archiver.
> See also:
>  - https://github.com/codehaus-plexus/plexus-archiver/issues/13
> The trivial fix was merged:
>  - https://github.com/codehaus-plexus/plexus-archiver/pull/12
> This is to track the need for an update to a `plexus-archiver` version 
> including  the above patches. Would love to see a Maven release including 
> this too, so that we can use our project's existing testsuites to test for 
> Java9 compatibility ASAP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSHARED-297) Commandline class shell injection vulnerabilities

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MSHARED-297:
---
Component/s: maven-shared-utils

> Commandline class shell injection vulnerabilities
> -
>
> Key: MSHARED-297
> URL: https://issues.apache.org/jira/browse/MSHARED-297
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-shared-utils
>Reporter: Charles Duffy
> Attachments: use-no-shell-r2.patch
>
>
> The Commandline class can emit double-quoted strings without proper escaping, 
> allowing shell injection attacks.
> The BourneShell class should unconditionally single-quote emitted strings 
> (including the name of the command itself being quoted), with {{'"'"'}} used 
> for embedded single quotes, for maximum safety across shells implementing a 
> superset of POSIX quoting rules.
> An appropriate fix has been built and applied against PLXUTILS; that patch is 
> submitted here in the hope that it will be useful, though it is not expected 
> to apply to the maven-shared-utils codebase without modification.
> See PLXUTILS-161 for history/discussion.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSHARED-416) Odd number of quotes in command-line fails

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MSHARED-416:
---
Component/s: maven-shared-utils

> Odd number of quotes in command-line fails
> --
>
> Key: MSHARED-416
> URL: https://issues.apache.org/jira/browse/MSHARED-416
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-shared-utils
>Reporter: Eric Citaire
> Attachments: QuoteTest.java
>
>
> When using org.apache.maven.shared.utils.cli.Commandline, if the command 
> contains a single-quote, the execution fails with output :
> {{/bin/sh: 1: Syntax error: Unterminated quoted string}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MSHARED-317) Analyzer reports unused dependencies between modules in multi-module project

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHARED-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15041622#comment-15041622
 ] 

Kristian Rosenvold commented on MSHARED-317:


The JDK8 fixes in r1717974 will solve this issue for jdk8 users. It should be 
possible to solve this for earlier versions if someone does the job.

> Analyzer reports unused dependencies between modules in multi-module project
> 
>
> Key: MSHARED-317
> URL: https://issues.apache.org/jira/browse/MSHARED-317
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.4
>Reporter: Krzysztof Krason
>
> I have  Multi module project:
> parent
>  - exception
>  - exception-user
> In "exception-user" I added dependency on "exception" and throw given 
> exception in one class.
> Depdencency analyzer reports that dependency on "exception" is unused.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MSHARED-428) maven-dependency-analyzer does not detect method references

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MSHARED-428.
--
Resolution: Fixed
  Assignee: Kristian Rosenvold

Fixed in r1717974

> maven-dependency-analyzer does not detect method references
> ---
>
> Key: MSHARED-428
> URL: https://issues.apache.org/jira/browse/MSHARED-428
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.6
>Reporter: Jonathan Haber
>Assignee: Kristian Rosenvold
>
> maven-dependency-analyzer doesn't seem to pick up on method reference usages. 
> When using the maven-dependency-plugin, if the only usage of a dependency is 
> via a method reference, this causes erroneous unused dependency errors that 
> fail our build. 
> I updated the maven-dependency-analyzer tests to fail and pushed it to our 
> fork:
> https://github.com/HubSpot/maven-shared/commit/d5ffacb808fba01837c644f2045a79eab50fecbf
> Changing from a method reference to a lambda or anonymous class makes the 
> test pass again.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSHARED-428) maven-dependency-analyzer does not detect method references

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MSHARED-428:
---
Fix Version/s: maven-dependency-analyzer-1.7

> maven-dependency-analyzer does not detect method references
> ---
>
> Key: MSHARED-428
> URL: https://issues.apache.org/jira/browse/MSHARED-428
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-dependency-analyzer
>Affects Versions: maven-dependency-analyzer-1.6
>Reporter: Jonathan Haber
>Assignee: Kristian Rosenvold
> Fix For: maven-dependency-analyzer-1.7
>
>
> maven-dependency-analyzer doesn't seem to pick up on method reference usages. 
> When using the maven-dependency-plugin, if the only usage of a dependency is 
> via a method reference, this causes erroneous unused dependency errors that 
> fail our build. 
> I updated the maven-dependency-analyzer tests to fail and pushed it to our 
> fork:
> https://github.com/HubSpot/maven-shared/commit/d5ffacb808fba01837c644f2045a79eab50fecbf
> Changing from a method reference to a lambda or anonymous class makes the 
> test pass again.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MSHADE-213) Clarify contract of ResourceTransformer wrt closing of streams

[Kristian Rosenvold (JIRA)]

Kristian Rosenvold created MSHADE-213:
-

 Summary: Clarify contract of ResourceTransformer wrt closing of 
streams
 Key: MSHADE-213
 URL: https://issues.apache.org/jira/browse/MSHADE-213
 Project: Maven Shade Plugin
  Issue Type: Improvement
Reporter: Kristian Rosenvold






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MSHADE-171) "Access Denied" on Windows because shade plugin seems to try to open a directory as Zip-File

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MSHADE-171.
-
   Resolution: Fixed
 Assignee: Kristian Rosenvold
Fix Version/s: (was: backlog)
   2.4.3

Fixed in r1714646 and also related issues, there should be no more resource 
leaks. It should be possible to test 2.4.3 SNAPSHOT.

> "Access Denied" on Windows because shade plugin seems to try to open a 
> directory as Zip-File
> 
>
> Key: MSHADE-171
> URL: https://issues.apache.org/jira/browse/MSHADE-171
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: Happens on both Windows and Linux
>Reporter: Dominik Stadler
>Assignee: Kristian Rosenvold
> Fix For: 2.4.3
>
> Attachments: MSHADE-171.zip
>
>
> Config of plugin is fairly simple, but fails with the error below when I call 
> "mvn package test", it works when I call only "mvn package", it seems the 
> plugin tries to open a directory as zip-file.
> It happens in a multi-module setup when building from the parent-directory. 
> It seems the dependency between the module where the shade plugin runs onto 
> another module causes the target/classes of that module to be added as 
> artifact-file, which causes the shade plugin to fail.
> Let me know if you need a self-contained reproducer project, I can provide 
> one, but it will take some time to build it...
> FYI, there was a similar problem in the war plugin at MWAR-192.
> {code}
>   
>   org.apache.maven.plugins
>   maven-shade-plugin
>   2.3
>   
>   
>   package
>   
>   shade
>   
>   
>   
>   
> {code}
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on project 
> towerrunner-ui: Error creating shaded jar: 
> C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
>  (Access is denied) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on 
> project towerrunner-ui: Error creating shaded jar: 
> C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
>  (Access is denied)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating 
> shaded jar: 
> C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
>  (Access is denied)
> at 
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:566)
> at 
> 

[jira] [Created] (MSHADE-214) Update jdepenency to 1.1 to fix resource leaks

[Kristian Rosenvold (JIRA)]

Kristian Rosenvold created MSHADE-214:
-

 Summary: Update jdepenency to 1.1 to fix resource leaks
 Key: MSHADE-214
 URL: https://issues.apache.org/jira/browse/MSHADE-214
 Project: Maven Shade Plugin
  Issue Type: Improvement
Reporter: Kristian Rosenvold






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MSHADE-214) Update jdepenency to 1.1 to fix resource leaks

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MSHADE-214.
-
   Resolution: Fixed
 Assignee: Kristian Rosenvold
Fix Version/s: 2.4.3

Fixed in r1714645

> Update jdepenency to 1.1 to fix resource leaks
> --
>
> Key: MSHADE-214
> URL: https://issues.apache.org/jira/browse/MSHADE-214
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: 2.4.3
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSHADE-213) Clarify contract of ResourceTransformer wrt closing of streams

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MSHADE-213:
--
Description: The interface does not specify who closes the input stream, 
which leads to inconsistent closing and file handle leaks. Document behaviour 
and correct current implementations accordingly

> Clarify contract of ResourceTransformer wrt closing of streams
> --
>
> Key: MSHADE-213
> URL: https://issues.apache.org/jira/browse/MSHADE-213
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: 2.4.3
>
>
> The interface does not specify who closes the input stream, which leads to 
> inconsistent closing and file handle leaks. Document behaviour and correct 
> current implementations accordingly



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MSHADE-213) Clarify contract of ResourceTransformer wrt closing of streams

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold reassigned MSHADE-213:
-

Assignee: Kristian Rosenvold

> Clarify contract of ResourceTransformer wrt closing of streams
> --
>
> Key: MSHADE-213
> URL: https://issues.apache.org/jira/browse/MSHADE-213
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: 2.4.3
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MSHADE-213) Clarify contract of ResourceTransformer wrt closing of streams

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHADE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MSHADE-213.
-
   Resolution: Fixed
Fix Version/s: 2.4.3

Fixed in r1714643

> Clarify contract of ResourceTransformer wrt closing of streams
> --
>
> Key: MSHADE-213
> URL: https://issues.apache.org/jira/browse/MSHADE-213
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Reporter: Kristian Rosenvold
> Fix For: 2.4.3
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MSHADE-171) "Access Denied" on Windows because shade plugin seems to try to open a directory as Zip-File

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15003898#comment-15003898
 ] 

Kristian Rosenvold commented on MSHADE-171:
---

Additional resource leaks have just been fixed in jdependency, so we'd need to 
wait for a release of a version >1.0

> "Access Denied" on Windows because shade plugin seems to try to open a 
> directory as Zip-File
> 
>
> Key: MSHADE-171
> URL: https://issues.apache.org/jira/browse/MSHADE-171
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: Happens on both Windows and Linux
>Reporter: Dominik Stadler
> Fix For: backlog
>
> Attachments: MSHADE-171.zip
>
>
> Config of plugin is fairly simple, but fails with the error below when I call 
> "mvn package test", it works when I call only "mvn package", it seems the 
> plugin tries to open a directory as zip-file.
> It happens in a multi-module setup when building from the parent-directory. 
> It seems the dependency between the module where the shade plugin runs onto 
> another module causes the target/classes of that module to be added as 
> artifact-file, which causes the shade plugin to fail.
> Let me know if you need a self-contained reproducer project, I can provide 
> one, but it will take some time to build it...
> FYI, there was a similar problem in the war plugin at MWAR-192.
> {code}
>   
>   org.apache.maven.plugins
>   maven-shade-plugin
>   2.3
>   
>   
>   package
>   
>   shade
>   
>   
>   
>   
> {code}
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on project 
> towerrunner-ui: Error creating shaded jar: 
> C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
>  (Access is denied) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on 
> project towerrunner-ui: Error creating shaded jar: 
> C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
>  (Access is denied)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating 
> shaded jar: 
> C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
>  (Access is denied)
> at 
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:566)
> at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
> at 
> 

[jira] [Commented] (MSHADE-171) "Access Denied" on Windows because shade plugin seems to try to open a directory as Zip-File

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15001884#comment-15001884
 ] 

Kristian Rosenvold commented on MSHADE-171:
---

There was some logic that did not close streams properly upon errors in shade 
processing; this might be the cause of this problem. Fixed in r1713986, you may 
want to give 2.5-SNAPSHOT a try (I'm not on windows)

> "Access Denied" on Windows because shade plugin seems to try to open a 
> directory as Zip-File
> 
>
> Key: MSHADE-171
> URL: https://issues.apache.org/jira/browse/MSHADE-171
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.3
> Environment: Happens on both Windows and Linux
>Reporter: Dominik Stadler
> Fix For: backlog
>
> Attachments: MSHADE-171.zip
>
>
> Config of plugin is fairly simple, but fails with the error below when I call 
> "mvn package test", it works when I call only "mvn package", it seems the 
> plugin tries to open a directory as zip-file.
> It happens in a multi-module setup when building from the parent-directory. 
> It seems the dependency between the module where the shade plugin runs onto 
> another module causes the target/classes of that module to be added as 
> artifact-file, which causes the shade plugin to fail.
> Let me know if you need a self-contained reproducer project, I can provide 
> one, but it will take some time to build it...
> FYI, there was a similar problem in the war plugin at MWAR-192.
> {code}
>   
>   org.apache.maven.plugins
>   maven-shade-plugin
>   2.3
>   
>   
>   package
>   
>   shade
>   
>   
>   
>   
> {code}
> {noformat}
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on project 
> towerrunner-ui: Error creating shaded jar: 
> C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
>  (Access is denied) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
> goal org.apache.maven.plugins:maven-shade-plugin:2.3:shade (default) on 
> project towerrunner-ui: Error creating shaded jar: 
> C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
>  (Access is denied)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating 
> shaded jar: 
> C:\workspaces\workspace.GWT.changeset\towerrunner\towerrunner-base\target\classes
>  (Access is denied)
> at 
> org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:566)
> at 
> 

[jira] [Closed] (MASSEMBLY-788) Entry names in ZIP file are not correctly parsed when unzipping it

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-788.

Resolution: Not A Problem

> Entry names in ZIP file are not correctly parsed when unzipping it
> --
>
> Key: MASSEMBLY-788
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-788
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.6
> Environment: Windows 7 Professional, JDK 1.8.0_25, maven 3.2.5, 
> vertx-platform-2.1.5
>Reporter: Matias Cuturi
>
> Hello Team,
> I had a problem when upgrading the Maven Assembly Plugin from 2.5.5 to 2.6. 
> The problem happens when calling the the function _unzipModuleData_ of the 
> class _DefaultPlatformManager.java_ (see vertx-platform-2.1.5) with a zip 
> file created by the Maven Assembly Plugin 2.6. The error message "Failed to 
> create directory" is thrown. This issue does not happen with v2.5.5.
> Example:
> Assuming that following module was compressed with v2.6:
> module/foo/bar/baz.java --> module.zip
> when unziping the file:
> {code}
> //Pseudo code
> String directory = "C:\unzip_directory\";
> InputStream is = new BufferedInputStream(new FileInputStream("C:\module.zip");
> ZipInputStream zis = new ZipInputStream(new BufferedInputStream(is));
> while ((entry = zis.getNextEntry()) != null) {
> //Create the directory structure from the zip file
> ...
> ...
> String entryName = entry.getName();
> if (!new File(directory, entryName).mkdir()) {
>   throw new PlatformManagerException("Failed to create directory");
> }
> }
> {code}
> the value of _entryName_ in the first while-iteration is "module/foo/bar/" 
> instead of being "module/" in the first iteration,  "foo/" in the second and 
> "bar/" in the third one. This causes an error when trying to create the new 
> file.
> This issue is probably only happening in Windows machines.
> Regards,
> Matias



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-788) Entry names in ZIP file are not correctly parsed when unzipping it

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14975883#comment-14975883
 ] 

Kristian Rosenvold commented on MASSEMBLY-788:
--

Can you attach a zip file with a sample, please ?

> Entry names in ZIP file are not correctly parsed when unzipping it
> --
>
> Key: MASSEMBLY-788
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-788
> Project: Maven Assembly Plugin
>  Issue Type: Bug
>Affects Versions: 2.6
> Environment: Windows 7 Professional, JDK 1.8.0_25, maven 3.2.5, 
> vertx-platform-2.1.5
>Reporter: Matias Cuturi
>
> Hello Team,
> I had a problem when upgrading the Maven Assembly Plugin from 2.5.5 to 2.6. 
> The problem happens when calling the the function _unzipModuleData_ of the 
> class _DefaultPlatformManager.java_ (see vertx-platform-2.1.5) with a zip 
> file created by the Maven Assembly Plugin 2.6. The error message "Failed to 
> create directory" is thrown. This issue does not happen with v2.5.5.
> Example:
> Assuming that following module was compressed with v2.6:
> module/foo/bar/baz.java --> module.zip
> when unziping the file:
> {code}
> //Pseudo code
> String directory = "C:\unzip_directory\";
> InputStream is = new BufferedInputStream(new FileInputStream("C:\module.zip");
> ZipInputStream zis = new ZipInputStream(new BufferedInputStream(is));
> while ((entry = zis.getNextEntry()) != null) {
> //Create the directory structure from the zip file
> ...
> ...
> String entryName = entry.getName();
> if (!new File(directory, entryName).mkdir()) {
>   throw new PlatformManagerException("Failed to create directory");
> }
> }
> {code}
> the value of _entryName_ in the first while-iteration is "module/foo/bar/" 
> instead of being "module/" in the first iteration,  "foo/" in the second and 
> "bar/" in the third one. This causes an error when trying to create the new 
> file.
> This issue is probably only happening in Windows machines.
> Regards,
> Matias



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5649) Stop abusing IllegalArgumentException in case of null and use Guava's Preconditions

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14954559#comment-14954559
 ] 

Kristian Rosenvold commented on MNG-5649:
-

Why not use it then ? Guava is a bit of a dead-end project come jdk8 

> Stop abusing IllegalArgumentException in case of null and use Guava's 
> Preconditions
> ---
>
> Key: MNG-5649
> URL: https://issues.apache.org/jira/browse/MNG-5649
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.3.7
>
>
> In several spots of Maven Core, IAE is thrown where an argument is null. This 
> should be turned into {{NullPointerException}} since JDK adheres to is and 
> the 
> [description|http://docs.oracle.com/javase/6/docs/api/java/lang/NullPointerException.html]
>  of this exception indicates that and Effective Java does that too.
> I possible fix version could next minor: 3.3. Is no one is opposed it could 
> even be 3.2.2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSHARED-391) org.apache.maven.shared.repository.DefaultRepositoryAssembler#findCentralRepository does not understand mirrors

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MSHARED-391:
---
Component/s: maven-repository-builder

> org.apache.maven.shared.repository.DefaultRepositoryAssembler#findCentralRepository
>  does not understand mirrors
> ---
>
> Key: MSHARED-391
> URL: https://issues.apache.org/jira/browse/MSHARED-391
> Project: Maven Shared Components
>  Issue Type: Bug
>  Components: maven-repository-builder
>Reporter: Kristian Rosenvold
>
> The method should search getMirroredRepositories() for mirrors too. 
> Unfortunately this method appeared in 3.0.3, so we need to establish a new 
> minimum to fix this



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MNG-5750) Sporadic failures in concurrent build

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MNG-5750.
---
Resolution: Fixed
  Assignee: Kristian Rosenvold

Fixed, see linked issue for details

> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle 
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Assignee: Kristian Rosenvold
>Priority: Critical
>
> We have a large project of 300+ modules which regularly fails with different 
> kind of errors in different places. The issue is reliably reproduced with 
> parallel build and is not happens in single threaded. The optimal concurrency 
> level for our project ~10 threads. At this level ~%20 of builds fail. To 
> workaround the issue we reduced concurrency to 4 in development builds and 
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points 
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all 
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package 
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package 
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static 
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package 
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static 
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly 
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in 
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly 
> to trace this down. Unfortunately i cannot submit my project - it is 
> proprietary.
> Thanks in advance, Alexander



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (MNG-5750) Sporadic failures in concurrent build

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold reopened MNG-5750:
-
  Assignee: (was: Kristian Rosenvold)

> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle 
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Priority: Critical
> Fix For: 3.2.5
>
>
> We have a large project of 300+ modules which regularly fails with different 
> kind of errors in different places. The issue is reliably reproduced with 
> parallel build and is not happens in single threaded. The optimal concurrency 
> level for our project ~10 threads. At this level ~%20 of builds fail. To 
> workaround the issue we reduced concurrency to 4 in development builds and 
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points 
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all 
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package 
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package 
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static 
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package 
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static 
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly 
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in 
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly 
> to trace this down. Unfortunately i cannot submit my project - it is 
> proprietary.
> Thanks in advance, Alexander



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952256#comment-14952256
 ] 

Kristian Rosenvold commented on SUREFIRE-1182:
--

Fix tested, works great now !

> Surefire 2.19 rc hangs when building maven core
> ---
>
> Key: SUREFIRE-1182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1182
> Project: Maven Surefire
>  Issue Type: Bug
> Environment: Ubuntu linux
>Reporter: Kristian Rosenvold
>Assignee: Tibor Digana
> Fix For: 2.19
>
>
> The 2.19 release candidate of 6 oct hangs when building maven core on linux.
> Stack dumps;
> Forked booter:
> 2015-10-08 18:59:45
> Full thread dump OpenJDK 64-Bit Server VM (25.45-b02 mixed mode):
> "Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x7f6770001000 
> nid=0x3f48 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "DestroyJavaVM" #22 prio=5 os_prio=0 tid=0x7f67c000a000 nid=0x3e8d 
> waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "pool-1-thread-6" #20 prio=5 os_prio=0 tid=0x7f67c065e800 nid=0x3eab 
> waiting on condition [0x7f678847f000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> "pool-1-thread-5" #19 prio=5 os_prio=0 tid=0x7f67c065d000 nid=0x3eaa 
> waiting on condition [0x7f678858]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> "pool-1-thread-4" #18 prio=5 os_prio=0 tid=0x7f67c065b000 nid=0x3ea9 
> waiting on condition [0x7f6788681000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> "pool-1-thread-3" #17 prio=5 os_prio=0 tid=0x7f67c0659800 nid=0x3ea8 
> waiting on condition [0x7f6788782000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> 

[jira] [Commented] (MNG-5750) Sporadic failures in concurrent build

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14951997#comment-14951997
 ] 

Kristian Rosenvold commented on MNG-5750:
-

I think so, this would appear to be the plexus-interpolation bug that was fixed 
in 1.21 

> Sporadic failures in concurrent build
> -
>
> Key: MNG-5750
> URL: https://issues.apache.org/jira/browse/MNG-5750
> Project: Maven
>  Issue Type: Bug
>  Components: General
>Affects Versions: 3.1.1, 3.2.1, 3.2.2, 3.2.5
> Environment: SLES 3.0.80-0.7-default SMP x86_64 GNU/Linux Oracle 
> HotSpot JDK 7u25
> windows server 2008 x64 Oracle HotSpot JDK 7u65/8u25
>Reporter: Alexander Ashitkin
>Priority: Critical
>
> We have a large project of 300+ modules which regularly fails with different 
> kind of errors in different places. The issue is reliably reproduced with 
> parallel build and is not happens in single threaded. The optimal concurrency 
> level for our project ~10 threads. At this level ~%20 of builds fail. To 
> workaround the issue we reduced concurrency to 4 in development builds and 
> reverted production build to 1 thread.
> Main point of failures:
> # Surefire ClassNotFound. Reported and investigated in SUREFIRE-1132. Points 
> to a problem with MavenProject#getArtifacts - empty set unexpectedly returned.
> # Compiler - unexpected failure because of incorrect classpath (literally all 
> dependencies are not on the classpath), like: {code}
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[3,30] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[4,30] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[8,25] package ... 
> does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[9,21] package 
> org.joda.time does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,37] package 
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[11,1] static 
> import only from classes and interfaces
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,37] package 
> com.google.common.base does not exist
> 20:20:54 [ERROR] /D:/jenkins/work/workspace/..Request.java:[12,1] static 
> import only from classes and interfaces
> {code}
> # Jar - unexpected NPE. Reported with stack traces in MJAR-192. (assembly 
> plusgin seems to be also affected)
> At this point the issue looks like problem with MavenProject#getArtifacts in 
> concurrent builds.
> To help with the issue im happy to implement or evaluate any custom assembly 
> to trace this down. Unfortunately i cannot submit my project - it is 
> proprietary.
> Thanks in advance, Alexander



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core

[Kristian Rosenvold (JIRA)]

Kristian Rosenvold created SUREFIRE-1182:


 Summary: Surefire 2.19 rc hangs when building maven core
 Key: SUREFIRE-1182
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1182
 Project: Maven Surefire
  Issue Type: Bug
 Environment: Ubuntu linux
Reporter: Kristian Rosenvold


The 2.19 release candidate of 6 oct hangs when building maven core on linux.

Stack dumps;


Forked booter:
2015-10-08 18:59:45
Full thread dump OpenJDK 64-Bit Server VM (25.45-b02 mixed mode):

"Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x7f6770001000 nid=0x3f48 
waiting on condition [0x]
   java.lang.Thread.State: RUNNABLE

"DestroyJavaVM" #22 prio=5 os_prio=0 tid=0x7f67c000a000 nid=0x3e8d waiting 
on condition [0x]
   java.lang.Thread.State: RUNNABLE

"pool-1-thread-6" #20 prio=5 os_prio=0 tid=0x7f67c065e800 nid=0x3eab 
waiting on condition [0x7f678847f000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf3001be0> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

"pool-1-thread-5" #19 prio=5 os_prio=0 tid=0x7f67c065d000 nid=0x3eaa 
waiting on condition [0x7f678858]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf3001be0> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

"pool-1-thread-4" #18 prio=5 os_prio=0 tid=0x7f67c065b000 nid=0x3ea9 
waiting on condition [0x7f6788681000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf3001be0> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

"pool-1-thread-3" #17 prio=5 os_prio=0 tid=0x7f67c0659800 nid=0x3ea8 
waiting on condition [0x7f6788782000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf3001be0> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

"pool-1-thread-2" #16 prio=5 os_prio=0 tid=0x7f67c0657800 nid=0x3ea7 
waiting on condition [0x7f673000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf3001be0> (a 

[jira] [Commented] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14948998#comment-14948998
 ] 

Kristian Rosenvold commented on SUREFIRE-1182:
--

I analyzed the two thread dumps, and it would appear that the interesting bits 
are in the main process; the forked process appears to be completely idle. But 
why are there two streampumper threads in the main process ?


> Surefire 2.19 rc hangs when building maven core
> ---
>
> Key: SUREFIRE-1182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1182
> Project: Maven Surefire
>  Issue Type: Bug
> Environment: Ubuntu linux
>Reporter: Kristian Rosenvold
>
> The 2.19 release candidate of 6 oct hangs when building maven core on linux.
> Stack dumps;
> Forked booter:
> 2015-10-08 18:59:45
> Full thread dump OpenJDK 64-Bit Server VM (25.45-b02 mixed mode):
> "Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x7f6770001000 
> nid=0x3f48 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "DestroyJavaVM" #22 prio=5 os_prio=0 tid=0x7f67c000a000 nid=0x3e8d 
> waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "pool-1-thread-6" #20 prio=5 os_prio=0 tid=0x7f67c065e800 nid=0x3eab 
> waiting on condition [0x7f678847f000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> "pool-1-thread-5" #19 prio=5 os_prio=0 tid=0x7f67c065d000 nid=0x3eaa 
> waiting on condition [0x7f678858]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> "pool-1-thread-4" #18 prio=5 os_prio=0 tid=0x7f67c065b000 nid=0x3ea9 
> waiting on condition [0x7f6788681000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> "pool-1-thread-3" #17 prio=5 os_prio=0 tid=0x7f67c0659800 nid=0x3ea8 
> waiting on condition [0x7f6788782000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   

[jira] [Commented] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14949119#comment-14949119
 ] 

Kristian Rosenvold commented on SUREFIRE-1182:
--

I have bisected the changes in git, and this broke in 
cb97ba70cb9ebe685f8f2a06e87b538795b5dd9b



> Surefire 2.19 rc hangs when building maven core
> ---
>
> Key: SUREFIRE-1182
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1182
> Project: Maven Surefire
>  Issue Type: Bug
> Environment: Ubuntu linux
>Reporter: Kristian Rosenvold
>
> The 2.19 release candidate of 6 oct hangs when building maven core on linux.
> Stack dumps;
> Forked booter:
> 2015-10-08 18:59:45
> Full thread dump OpenJDK 64-Bit Server VM (25.45-b02 mixed mode):
> "Attach Listener" #23 daemon prio=9 os_prio=0 tid=0x7f6770001000 
> nid=0x3f48 waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "DestroyJavaVM" #22 prio=5 os_prio=0 tid=0x7f67c000a000 nid=0x3e8d 
> waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
> "pool-1-thread-6" #20 prio=5 os_prio=0 tid=0x7f67c065e800 nid=0x3eab 
> waiting on condition [0x7f678847f000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> "pool-1-thread-5" #19 prio=5 os_prio=0 tid=0x7f67c065d000 nid=0x3eaa 
> waiting on condition [0x7f678858]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> "pool-1-thread-4" #18 prio=5 os_prio=0 tid=0x7f67c065b000 nid=0x3ea9 
> waiting on condition [0x7f6788681000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> "pool-1-thread-3" #17 prio=5 os_prio=0 tid=0x7f67c0659800 nid=0x3ea8 
> waiting on condition [0x7f6788782000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0xf3001be0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
>   at 
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>   at 
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
>   at 
> 

[jira] [Commented] (MSHARED-442) Remove shading of artifact instead of using simple jar

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHARED-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14943051#comment-14943051
 ] 

Kristian Rosenvold commented on MSHARED-442:


I'm not sure this is a good idea, but I'll let this blow up somewhere before 
reverting :) 



> Remove shading of artifact instead of using simple jar
> --
>
> Key: MSHARED-442
> URL: https://issues.apache.org/jira/browse/MSHARED-442
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-shared-utils
>Affects Versions: maven-shared-utils-0.9
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: maven-shared-utils-3.0.0
>
>
> Currently the maven-shared-utils are being shaded during the build but why do 
> we need that? It would be simpler to use create a simple jar file instead. 
> The old build included commons-io into the shaded jar. commons-io dependency 
> is defined optional.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790937#comment-14790937
 ] 

Kristian Rosenvold edited comment on MDEP-490 at 9/16/15 6:57 PM:
--

Please stop name dropping people to catch their attention. In a lot of cases it 
has the opposite effect of what you want.


was (Author: krosenvold):
Please stop name dropping people to catch their attention. In a lot of cases it 
has the opposite intention of what you want.

> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it 
> doesn't work because of exclusion errors. One common example is libraries 
> that accidentally depend on junit at compile scope instead of test scope. 
> When I encounter a library like this, I add an exclusion on junit. But I have 
> junit in my dependency tree at test scope, so my build fails with a message 
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been 
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to 
> ignore exclusion errors. I just want to use the goal to check for version 
> mismatches, if I want to enforce banned dependencies the 
> maven-enforcer-plugin has more robust support for this. I implemented this 
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull 
> request. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MDEP-490) Add flag to analyze-dep-mgt goal to ignore exclusion errors

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14790937#comment-14790937
 ] 

Kristian Rosenvold commented on MDEP-490:
-

Please stop name dropping people to catch their attention. In a lot of cases it 
has the opposite intention of what you want.

> Add flag to analyze-dep-mgt goal to ignore exclusion errors
> ---
>
> Key: MDEP-490
> URL: https://issues.apache.org/jira/browse/MDEP-490
> Project: Maven Dependency Plugin
>  Issue Type: Improvement
>Reporter: Jonathan Haber
>
> I would like to run the analyze-dep-mgt goal with failBuild=true, but it 
> doesn't work because of exclusion errors. One common example is libraries 
> that accidentally depend on junit at compile scope instead of test scope. 
> When I encounter a library like this, I add an exclusion on junit. But I have 
> junit in my dependency tree at test scope, so my build fails with a message 
> like:
> {quote}
> [INFO] junit:junit:jar was excluded in DepMgt, but version 4.11 has been 
> found in the dependency tree.
> {quote}
> I think the simplest fix is to add a flag to the analyze-dep-mgt goal to 
> ignore exclusion errors. I just want to use the goal to check for version 
> mismatches, if I want to enforce banned dependencies the 
> maven-enforcer-plugin has more robust support for this. I implemented this 
> change in [this|https://github.com/apache/maven-plugins/pull/54] pull 
> request. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MSHARED-436) PrettyPrintXmlWriter produces too much garbage and is therefore slower than needed

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MSHARED-436.
--
   Resolution: Fixed
 Assignee: Kristian Rosenvold
Fix Version/s: maven-shared-utils-0.9

Fixed in r1702682

> PrettyPrintXmlWriter produces too much garbage and is therefore slower than 
> needed
> --
>
> Key: MSHARED-436
> URL: https://issues.apache.org/jira/browse/MSHARED-436
> Project: Maven Shared Components
>  Issue Type: Improvement
>  Components: maven-shared-utils
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: maven-shared-utils-0.9
>
>
> Use of more appropriate data structures will almost certainly improve the 
> performance of this class, which is used in surefire report writing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MSHARED-436) PrettyPrintXmlWriter produces too much garbage and is therefore slower than needed

[Kristian Rosenvold (JIRA)]

Kristian Rosenvold created MSHARED-436:
--

 Summary: PrettyPrintXmlWriter produces too much garbage and is 
therefore slower than needed
 Key: MSHARED-436
 URL: https://issues.apache.org/jira/browse/MSHARED-436
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-shared-utils
Reporter: Kristian Rosenvold


Use of more appropriate data structures will almost certainly improve the 
performance of this class, which is used in surefire report writing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14694975#comment-14694975
 ] 

Kristian Rosenvold commented on MNG-5869:
-

Reading https://maven.apache.org/guides/mini/guide-http-settings.html,
I suspect your build will fail after the default 30 minute read
timeout. Did you check this ?



 Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
 

 Key: MNG-5869
 URL: https://issues.apache.org/jira/browse/MNG-5869
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
 Attachments: settings.xml, threaddumps.log


 We recently discovered a strange bug of frozen dependencies downloads
 I didn't yet studied a lot the issue but I guess it may be something in 
 recent versions of Wagon.
 I created few jobs to demonstrate the Maven issue and I would like to have 
 some guidance to deeply analyse it.
 The project used is https://github.com/kenzanmedia/bowtie/ which has a really 
 simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
 All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
 We are using some custom global and user maven settings but only to setup 
 some mirrors, some credentials and to (re)define some repositories
 Here are my results jobs on https://aheritier.ci.cloudbees.com
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
 Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and 
 3.3.3 it works only if we use the https access to maven central
 For Maven 3.2 and 3.3 with http repositories the build is frozen and killed 
 after the timeout I defined (5 minutes - I did also a test with 1h)
 All builds are frozen at the same point in the download process to grab 
 surefire artefacts
 DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 {code}
 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie 
 ---
 06:28:06 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
 06:28:06 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
  (3 KB at 3.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
  (3 KB at 42.7 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
  (6 KB at 52.9 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
  (2 KB at 2.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  (16 KB at 154.9 KB/sec)
 06:28:08 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
 06:28:08 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
  (2 KB at 62.8 KB/sec)
 06:28:08 

[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693150#comment-14693150
 ] 

Kristian Rosenvold commented on MNG-5869:
-

I think the only value we could possibly hope to gain from this is if you 
bisect the org.mock-server dependencies version from 3.19.1 - 3.9.17 to find 
out exactly which change they did to fix the problem  by looking at the changes 
they did for that specific version. Subsequently we could discuss if the 
incorrect behaviour is something we should support/be more informative of. 
Generally, when something is operating outside the spec, you're in a shady area.

If you're willing to do these steps, we might be able to gain something from 
this issue

 Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
 

 Key: MNG-5869
 URL: https://issues.apache.org/jira/browse/MNG-5869
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
 Attachments: settings.xml, threaddumps.log


 We recently discovered a strange bug of frozen dependencies downloads
 I didn't yet studied a lot the issue but I guess it may be something in 
 recent versions of Wagon.
 I created few jobs to demonstrate the Maven issue and I would like to have 
 some guidance to deeply analyse it.
 The project used is https://github.com/kenzanmedia/bowtie/ which has a really 
 simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
 All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
 We are using some custom global and user maven settings but only to setup 
 some mirrors, some credentials and to (re)define some repositories
 Here are my results jobs on https://aheritier.ci.cloudbees.com
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
 Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and 
 3.3.3 it works only if we use the https access to maven central
 For Maven 3.2 and 3.3 with http repositories the build is frozen and killed 
 after the timeout I defined (5 minutes - I did also a test with 1h)
 All builds are frozen at the same point in the download process to grab 
 surefire artefacts
 DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 {code}
 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie 
 ---
 06:28:06 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
 06:28:06 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
  (3 KB at 3.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
  (3 KB at 42.7 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
  (6 KB at 52.9 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
  (2 KB at 2.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  (16 KB at 

[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693094#comment-14693094
 ] 

Kristian Rosenvold commented on MNG-5869:
-

It hangs on my machine too. A couple of things I see from your thread dump:

A) You have threads waiting for downloads to finish
B) There is an instance of org.mockserver.mockserver.MockServer$ running, which 
would seem to indicate you are running something like the mrm-plugin or some 
other kind of proxy in front of your local repo for testing. I did not 
specifically dive into this but I'd recommend further investigations along this 
line of inquiry

 Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
 

 Key: MNG-5869
 URL: https://issues.apache.org/jira/browse/MNG-5869
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
 Attachments: settings.xml, threaddumps.log


 We recently discovered a strange bug of frozen dependencies downloads
 I didn't yet studied a lot the issue but I guess it may be something in 
 recent versions of Wagon.
 I created few jobs to demonstrate the Maven issue and I would like to have 
 some guidance to deeply analyse it.
 The project used is https://github.com/kenzanmedia/bowtie/ which has a really 
 simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
 All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
 We are using some custom global and user maven settings but only to setup 
 some mirrors, some credentials and to (re)define some repositories
 Here are my results jobs on https://aheritier.ci.cloudbees.com
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
 Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and 
 3.3.3 it works only if we use the https access to maven central
 For Maven 3.2 and 3.3 with http repositories the build is frozen and killed 
 after the timeout I defined (5 minutes - I did also a test with 1h)
 All builds are frozen at the same point in the download process to grab 
 surefire artefacts
 DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 {code}
 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie 
 ---
 06:28:06 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
 06:28:06 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
  (3 KB at 3.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
  (3 KB at 42.7 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
  (6 KB at 52.9 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
  (2 KB at 2.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  (16 KB at 154.9 KB/sec)
 06:28:08 [INFO] Downloading: 
 

[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693100#comment-14693100
 ] 

Kristian Rosenvold commented on MNG-5869:
-

Upgrading all org.mock-server depenedncies to tha latest 3.9.17 fixes the 
problem here

 Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
 

 Key: MNG-5869
 URL: https://issues.apache.org/jira/browse/MNG-5869
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
 Attachments: settings.xml, threaddumps.log


 We recently discovered a strange bug of frozen dependencies downloads
 I didn't yet studied a lot the issue but I guess it may be something in 
 recent versions of Wagon.
 I created few jobs to demonstrate the Maven issue and I would like to have 
 some guidance to deeply analyse it.
 The project used is https://github.com/kenzanmedia/bowtie/ which has a really 
 simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
 All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
 We are using some custom global and user maven settings but only to setup 
 some mirrors, some credentials and to (re)define some repositories
 Here are my results jobs on https://aheritier.ci.cloudbees.com
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
 Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and 
 3.3.3 it works only if we use the https access to maven central
 For Maven 3.2 and 3.3 with http repositories the build is frozen and killed 
 after the timeout I defined (5 minutes - I did also a test with 1h)
 All builds are frozen at the same point in the download process to grab 
 surefire artefacts
 DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 {code}
 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie 
 ---
 06:28:06 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
 06:28:06 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
  (3 KB at 3.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
  (3 KB at 42.7 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
  (6 KB at 52.9 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
  (2 KB at 2.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  (16 KB at 154.9 KB/sec)
 06:28:08 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
 06:28:08 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
  (2 KB at 62.8 KB/sec)
 06:28:08 [INFO] Downloading: 
 

[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693404#comment-14693404
 ] 

Kristian Rosenvold commented on MNG-5869:
-

https://github.com/jamesdbloom/mockserver/compare/mockserver-3.9.5...mockserver-3.9.6#diff-5a54c9aaccb46c226c7f6c69bfb465ffL142



 Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
 

 Key: MNG-5869
 URL: https://issues.apache.org/jira/browse/MNG-5869
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
 Attachments: settings.xml, threaddumps.log


 We recently discovered a strange bug of frozen dependencies downloads
 I didn't yet studied a lot the issue but I guess it may be something in 
 recent versions of Wagon.
 I created few jobs to demonstrate the Maven issue and I would like to have 
 some guidance to deeply analyse it.
 The project used is https://github.com/kenzanmedia/bowtie/ which has a really 
 simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
 All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
 We are using some custom global and user maven settings but only to setup 
 some mirrors, some credentials and to (re)define some repositories
 Here are my results jobs on https://aheritier.ci.cloudbees.com
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
 Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and 
 3.3.3 it works only if we use the https access to maven central
 For Maven 3.2 and 3.3 with http repositories the build is frozen and killed 
 after the timeout I defined (5 minutes - I did also a test with 1h)
 All builds are frozen at the same point in the download process to grab 
 surefire artefacts
 DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 {code}
 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie 
 ---
 06:28:06 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
 06:28:06 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
  (3 KB at 3.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
  (3 KB at 42.7 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
  (6 KB at 52.9 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
  (2 KB at 2.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  (16 KB at 154.9 KB/sec)
 06:28:08 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
 06:28:08 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
  (2 KB at 62.8 KB/sec)
 06:28:08 [INFO] Downloading: 
 

[jira] [Comment Edited] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14693404#comment-14693404
 ] 

Kristian Rosenvold edited comment on MNG-5869 at 8/12/15 12:25 PM:
---

https://github.com/jamesdbloom/mockserver/compare/mockserver-3.9.5...mockserver-3.9.6#diff-5a54c9aaccb46c226c7f6c69bfb465ffL142

Would appear that incorrect content-length is the key here. Seen this before.



was (Author: krosenvold):
https://github.com/jamesdbloom/mockserver/compare/mockserver-3.9.5...mockserver-3.9.6#diff-5a54c9aaccb46c226c7f6c69bfb465ffL142



 Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
 

 Key: MNG-5869
 URL: https://issues.apache.org/jira/browse/MNG-5869
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER
 Attachments: settings.xml, threaddumps.log


 We recently discovered a strange bug of frozen dependencies downloads
 I didn't yet studied a lot the issue but I guess it may be something in 
 recent versions of Wagon.
 I created few jobs to demonstrate the Maven issue and I would like to have 
 some guidance to deeply analyse it.
 The project used is https://github.com/kenzanmedia/bowtie/ which has a really 
 simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
 All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
 We are using some custom global and user maven settings but only to setup 
 some mirrors, some credentials and to (re)define some repositories
 Here are my results jobs on https://aheritier.ci.cloudbees.com
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
 Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and 
 3.3.3 it works only if we use the https access to maven central
 For Maven 3.2 and 3.3 with http repositories the build is frozen and killed 
 after the timeout I defined (5 minutes - I did also a test with 1h)
 All builds are frozen at the same point in the download process to grab 
 surefire artefacts
 DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 {code}
 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie 
 ---
 06:28:06 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
 06:28:06 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
  (3 KB at 3.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
  (3 KB at 42.7 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
  (6 KB at 52.9 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
  (2 KB at 2.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  (16 KB at 154.9 KB/sec)
 06:28:08 [INFO] Downloading: 
 

[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14681737#comment-14681737
 ] 

Kristian Rosenvold commented on MNG-5869:
-

Make a thread dump with jstack and include it here, please.

 Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
 

 Key: MNG-5869
 URL: https://issues.apache.org/jira/browse/MNG-5869
 Project: Maven
  Issue Type: Bug
  Components: Dependencies
Affects Versions: 3.2.5, 3.3.3
Reporter: Arnaud HERITIER

 We recently discovered a strange bug of frozen dependencies downloads
 I didn't yet studied a lot the issue but I guess it may be something in 
 recent versions of Wagon.
 I created few jobs to demonstrate the Maven issue and I would like to have 
 some guidance to deeply analyse it.
 The project used is https://github.com/kenzanmedia/bowtie/ which has a really 
 simple Maven build : https://github.com/kenzanmedia/bowtie/blob/master/pom.xml
 All my builds are using Apache Maven in versions 3.1.1, 3.2.5 or 3.3.3
 We are using some custom global and user maven settings but only to setup 
 some mirrors, some credentials and to (re)define some repositories
 Here are my results jobs on https://aheritier.ci.cloudbees.com
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo.maven.apache.org (https)
 * (/) DEV-1599 - Maven 3.1.1 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.2.5 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.2.5 (DC) downloads from repo1.maven.org (http)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.cloudbees.com (http)
 * (/) DEV-1599 - Maven 3.3.3 (DC) downloads from repo.maven.apache.org (https)
 * (x) DEV-1599 - Maven 3.3.3 (DC) downloads from repo1.maven.org (http)
 Result: Builds are always working with Maven 3.1.1 while for Maven 3.2.5 and 
 3.3.3 it works only if we use the https access to maven central
 For Maven 3.2 and 3.3 with http repositories the build is frozen and killed 
 after the timeout I defined (5 minutes - I did also a test with 1h)
 All builds are frozen at the same point in the download process to grab 
 surefire artefacts
 DEV-1599 - Maven 3.2.5 (DC) downloads from repo.cloudbees.com (http)
 {code}
 06:28:06 [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ bowtie 
 ---
 06:28:06 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
 06:28:06 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-booter/2.12.4/surefire-booter-2.12.4.pom
  (3 KB at 3.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/surefire-api/2.12.4/surefire-api-2.12.4.pom
  (3 KB at 42.7 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/surefire/maven-surefire-common/2.12.4/maven-surefire-common-2.12.4.pom
  (6 KB at 52.9 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-annotations/3.1/maven-plugin-annotations-3.1.pom
  (2 KB at 2.2 KB/sec)
 06:28:07 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
 06:28:07 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/plugin-tools/maven-plugin-tools/3.1/maven-plugin-tools-3.1.pom
  (16 KB at 154.9 KB/sec)
 06:28:08 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
 06:28:08 [INFO] Downloaded: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting-api/2.0.9/maven-reporting-api-2.0.9.pom
  (2 KB at 62.8 KB/sec)
 06:28:08 [INFO] Downloading: 
 http://repo.cloudbees.com/content/repositories/central/org/apache/maven/reporting/maven-reporting/2.0.9/maven-reporting-2.0.9.pom
 06:28:09 

[jira] [Closed] (MASSEMBLY-781) Execution make-assembly fails: user id is too big

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-781.

Resolution: Invalid
  Assignee: Kristian Rosenvold

You have to switch tar to posix format to support these ID's, gnu format 
cannot support them

 Execution make-assembly fails: user id is too big
 -

 Key: MASSEMBLY-781
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-781
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
 Environment: Mac OS X 10.10.4 (Yosemite)
 Maven 3.3.3
Reporter: Matthew Storer
Assignee: Kristian Rosenvold
  Labels: assembly, build, maven

 maven-assembly-plugin fails make-assembly execution when the executing user's 
 ID is too big.
 While building a multi-module project (X) from the command line using {{mvn 
 package}}, all defined modules build just fine, but assembling X itself fails 
 with the following error:
 {quote}
 [INFO] 
 
 [INFO] Building X 1.0
 [INFO] 
 
 [INFO] 
 [INFO] --- maven-assembly-plugin:2.5.5:single (make-assembly) @ x ---
 [INFO] Reading assembly descriptor: src/assembly/bin-assembly.xml
 [INFO] Building tar: /bb/x/target/x-1.0-bin.tar.gz
 [INFO] 
 
 [INFO] Reactor Summary:
 [INFO] 
 [INFO] Common . SUCCESS [  3.180 
 s]
 [INFO] A Service .. SUCCESS [  3.337 
 s]
 [INFO] B Service .. SUCCESS [  2.186 
 s]
 [INFO] A User Interface ... SUCCESS [  1.331 
 s]
 [INFO] B User Interface ... SUCCESS [  1.380 
 s]
 [INFO] X .. FAILURE [  0.346 
 s]
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 19.722 s
 [INFO] Finished at: 2015-07-23T16:32:34-04:00
 [INFO] Final Memory: 53M/279M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (make-assembly) 
 on project X: Execution make-assembly of goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: user id 
 '1535409742' is too big (  2097151 ). - [Help 1]
 {quote}
 Snippet from X multi-module POM that configures maven-assembly-plugin:
 {quote}
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.5.5/version
 configuration
 descriptors
 descriptorsrc/assembly/bin-assembly.xml/descriptor
 descriptorsrc/assembly/src-assembly.xml/descriptor
 /descriptors
 /configuration
 executions
 execution
 idmake-assembly/id
 phasepackage/phase
 goals
 goalsingle/goal
 /goals
 /execution
 /executions
 /plugin
 {quote}
 Error and stack trace:
 {quote}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (make-assembly) 
 on project X: Execution make-assembly of goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: user id 
 '1535409742' is too big (  2097151 ). - [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single 
 (make-assembly) on project X: Execution make-assembly of goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single failed: user id 
 '1535409742' is too big (  2097151 ).
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
   at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
   at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
   at 
 

[jira] [Closed] (MASSEMBLY-704) Remove all goals which are marked deprecated

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-704.

Resolution: Fixed
  Assignee: Kristian Rosenvold  (was: Karl Heinz Marbaise)

Fixed in r1691766

 Remove all goals which are marked deprecated
 

 Key: MASSEMBLY-704
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-704
 Project: Maven Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.4.1
Reporter: Karl Heinz Marbaise
Assignee: Kristian Rosenvold

 All goals which are marked deprecated should be removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14616595#comment-14616595
 ] 

Kristian Rosenvold commented on SUREFIRE-1157:
--

I poked around slightly in the code and the jdk, and it would appear that as 
long as any files are opened *before* we call System.setSecurityManager we can 
just keep them open. All in all, we should probably be able to switch back to 
regular files (and still work with a security manager) with this strategy. 

 Surefire fork communication fails when a native library writes to stdout
 

 Key: SUREFIRE-1157
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1157
 Project: Maven Surefire
  Issue Type: Bug
  Components: process forking
Affects Versions: 2.17
Reporter: Dan Berindei

 We are seeing this exception in some of our CI builds:
 {noformat}
 [11:17:10]W:   [Step 2/4] [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
 project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null:
  NoSuchElementException - [Help 1]
 [11:17:10] :   [Step 2/4] 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) 
 on project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [11:17:10] :   [Step 2/4] at 
 java.lang.reflect.Method.invoke(Method.java:483)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
 [11:17:10] :   [Step 2/4] Caused by: 
 org.apache.maven.plugin.PluginExecutionException: Execution default-test of 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
 [11:17:10] :   [Step 2/4] ... 19 more
 [11:17:10] :   [Step 2/4] 

[jira] [Commented] (MNG-5847) Maven controls java.library.path

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14602439#comment-14602439
 ] 

Kristian Rosenvold commented on MNG-5847:
-

Unless you want to fix the isse yourself, you're relying that some commiter has 
sufficient understanding of your problem to fix it. So while I might be able to 
fix the problem, I am not very familiar with native stuff. So by making a test 
project you'd increase the chance of getting this issue fixed. Is there any 
chance you could use some existing stuff with native code from maven central ? 
(org.xerial.snappy/snappy-java comes to mind) ? Otherwise I'm afraid you'll 
have to fix the issue yourself and create a patch

 Maven controls java.library.path
 

 Key: MNG-5847
 URL: https://issues.apache.org/jira/browse/MNG-5847
 Project: Maven
  Issue Type: Wish
Reporter: Markus Karg
  Labels: dill, jni, lib, native, so

 We have many Java projects that are dependent of other Java projects which 
 make use of JNI. Hence, when we do mvn test in our project, we fail 
 frequently as the native part of the dependency is missing, even if we 
 declare the native part as an explicit dependency. There are several ideas 
 how to solve that, but non of them is complete or sufficient.
 The solution users expect would look like this:
 * MyProject has one dependency to OtherProject of type*/type (asterisk 
 means: Maven selects best fit).
 * OtherProject offers many different packages, e. g. win-x86-dll, 
 win-x64-dll, linux-so-64, etc.
 * When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
 dependency's coordinates, and select that package that is the best fit for 
 the current execution enviroment. For example, it select win-x86-dll when 
 run on Windows (32 Bit), or selects linux-so-64 when run on Linux (64 Bit) 
 etc. This mechanism should be extensible by future extension plugin, so a 
 third party vendor can simply provide addtional mappings via Maven Central.
 * Just as Maven does a configuration of the ClassPath from all JAR 
 dependencies, it now will now do a configuration of all native dependencies. 
 That means, it copies the selected native dependencies to target/dependencies 
 and builds a synthetic java.library.path system property.
 * As a result, adding a native dependency will work on any platform without 
 any complex pom.xml tweaks.
 * The solution shall not be a Java-only solution, but it shall work with any 
 kind of toolset. So a toolset plugin shall be able to utilize the core 
 mechanism and adapt it to its own needs, which includes for example the fact 
 that setting java.library.path is job of the Java Toolset Plugin, while 
 providing a similar lookup mechanism is job a hypothetical different Toolset 
 Plugin.
 We would really beg the Maven team to provide such a solution, as JNI is an 
 integral part of Java for really long time, and we have this problem every 
 other day.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNG-5847) Maven controls java.library.path

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14600814#comment-14600814
 ] 

Kristian Rosenvold commented on MNG-5847:
-

This issue will require a small test project that demonstrates the problem.


 Maven controls java.library.path
 

 Key: MNG-5847
 URL: https://issues.apache.org/jira/browse/MNG-5847
 Project: Maven
  Issue Type: Wish
Reporter: Markus Karg
  Labels: dill, jni, lib, native, so

 We have many Java projects that are dependent of other Java projects which 
 make use of JNI. Hence, when we do mvn test in our project, we fail 
 frequently as the native part of the dependency is missing, even if we 
 declare the native part as an explicit dependency. There are several ideas 
 how to solve that, but non of them is complete or sufficient.
 The solution users expect would look like this:
 * MyProject has one dependency to OtherProject of type*/type (asterisk 
 means: Maven selects best fit).
 * OtherProject offers many different packages, e. g. win-x86-dll, 
 win-x64-dll, linux-so-64, etc.
 * When doing mvn test on MyProject, Maven checks ALL exiting packages for the 
 dependency's coordinates, and select that package that is the best fit for 
 the current execution enviroment. For example, it select win-x86-dll when 
 run on Windows (32 Bit), or selects linux-so-64 when run on Linux (64 Bit) 
 etc. This mechanism should be extensible by future extension plugin, so a 
 third party vendor can simply provide addtional mappings via Maven Central.
 * Just as Maven does a configuration of the ClassPath from all JAR 
 dependencies, it now will now do a configuration of all native dependencies. 
 That means, it copies the selected native dependencies to target/dependencies 
 and builds a synthetic java.library.path system property.
 * As a result, adding a native dependency will work on any platform without 
 any complex pom.xml tweaks.
 * The solution shall not be a Java-only solution, but it shall work with any 
 kind of toolset. So a toolset plugin shall be able to utilize the core 
 mechanism and adapt it to its own needs, which includes for example the fact 
 that setting java.library.path is job of the Java Toolset Plugin, while 
 providing a similar lookup mechanism is job a hypothetical different Toolset 
 Plugin.
 We would really beg the Maven team to provide such a solution, as JNI is an 
 integral part of Java for really long time, and we have this problem every 
 other day.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MNG-5844) Close IO Streams in finally or try-with-resource statement

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MNG-5844:

 Priority: Minor  (was: Critical)
Fix Version/s: 3.3.4

 Close IO Streams in finally or try-with-resource statement
 --

 Key: MNG-5844
 URL: https://issues.apache.org/jira/browse/MNG-5844
 Project: Maven
  Issue Type: Improvement
Reporter: Tang Xinye
Assignee: Kristian Rosenvold
Priority: Minor
 Fix For: 3.3.4


 The problem here is that if an exception is thrown during the read process 
 the method will exit without closing the stream and hence without releasing 
 the file system resources, it may run out of resources before it does run.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MNG-5844) Close IO Streams in finally or try-with-resource statement

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MNG-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MNG-5844.
---
Resolution: Fixed
  Assignee: Kristian Rosenvold

Thanks for the patch !

 Close IO Streams in finally or try-with-resource statement
 --

 Key: MNG-5844
 URL: https://issues.apache.org/jira/browse/MNG-5844
 Project: Maven
  Issue Type: Improvement
Reporter: Tang Xinye
Assignee: Kristian Rosenvold
Priority: Critical

 The problem here is that if an exception is thrown during the read process 
 the method will exit without closing the stream and hence without releasing 
 the file system resources, it may run out of resources before it does run.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNGSITE-242) not able to compile a module named as RCS and SCCS

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593270#comment-14593270
 ] 

Kristian Rosenvold edited comment on MNGSITE-242 at 6/19/15 9:45 AM:
-

I'm quite sure this is because RCS and SCCS appear on the default excludes 
list for the maven-shared/plexus directory scanner, as can be seen here. 
Someone, somewhere needs to disable default excludes :)

https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/DirectoryScanner.java#L126


Given a small problem that reproduces the problem it should not be too hard to 
find


was (Author: krosenvold):
I'm quite sure this is because RCS appears on the default excludes list for 
the maven-shared/plexus directory scanner, as can be seen here. Someone, 
somewhere needs to disable default excludes :)

https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/DirectoryScanner.java#L126


Given a small problem that reproduces the problem it should not be too hard to 
find

 not able to compile a module named as RCS and SCCS
 --

 Key: MNGSITE-242
 URL: https://issues.apache.org/jira/browse/MNGSITE-242
 Project: Maven Project Web Site
  Issue Type: Bug
 Environment: Red Hat
Reporter: Akshay Sharma
Priority: Blocker
  Labels: maven
 Attachments: RCS-20150619_120831.log


 I am using Maven as build tool for building our banking application. There is 
 one module which named as RCS which is not getting compiled because of one 
 strange restriction forced by maven. All other modules are getting complied. 
 When i searched the reason on google, i found that maven does not allow users 
 to name module/package RCS/GIT/SVN/SCCS. 
 My RCS name is a financial term and its not possible to change the module 
 name as it has multiple dependencies. 
 How we can remove this restriction or what is the possible solution. Please 
 help me in this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MNGSITE-242) not able to compile a module named as RCS and SCCS

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593270#comment-14593270
 ] 

Kristian Rosenvold commented on MNGSITE-242:


I'm quite sure this is because RCS appears on the default excludes list for 
the maven-shared/plexus directory scanner, as can be seen here. Someone, 
somewhere needs to disable default excludes :)

https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/DirectoryScanner.java#L126


Given a small problem that reproduces the problem it should not be too hard to 
find

 not able to compile a module named as RCS and SCCS
 --

 Key: MNGSITE-242
 URL: https://issues.apache.org/jira/browse/MNGSITE-242
 Project: Maven Project Web Site
  Issue Type: Bug
 Environment: Red Hat
Reporter: Akshay Sharma
Priority: Blocker
  Labels: maven
 Attachments: RCS-20150619_120831.log


 I am using Maven as build tool for building our banking application. There is 
 one module which named as RCS which is not getting compiled because of one 
 strange restriction forced by maven. All other modules are getting complied. 
 When i searched the reason on google, i found that maven does not allow users 
 to name module/package RCS/GIT/SVN/SCCS. 
 My RCS name is a financial term and its not possible to change the module 
 name as it has multiple dependencies. 
 How we can remove this restriction or what is the possible solution. Please 
 help me in this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNGSITE-242) not able to compile a module named as RCS and SCCS

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593270#comment-14593270
 ] 

Kristian Rosenvold edited comment on MNGSITE-242 at 6/19/15 9:46 AM:
-

I'm quite sure this is because RCS and SCCS appear on the default excludes 
list for the maven-shared/plexus directory scanner, as can be seen at 
https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/DirectoryScanner.java#L126.
 Someone, somewhere needs to disable default excludes :)




Given a small problem that reproduces the problem it should not be too hard to 
find


was (Author: krosenvold):
I'm quite sure this is because RCS and SCCS appear on the default excludes 
list for the maven-shared/plexus directory scanner, as can be seen here. 
Someone, somewhere needs to disable default excludes :)

https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/DirectoryScanner.java#L126


Given a small problem that reproduces the problem it should not be too hard to 
find

 not able to compile a module named as RCS and SCCS
 --

 Key: MNGSITE-242
 URL: https://issues.apache.org/jira/browse/MNGSITE-242
 Project: Maven Project Web Site
  Issue Type: Bug
 Environment: Red Hat
Reporter: Akshay Sharma
Priority: Blocker
  Labels: maven
 Attachments: RCS-20150619_120831.log


 I am using Maven as build tool for building our banking application. There is 
 one module which named as RCS which is not getting compiled because of one 
 strange restriction forced by maven. All other modules are getting complied. 
 When i searched the reason on google, i found that maven does not allow users 
 to name module/package RCS/GIT/SVN/SCCS. 
 My RCS name is a financial term and its not possible to change the module 
 name as it has multiple dependencies. 
 How we can remove this restriction or what is the possible solution. Please 
 help me in this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-774) too many open files

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593305#comment-14593305
 ] 

Kristian Rosenvold commented on MASSEMBLY-774:
--

It would appear I fixed this on the 2.x branch *âfter* releasing 3.0.1. If you 
switch to version 2.10.3 it should work fine. Once you confirm this I'll 
release 3.0.2

 too many open files
 ---

 Key: MASSEMBLY-774
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-774
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
Reporter: Dan Armbrust

 I ran across this - 
 http://mail-archives.apache.org/mod_mbox/maven-dev/201501.mbox/%3ca2ee0d04-04e3-4c99-8842-673463862...@takari.io%3E
  - and since I'm making huge zip files, I thought I would give it a try.
 I configured as:
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.5.5/version
 dependencies
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-archiver/artifactId
 version3.0.1/version
 /dependency
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-io/artifactId
 version2.6/version
 /dependency
 /dependencies
 /plugin
 But this lead to a failure:
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (zip) on project 
 ... sememe/seg.3182.sememe.map (Too many open files) - [Help 1]
 I certainly could raise my ulimit:
 darmbrust@overkill:/mnt/STORAGE/Work/Apelon/Workspaces/ISAAC-Core-2/va-solor-goods$
  ulimit -a
 ...
 open files  (-n) 1024
 But it seems it would be better if the zip process limited itself to a 
 reasonable number of open files.  I don't know the algorithm... but it seems 
 that double or triple the processor count would be more than enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MASSEMBLY-774) too many open files

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593305#comment-14593305
 ] 

Kristian Rosenvold edited comment on MASSEMBLY-774 at 6/19/15 10:30 AM:


It would appear I fixed this on the 2.x branch *after* releasing 3.0.1. If you 
switch to version 2.10.3 it should work fine. Once you confirm this I'll 
release 3.0.2


was (Author: krosenvold):
It would appear I fixed this on the 2.x branch *âfter* releasing 3.0.1. If you 
switch to version 2.10.3 it should work fine. Once you confirm this I'll 
release 3.0.2

 too many open files
 ---

 Key: MASSEMBLY-774
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-774
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
Reporter: Dan Armbrust

 I ran across this - 
 http://mail-archives.apache.org/mod_mbox/maven-dev/201501.mbox/%3ca2ee0d04-04e3-4c99-8842-673463862...@takari.io%3E
  - and since I'm making huge zip files, I thought I would give it a try.
 I configured as:
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.5.5/version
 dependencies
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-archiver/artifactId
 version3.0.1/version
 /dependency
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-io/artifactId
 version2.6/version
 /dependency
 /dependencies
 /plugin
 But this lead to a failure:
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (zip) on project 
 ... sememe/seg.3182.sememe.map (Too many open files) - [Help 1]
 I certainly could raise my ulimit:
 darmbrust@overkill:/mnt/STORAGE/Work/Apelon/Workspaces/ISAAC-Core-2/va-solor-goods$
  ulimit -a
 ...
 open files  (-n) 1024
 But it seems it would be better if the zip process limited itself to a 
 reasonable number of open files.  I don't know the algorithm... but it seems 
 that double or triple the processor count would be more than enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MNGSITE-242) not able to compile a module named as RCS and SCCS

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNGSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593270#comment-14593270
 ] 

Kristian Rosenvold edited comment on MNGSITE-242 at 6/19/15 9:46 AM:
-

I'm quite sure this is because RCS and SCCS appear on the default excludes 
list for the maven-shared/plexus directory scanner, as can be seen here. 
Someone, somewhere needs to disable default excludes :)

https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/DirectoryScanner.java#L126


Given a small problem that reproduces the problem it should not be too hard to 
find


was (Author: krosenvold):
I'm quite sure this is because RCS and SCCS appear on the default excludes 
list for the maven-shared/plexus directory scanner, as can be seen here. 
Someone, somewhere needs to disable default excludes :)

https://github.com/apache/maven-shared/blob/trunk/maven-shared-utils/src/main/java/org/apache/maven/shared/utils/io/DirectoryScanner.java#L126


Given a small problem that reproduces the problem it should not be too hard to 
find

 not able to compile a module named as RCS and SCCS
 --

 Key: MNGSITE-242
 URL: https://issues.apache.org/jira/browse/MNGSITE-242
 Project: Maven Project Web Site
  Issue Type: Bug
 Environment: Red Hat
Reporter: Akshay Sharma
Priority: Blocker
  Labels: maven
 Attachments: RCS-20150619_120831.log


 I am using Maven as build tool for building our banking application. There is 
 one module which named as RCS which is not getting compiled because of one 
 strange restriction forced by maven. All other modules are getting complied. 
 When i searched the reason on google, i found that maven does not allow users 
 to name module/package RCS/GIT/SVN/SCCS. 
 My RCS name is a financial term and its not possible to change the module 
 name as it has multiple dependencies. 
 How we can remove this restriction or what is the possible solution. Please 
 help me in this. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MASSEMBLY-774) too many open files

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593010#comment-14593010
 ] 

Kristian Rosenvold edited comment on MASSEMBLY-774 at 6/19/15 5:05 AM:
---

Can you run with mvn -e and include the stacktrace of where the file allocation 
is failing ?
(Maybe run a few times to see if it fails in the same place, include all stack 
traces if different)

(This was fixed in https://github.com/codehaus-plexus/plexus-archiver/issues/6, 
but there apperas to be multiple code paths with this problem then..)


was (Author: krosenvold):
Can you run with mvn -e and include the stacktrace of where the file allocation 
is failing ?

(This was fixed in https://github.com/codehaus-plexus/plexus-archiver/issues/6, 
but there apperas to be multiple code paths with this problem then..)

 too many open files
 ---

 Key: MASSEMBLY-774
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-774
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
Reporter: Dan Armbrust

 I ran across this - 
 http://mail-archives.apache.org/mod_mbox/maven-dev/201501.mbox/%3ca2ee0d04-04e3-4c99-8842-673463862...@takari.io%3E
  - and since I'm making huge zip files, I thought I would give it a try.
 I configured as:
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.5.5/version
 dependencies
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-archiver/artifactId
 version3.0.1/version
 /dependency
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-io/artifactId
 version2.6/version
 /dependency
 /dependencies
 /plugin
 But this lead to a failure:
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (zip) on project 
 ... sememe/seg.3182.sememe.map (Too many open files) - [Help 1]
 I certainly could raise my ulimit:
 darmbrust@overkill:/mnt/STORAGE/Work/Apelon/Workspaces/ISAAC-Core-2/va-solor-goods$
  ulimit -a
 ...
 open files  (-n) 1024
 But it seems it would be better if the zip process limited itself to a 
 reasonable number of open files.  I don't know the algorithm... but it seems 
 that double or triple the processor count would be more than enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MASSEMBLY-774) too many open files

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593010#comment-14593010
 ] 

Kristian Rosenvold edited comment on MASSEMBLY-774 at 6/19/15 5:05 AM:
---

Can you run with mvn -e and include the stacktrace of where the file allocation 
is failing ?
(Maybe run a few times to see if it fails in the same place, include all stack 
traces if different)

(This was fixed in https://github.com/codehaus-plexus/plexus-archiver/issues/6, 
but there appears to be multiple code paths with this problem then..)


was (Author: krosenvold):
Can you run with mvn -e and include the stacktrace of where the file allocation 
is failing ?
(Maybe run a few times to see if it fails in the same place, include all stack 
traces if different)

(This was fixed in https://github.com/codehaus-plexus/plexus-archiver/issues/6, 
but there apperas to be multiple code paths with this problem then..)

 too many open files
 ---

 Key: MASSEMBLY-774
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-774
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
Reporter: Dan Armbrust

 I ran across this - 
 http://mail-archives.apache.org/mod_mbox/maven-dev/201501.mbox/%3ca2ee0d04-04e3-4c99-8842-673463862...@takari.io%3E
  - and since I'm making huge zip files, I thought I would give it a try.
 I configured as:
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.5.5/version
 dependencies
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-archiver/artifactId
 version3.0.1/version
 /dependency
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-io/artifactId
 version2.6/version
 /dependency
 /dependencies
 /plugin
 But this lead to a failure:
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (zip) on project 
 ... sememe/seg.3182.sememe.map (Too many open files) - [Help 1]
 I certainly could raise my ulimit:
 darmbrust@overkill:/mnt/STORAGE/Work/Apelon/Workspaces/ISAAC-Core-2/va-solor-goods$
  ulimit -a
 ...
 open files  (-n) 1024
 But it seems it would be better if the zip process limited itself to a 
 reasonable number of open files.  I don't know the algorithm... but it seems 
 that double or triple the processor count would be more than enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-759) tar outputs missing entries for target directory.

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593052#comment-14593052
 ] 

Kristian Rosenvold commented on MASSEMBLY-759:
--

To be honest, I looked at this issue and it was actually slightly more 
complicated than one might anticipate (due to layering issues). Since there is 
a known workaround it's not at the top of my list

If someone makes a patch it's much more likely I will review it :)



 tar outputs missing entries for target directory.
 -

 Key: MASSEMBLY-759
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-759
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: dependencySet
Affects Versions: 2.5.3
Reporter: mike duigou

 {quote}
 assembly 
 xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   
 xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
  http://maven.apache.org/xsd/assembly-1.1.2.xsd;
 idtarball/id
 formats
 formattar/format
 formattbz2/format
 /formats
 includeBaseDirectoryfalse/includeBaseDirectory
  dependencySets
 dependencySet
 outputDirectory./lib/outputDirectory
 directoryMode0755/directoryMode
 useProjectArtifacttrue/useProjectArtifact
 unpackfalse/unpack
 scoperuntime/scope
 excludes
 exclude*:javaee-web-api/exclude
 /excludes
 /dependencySet
 /dependencySets
 /assembly
 {quote}
 Does not output a tar record for the created libdirectory, just for the 
 entries under it:
 {quote}
 
 -rw-r--r--  0 mike staff   60686 29 Dec 13:19 lib/commons-logging-1.1.1.jar
 
 {quote}
 The only alternative seems to be to create a lib directory somewhere and use 
 a fileset to copy it over before the dependencySet



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-774) too many open files

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593010#comment-14593010
 ] 

Kristian Rosenvold commented on MASSEMBLY-774:
--

Can you run with mvn -e and include the stacktrace of where the file allocation 
is failing ?


 too many open files
 ---

 Key: MASSEMBLY-774
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-774
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
Reporter: Dan Armbrust

 I ran across this - 
 http://mail-archives.apache.org/mod_mbox/maven-dev/201501.mbox/%3ca2ee0d04-04e3-4c99-8842-673463862...@takari.io%3E
  - and since I'm making huge zip files, I thought I would give it a try.
 I configured as:
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.5.5/version
 dependencies
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-archiver/artifactId
 version3.0.1/version
 /dependency
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-io/artifactId
 version2.6/version
 /dependency
 /dependencies
 /plugin
 But this lead to a failure:
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (zip) on project 
 ... sememe/seg.3182.sememe.map (Too many open files) - [Help 1]
 I certainly could raise my ulimit:
 darmbrust@overkill:/mnt/STORAGE/Work/Apelon/Workspaces/ISAAC-Core-2/va-solor-goods$
  ulimit -a
 ...
 open files  (-n) 1024
 But it seems it would be better if the zip process limited itself to a 
 reasonable number of open files.  I don't know the algorithm... but it seems 
 that double or triple the processor count would be more than enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MASSEMBLY-774) too many open files

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14593010#comment-14593010
 ] 

Kristian Rosenvold edited comment on MASSEMBLY-774 at 6/19/15 5:01 AM:
---

Can you run with mvn -e and include the stacktrace of where the file allocation 
is failing ?

(This was fixed in https://github.com/codehaus-plexus/plexus-archiver/issues/6, 
but there apperas to be multiple code paths with this problem then..)


was (Author: krosenvold):
Can you run with mvn -e and include the stacktrace of where the file allocation 
is failing ?


 too many open files
 ---

 Key: MASSEMBLY-774
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-774
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
Reporter: Dan Armbrust

 I ran across this - 
 http://mail-archives.apache.org/mod_mbox/maven-dev/201501.mbox/%3ca2ee0d04-04e3-4c99-8842-673463862...@takari.io%3E
  - and since I'm making huge zip files, I thought I would give it a try.
 I configured as:
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-assembly-plugin/artifactId
 version2.5.5/version
 dependencies
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-archiver/artifactId
 version3.0.1/version
 /dependency
 dependency
 groupIdorg.codehaus.plexus/groupId
 artifactIdplexus-io/artifactId
 version2.6/version
 /dependency
 /dependencies
 /plugin
 But this lead to a failure:
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-assembly-plugin:2.5.5:single (zip) on project 
 ... sememe/seg.3182.sememe.map (Too many open files) - [Help 1]
 I certainly could raise my ulimit:
 darmbrust@overkill:/mnt/STORAGE/Work/Apelon/Workspaces/ISAAC-Core-2/va-solor-goods$
  ulimit -a
 ...
 open files  (-n) 1024
 But it seems it would be better if the zip process limited itself to a 
 reasonable number of open files.  I don't know the algorithm... but it seems 
 that double or triple the processor count would be more than enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MSHARED-426) Upgrade maven-assembly-plugin to Version 2.5.5

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold resolved MSHARED-426.

Resolution: Fixed
  Assignee: Kristian Rosenvold  (was: Tibor Digana)

 Upgrade maven-assembly-plugin to Version 2.5.5
 --

 Key: MSHARED-426
 URL: https://issues.apache.org/jira/browse/MSHARED-426
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-shared-utils
Affects Versions: maven-shared-utils-0.8
Reporter: Tibor Digana
Assignee: Kristian Rosenvold

 The build fails on tests maven-shared-utils with command mvn clean verify.
 Failed tests:
DirectoryScannerTest.followSymlinks:179 null
FileUtilsTest.copyFileThatIsSymlink:433 null
 Tests run: 858, Failures: 2, Errors: 0, Skipped: 27 
 Solution is to upgrade maven-assembly-plugin to version 2.5.5.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MSHARED-426) Upgrade maven-assembly-plugin to Version 2.5.5

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MSHARED-426:
---
Fix Version/s: maven-shared-utils-0.9

 Upgrade maven-assembly-plugin to Version 2.5.5
 --

 Key: MSHARED-426
 URL: https://issues.apache.org/jira/browse/MSHARED-426
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-shared-utils
Affects Versions: maven-shared-utils-0.8
Reporter: Tibor Digana
Assignee: Kristian Rosenvold
 Fix For: maven-shared-utils-0.9


 The build fails on tests maven-shared-utils with command mvn clean verify.
 Failed tests:
DirectoryScannerTest.followSymlinks:179 null
FileUtilsTest.copyFileThatIsSymlink:433 null
 Tests run: 858, Failures: 2, Errors: 0, Skipped: 27 
 Solution is to upgrade maven-assembly-plugin to version 2.5.5.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MASSEMBLY-773) MetaInfServicesHandler catalog is not cleared between invocations in multimodule projects

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-773.

   Resolution: Fixed
Fix Version/s: 3.0.0

Fixed in  r1684951

 MetaInfServicesHandler catalog is not cleared between invocations in 
 multimodule projects
 -

 Key: MASSEMBLY-773
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-773
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.2, 2.5.5
Reporter: Nick Dimiduk
 Fix For: 3.0.0


 I have a multi-module project (Apache Phoenix) that is using the assembly 
 plugin to build two unrelated uberjars.
 {noformat}
 [INFO] Apache Phoenix . SUCCESS [  3.705 
 s]
 [INFO] Phoenix Core ... SUCCESS [01:30 
 min]
 [INFO] Phoenix - Flume  SUCCESS [  2.832 
 s]
 [INFO] Phoenix - Pig .. SUCCESS [  2.579 
 s]
 [INFO] Phoenix Query Server Client  SUCCESS [  0.906 
 s]
 [INFO] Phoenix Query Server ... SUCCESS [ 33.841 
 s]
 [INFO] Phoenix - Pherf  SUCCESS [ 14.286 
 s]
 [INFO] Phoenix - Spark  SUCCESS [ 33.687 
 s]
 [INFO] Phoenix Assembly ... SUCCESS [01:29 
 min]{noformat}
 The first uberjar is built by the {{Assembly}} module and consists of classes 
 from {{Core}}, {{Flume}}, {{Pig}}, {{Spark}}, and sundry dependencies. The 
 second is built in the {{Query Server}} module and consists of {{Core}}, 
 {{Query Server}}, and {{Query Server Client}} modules. Both {{Core}} and 
 {{Query Server Client}} modules provide a 
 {{META-INF/services/java.sql.Driver}} file. As you can see above, the {{Query 
 Server}} module is assembled first, and then the {{Assembly}} module.
 Initially I added the {{metaInf-services}} {{containerDescriptorHandler}} to 
 the {{Assembly}} module (PHOENIX-1995) and everything worked as expected. 
 Later, I added it also to the {{Query Server}} module (PHOENIX-2013). After 
 that, I noticed that the resulting {{java.sql.Driver}} file packaged by 
 {{Assembly}} contains entries for this file from {{Query Server}}.
 After much mucking about with dependencies, excludes, etc, I decided to 
 {{mvnDebug}} the build. With a breakpoint in 
 {{AbstractLineAggregatingHandler#addToArchive}}, sure enough, I see all the 
 {{catalog}} entries from the first assembly invocation in the second 
 invocation. I also see that the instance of {{MetaInfServicesHandler}} and 
 it's {{catalog}} instance are identical between module invocations. 
 Breakpoints at {{AbstractLineAggregatingHandler#getCatalog}} and 
 {{AbstractLineAggregatingHandler#setCatalog}} are never hit, indicating that 
 nothing external is tinkering with the {{catalog}} or its contents.
 I think the instance of {{MetaInfServicesHandler}} should be either reset or 
 re-instantiated between module invocations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-748) problem to extract zip files including file names with umlauts

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14580033#comment-14580033
 ] 

Kristian Rosenvold commented on MASSEMBLY-748:
--

Use encoding parameter in 
http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_unpackOptions
 to inidcate the encoding of the file you are unpacking.

 problem to extract zip files including file names with umlauts
 --

 Key: MASSEMBLY-748
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-748
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: 2.5.3
 Environment: 
Reporter: Hannes Kogler
Assignee: Kristian Rosenvold
 Fix For: 2.5.4

 Attachments: encoding_problem_on_zip_extract.7z


 Like in an other issue reported, you need to explicitly set the code page 
 CP850 to create zip packages hosting file names with correct umlauts their 
 names. (by using the following configuration)
 archiverConfig
   encodingCP850/encoding
 /archiverConfig
 After all this solution is not 100% useful, because if you extract this file 
 with the obiously correct umlauts in the zip, wrong chars for all umlauts 
 reappear.
 It's strange, because if you unzip this zip file with all other zip tools 
 (7zip, Windows native zip support aso.) the extraction works fine.
 Only using the maven-assembly-plugin the umlauts get corrupted.
 (a try to set the archiverConfig with the CP850 also for the extracting 
 execution process of the assembly plugin just results in a bad error calling
 Failed to configure archiver:
   org.codehaus.plexus.archiver.dir.DirectoryArchiver: Cannot find 'encoding' 
 in class org.codehaus.plexus.archiver.dir.DirectoryArchiver  )



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-771.

Resolution: Invalid
  Assignee: Kristian Rosenvold

The thing is that tar files can also have root-relative files inside it, which 
means files with a name that starts from the root of the file system. I'll see 
if I can improve the warning message further..

 Regression: Unable to create tar.gz in cross-platform build without error 
 messages on Windows
 -

 Key: MASSEMBLY-771
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
 Environment: Windows
Reporter: Axel Fontaine
Assignee: Kristian Rosenvold

 Recent versions of the assembly plugin started outputting a harmless, but 
 annoying error message when creating tar.gz files from Windows:
 [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
 root-relative-reference (starting with slash) /mypath
 This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MASSEMBLY-772) tar.gz contents owned by user who ran build

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MASSEMBLY-772:
-
Issue Type: Wish  (was: Bug)

 tar.gz contents owned by user who ran build
 ---

 Key: MASSEMBLY-772
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-772
 Project: Maven Assembly Plugin
  Issue Type: Wish
  Components: maven-archiver
Affects Versions: 2.5.5
 Environment: Windows, Maven 3.3.3
Reporter: Axel Fontaine

 When creating a tar.gz, the files it contains have no group (OK), but do have 
 a user (not OK). More specifically it is the user who ran the build. This 
 should really be empty to avoid any surprises.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MSHARED-331) Sections in own manifest file are mixed up

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MSHARED-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MSHARED-331.
--
Resolution: Invalid
  Assignee: Kristian Rosenvold

The jar specification explicitly states that a blank line is newline newline, 
hence spaces are not permitted.

 Sections in own manifest file are mixed up
 --

 Key: MSHARED-331
 URL: https://issues.apache.org/jira/browse/MSHARED-331
 Project: Maven Shared Components
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: maven-archiver-2.5
Reporter: Johannes Schneider
Assignee: Kristian Rosenvold

 I'm using my own manifest file as described 
 [here|http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html].
  Plugin-Config:
 {code:xml}
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-jar-plugin/artifactId
 version2.4/version
 configuration
 archive
 manifestEntries
 
 Implementation-Version${project.version}/Implementation-Version
 /manifestEntries
 manifestFilemanifest.mf/manifestFile
 /archive
 /configuration
 /plugin
 {code}
 The manifest.mf file contains a Name: Dependencies section:
 {noformat}
 Implementation-Title: hello-api
 Implementation-Vendor: js
 
 Name: Dependencies
 helloModule: 3.0.0
 somethingElse: 6.4:0.2
 tools:  6.4:0.64
 {noformat}
 In the resulting MANIFEST.MF inside the jar file, however, all entries are 
 disorderd. In particular, the section is destroyed:
 {noformat}
 Manifest-Version: 1.0
 Implementation-Vendor: js   
 Implementation-Title: hello-api
 somethingElse: 6.4:0.2
 tools:  6.4:0.64
 Implementation-Version: 6.4.11-2-SNAPSHOT
 Built-By: js
 Build-Jdk: 1.7.0_51
 Name: Dependencies
 helloModule: 3.0.0
 Created-By: Apache Maven 3.0.5
 Archiver-Version: Plexus Archiver
 {noformat}
 As a workaround, I can define the whole manifest in the pom file. However, 
 this is not a good solution since I do not want everyone to edit the pom 
 file, which always involves the risk of destroying/manipulating the build. 
 Furthermore, it is not very convenient to search for the archive section in 
 a lengthy pom file.
 Remark: I am not sure which version of maven-archiver is used by 
 maven-jar-plugin 2.4, so I chose the most recent one.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578349#comment-14578349
 ] 

Kristian Rosenvold commented on MASSEMBLY-771:
--

Why dont you just fix the descriptor ? (Or attach it if you believe the message 
is incorrect)

 Regression: Unable to create tar.gz in cross-platform build without error 
 messages on Windows
 -

 Key: MASSEMBLY-771
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
 Environment: Windows
Reporter: Axel Fontaine

 Recent versions of the assembly plugin started outputting a harmless, but 
 annoying error message when creating tar.gz files from Windows:
 [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
 root-relative-reference (starting with slash) /mypath
 This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14578357#comment-14578357
 ] 

Kristian Rosenvold commented on MASSEMBLY-771:
--

Removing the leading slash from /jre should do the trick. Or do you intend to 
produce a tar file that extracts to the root of the linux file system ? 
(Because I see that's obviously going to create this warning on windows...)

 Regression: Unable to create tar.gz in cross-platform build without error 
 messages on Windows
 -

 Key: MASSEMBLY-771
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-771
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.5
 Environment: Windows
Reporter: Axel Fontaine

 Recent versions of the assembly plugin started outputting a harmless, but 
 annoying error message when creating tar.gz files from Windows:
 [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific 
 root-relative-reference (starting with slash) /mypath
 This used to work fine with older versions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MASSEMBLY-752) [PATCH] Option to ignore empty directories in fileSet directory

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MASSEMBLY-752:
-
Fix Version/s: 3.0.0

 [PATCH] Option to ignore empty directories in fileSet directory
 ---

 Key: MASSEMBLY-752
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-752
 Project: Maven Assembly Plugin
  Issue Type: Improvement
Affects Versions: 2.5.3
Reporter: Guillaume Boué
 Fix For: 3.0.0

 Attachments: MASSEMBLY-ignoreEmptyDirectories.patch


 When the directory attribute of fileSets contains empty directories, it would 
 be nice to have an option to ignore them.
 === Actual behaviour ===
 Considering the structure :
 src/
+-- folder1/file.txt
+-- folder2/
 with the following fileSet in assembly.xml :
 fileSet
 directorysrc/directory
 outputDirectory//outputDirectory
 /fileSet
 the assembly-plugin produces, as of today :
 /folder1/file.txt
 /folder2
 Note that the empty directory folder2 is present in the assembly.
 === Proposed enhancement ===
 With this enhancement, it would be possible to have the following in 
 assembly.xml :
 fileSet
 directorysrc/directory
 outputDirectory//outputDirectory
 includeEmptyDirectoriesfalse/includeEmptyDirectories
 /fileSet
 and the resulting assembly would be :
 /folder1/file.txt
 Note that folder2 would not be present inside the assembly because it is 
 empty.
 Attached is a patch adding the attribute includeEmptyDirectories to the 
 fileSet element in assembly.xml file. For backward compatibility, the default 
 value of this attribute is true.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MASSEMBLY-768) JarInputStream unable to find manifest created by version 2.5.4

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-768.

Resolution: Fixed

Fixed in r1682528

 JarInputStream unable to find  manifest created by version 2.5.4
 

 Key: MASSEMBLY-768
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-768
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.4
 Environment: windows 64 bit, java 8. maven 3.3..3
Reporter: Vlad Skarzhevskyy
Assignee: Kristian Rosenvold
Priority: Critical
 Fix For: 2.5.5

 Attachments: mco.xml, pom.xml


 The problem is non trivial to reproduce. Changing back to version 2.5.3 
 resolves the problem.
 On some computers plugin creates a jar file with manifest unreadable by java. 
 JarInputStream
 see comments in JarInputStream(InputStream in, boolean verify)
 java expects manifest to be either the first or the second entry in archive.
 looking at the gnerated jar using winrar generate report i see that in broken 
 files MANIFEST.MF  is not in right place.
 In example below it is third place.
 {noformat}
 #  Archive D:\sample-java\target\sample-bad.jar
 2015-05-15 20:19FolderFolder  META-INF
 2015-05-15 20:19FolderFolder  META-INF\lib
 2015-05-15 20:19   274   203  META-INF\MANIFEST.MF
 2015-05-14 01:43 10106  8342  
 META-INF\lib\mco2-sample-java-2.6.0-SNAPSHOT.jar
 2015-03-04 15:46  8262  7790  mco2-sample-java.mco.png
 2015-03-04 15:46 10400  1564  mco2-sample-java.mco.xml
 #
 # Total   SizePacked  Files
 #29042 17899  6
 {noformat}
 Please let me know if you need additional info. Or a complete test project.
 My assembly descriptor and partial pom with configuration will be attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MASSEMBLY-769) ZIP fileMode permissions not properly set with dependencySet and unpackOptions

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-769.

Resolution: Fixed
  Assignee: Kristian Rosenvold

Fixed in r1682528

 ZIP fileMode permissions not properly set with dependencySet and unpackOptions
 --

 Key: MASSEMBLY-769
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-769
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.3, 2.5.4
Reporter: Dawid Weiss
Assignee: Kristian Rosenvold
Priority: Minor
 Fix For: 2.5.5

 Attachments: example.zip


 This issue first appeared in 2.5.3 and applies to an assembly with filtered 
 dependencies and fileMode set, as in here:
 {code}
 dependencySet
   outputDirectory//outputDirectory
   includes
 includetest:child1/include
   /includes
   useTransitiveDependenciestrue/useTransitiveDependencies
   useTransitiveFilteringtrue/useTransitiveFiltering
   useProjectArtifactfalse/useProjectArtifact
   unpacktrue/unpack
   unpackOptions
 includes
 includel4g/include
 includel4g.cmd/include
 /includes
   /unpackOptions
   fileMode0755/fileMode
 /dependencySet
 {code}
 The output ZIP had proper file mode flags in 2.5.2, but from 2.5.3 on it's 
 incorrect.
 Steps to reproduce:
 {code}
 unzip example.zip
 cd example
 mvn clean package
 zipinfo child2/target/*.zip
 {code}
 Output (slightly trimmed) for 2.5.3 and 2.5.4:
 {code}
 Archive:  c:\_tmp\example\example\child2\target\foo-1.0-SNAPSHOT-private.zip
 Zip file size: 565 bytes, number of entries: 4
 drwxr-xr-x  2.0 unx0 b- stor 15-May-18 13:45 foo-1.0-SNAPSHOT/
 -rw-r--r--  2.0 unx3 bl defN 15-May-18 13:45 foo-1.0-SNAPSHOT/l4g
 -rw-r--r--  2.0 unx3 bl defN 15-May-18 13:45 foo-1.0-SNAPSHOT/l4g.cmd
 {code}
 output for 2.5.2 (note the 'x' flag for ``l4g`` files):
 {code}
 Archive:  c:\_tmp\example\example\child2\target\foo-1.0-SNAPSHOT-private.zip
 Zip file size: 565 bytes, number of entries: 4
 drwxr-xr-x  2.0 unx0 b- stor 15-May-18 13:47 foo-1.0-SNAPSHOT/
 -rwxr-xr-x  2.0 unx3 bl defN 15-May-18 13:47 foo-1.0-SNAPSHOT/l4g
 -rwxr-xr-x  2.0 unx3 bl defN 15-May-18 13:47 foo-1.0-SNAPSHOT/l4g.cmd
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-767) Schema missing from the web site

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14565213#comment-14565213
 ] 

Kristian Rosenvold commented on MASSEMBLY-767:
--

How to I get the schema there ??

 Schema missing from the web site
 

 Key: MASSEMBLY-767
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-767
 Project: Maven Assembly Plugin
  Issue Type: Bug
Reporter: Benson Margulies

  http://maven.apache.org/xsd/assembly-1.1.3.xsd isn't there. It should be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MASSEMBLY-767) Schema missing from the web site

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MASSEMBLY-767:
-
Fix Version/s: 2.5.5

 Schema missing from the web site
 

 Key: MASSEMBLY-767
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-767
 Project: Maven Assembly Plugin
  Issue Type: Bug
Reporter: Benson Margulies
Assignee: Kristian Rosenvold
 Fix For: 2.5.5


  http://maven.apache.org/xsd/assembly-1.1.3.xsd isn't there. It should be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (MASSEMBLY-767) Schema missing from the web site

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold closed MASSEMBLY-767.

Resolution: Fixed
  Assignee: Kristian Rosenvold

Ok, fixed the index page and the xsds

 Schema missing from the web site
 

 Key: MASSEMBLY-767
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-767
 Project: Maven Assembly Plugin
  Issue Type: Bug
Reporter: Benson Margulies
Assignee: Kristian Rosenvold

  http://maven.apache.org/xsd/assembly-1.1.3.xsd isn't there. It should be.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-769) ZIP fileMode permissions not properly set with dependencySet and unpackOptions

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14563356#comment-14563356
 ] 

Kristian Rosenvold commented on MASSEMBLY-769:
--

Fixed in plexus-archiver in fa9760eb62b7ed6e6c173a2626ff1b97792aba42

 ZIP fileMode permissions not properly set with dependencySet and unpackOptions
 --

 Key: MASSEMBLY-769
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-769
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.3, 2.5.4
Reporter: Dawid Weiss
Priority: Minor
 Attachments: example.zip


 This issue first appeared in 2.5.3 and applies to an assembly with filtered 
 dependencies and fileMode set, as in here:
 {code}
 dependencySet
   outputDirectory//outputDirectory
   includes
 includetest:child1/include
   /includes
   useTransitiveDependenciestrue/useTransitiveDependencies
   useTransitiveFilteringtrue/useTransitiveFiltering
   useProjectArtifactfalse/useProjectArtifact
   unpacktrue/unpack
   unpackOptions
 includes
 includel4g/include
 includel4g.cmd/include
 /includes
   /unpackOptions
   fileMode0755/fileMode
 /dependencySet
 {code}
 The output ZIP had proper file mode flags in 2.5.2, but from 2.5.3 on it's 
 incorrect.
 Steps to reproduce:
 {code}
 unzip example.zip
 cd example
 mvn clean package
 zipinfo child2/target/*.zip
 {code}
 Output (slightly trimmed) for 2.5.3 and 2.5.4:
 {code}
 Archive:  c:\_tmp\example\example\child2\target\foo-1.0-SNAPSHOT-private.zip
 Zip file size: 565 bytes, number of entries: 4
 drwxr-xr-x  2.0 unx0 b- stor 15-May-18 13:45 foo-1.0-SNAPSHOT/
 -rw-r--r--  2.0 unx3 bl defN 15-May-18 13:45 foo-1.0-SNAPSHOT/l4g
 -rw-r--r--  2.0 unx3 bl defN 15-May-18 13:45 foo-1.0-SNAPSHOT/l4g.cmd
 {code}
 output for 2.5.2 (note the 'x' flag for ``l4g`` files):
 {code}
 Archive:  c:\_tmp\example\example\child2\target\foo-1.0-SNAPSHOT-private.zip
 Zip file size: 565 bytes, number of entries: 4
 drwxr-xr-x  2.0 unx0 b- stor 15-May-18 13:47 foo-1.0-SNAPSHOT/
 -rwxr-xr-x  2.0 unx3 bl defN 15-May-18 13:47 foo-1.0-SNAPSHOT/l4g
 -rwxr-xr-x  2.0 unx3 bl defN 15-May-18 13:47 foo-1.0-SNAPSHOT/l4g.cmd
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MASSEMBLY-769) ZIP fileMode permissions not properly set with dependencySet and unpackOptions

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MASSEMBLY-769:
-
Fix Version/s: 2.5.5

 ZIP fileMode permissions not properly set with dependencySet and unpackOptions
 --

 Key: MASSEMBLY-769
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-769
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.3, 2.5.4
Reporter: Dawid Weiss
Priority: Minor
 Fix For: 2.5.5

 Attachments: example.zip


 This issue first appeared in 2.5.3 and applies to an assembly with filtered 
 dependencies and fileMode set, as in here:
 {code}
 dependencySet
   outputDirectory//outputDirectory
   includes
 includetest:child1/include
   /includes
   useTransitiveDependenciestrue/useTransitiveDependencies
   useTransitiveFilteringtrue/useTransitiveFiltering
   useProjectArtifactfalse/useProjectArtifact
   unpacktrue/unpack
   unpackOptions
 includes
 includel4g/include
 includel4g.cmd/include
 /includes
   /unpackOptions
   fileMode0755/fileMode
 /dependencySet
 {code}
 The output ZIP had proper file mode flags in 2.5.2, but from 2.5.3 on it's 
 incorrect.
 Steps to reproduce:
 {code}
 unzip example.zip
 cd example
 mvn clean package
 zipinfo child2/target/*.zip
 {code}
 Output (slightly trimmed) for 2.5.3 and 2.5.4:
 {code}
 Archive:  c:\_tmp\example\example\child2\target\foo-1.0-SNAPSHOT-private.zip
 Zip file size: 565 bytes, number of entries: 4
 drwxr-xr-x  2.0 unx0 b- stor 15-May-18 13:45 foo-1.0-SNAPSHOT/
 -rw-r--r--  2.0 unx3 bl defN 15-May-18 13:45 foo-1.0-SNAPSHOT/l4g
 -rw-r--r--  2.0 unx3 bl defN 15-May-18 13:45 foo-1.0-SNAPSHOT/l4g.cmd
 {code}
 output for 2.5.2 (note the 'x' flag for ``l4g`` files):
 {code}
 Archive:  c:\_tmp\example\example\child2\target\foo-1.0-SNAPSHOT-private.zip
 Zip file size: 565 bytes, number of entries: 4
 drwxr-xr-x  2.0 unx0 b- stor 15-May-18 13:47 foo-1.0-SNAPSHOT/
 -rwxr-xr-x  2.0 unx3 bl defN 15-May-18 13:47 foo-1.0-SNAPSHOT/l4g
 -rwxr-xr-x  2.0 unx3 bl defN 15-May-18 13:47 foo-1.0-SNAPSHOT/l4g.cmd
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550045#comment-14550045
 ] 

Kristian Rosenvold commented on SUREFIRE-1157:
--

We switched to using console output form the fork to avoid security manager 
issues, currently surefire allows junit3 tests to be run with a security 
manager and no specific kind of policy exempts in place. 

If we were to switch we'd have to look into alternatives that do not require 
native code, I dont know if stuff like Unix Domain Sockets can be used. I 
suspect we'd have to make the remoting strategy swappable, at least 
per-platform, possibly also with a fallback to stdio.



 Surefire fork communication fails when a native library writes to stdout
 

 Key: SUREFIRE-1157
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1157
 Project: Maven Surefire
  Issue Type: Bug
  Components: process forking
Affects Versions: 2.17
Reporter: Dan Berindei

 We are seeing this exception in some of our CI builds:
 {noformat}
 [11:17:10]W:   [Step 2/4] [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
 project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null:
  NoSuchElementException - [Help 1]
 [11:17:10] :   [Step 2/4] 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) 
 on project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [11:17:10] :   [Step 2/4] at 
 java.lang.reflect.Method.invoke(Method.java:483)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
 [11:17:10] :   [Step 2/4] Caused by: 
 org.apache.maven.plugin.PluginExecutionException: Execution default-test of 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
 [11:17:10] 

[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14551820#comment-14551820
 ] 

Kristian Rosenvold commented on SUREFIRE-1157:
--

I would really like to see some evidence (documentation) that file works 
anywhere near reliable as an IPC mechanisms across all platforms. From what I 
recall it's pretty awful. And as far as I know we have little control of what 
kind of file system we're actually on, it might even be networked.

 Surefire fork communication fails when a native library writes to stdout
 

 Key: SUREFIRE-1157
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1157
 Project: Maven Surefire
  Issue Type: Bug
  Components: process forking
Affects Versions: 2.17
Reporter: Dan Berindei

 We are seeing this exception in some of our CI builds:
 {noformat}
 [11:17:10]W:   [Step 2/4] [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
 project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null:
  NoSuchElementException - [Help 1]
 [11:17:10] :   [Step 2/4] 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) 
 on project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [11:17:10] :   [Step 2/4] at 
 java.lang.reflect.Method.invoke(Method.java:483)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
 [11:17:10] :   [Step 2/4] Caused by: 
 org.apache.maven.plugin.PluginExecutionException: Execution default-test of 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
 [11:17:10] :   [Step 2/4] ... 19 more
 [11:17:10] :   [Step 2/4] Caused by: 

[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14551823#comment-14551823
 ] 

Kristian Rosenvold commented on SUREFIRE-1157:
--

@Tibor; if we did hop down the JNI hole I'm sure we'd have to make our own 
unique binary. 

 Surefire fork communication fails when a native library writes to stdout
 

 Key: SUREFIRE-1157
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1157
 Project: Maven Surefire
  Issue Type: Bug
  Components: process forking
Affects Versions: 2.17
Reporter: Dan Berindei

 We are seeing this exception in some of our CI builds:
 {noformat}
 [11:17:10]W:   [Step 2/4] [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
 project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null:
  NoSuchElementException - [Help 1]
 [11:17:10] :   [Step 2/4] 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) 
 on project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [11:17:10] :   [Step 2/4] at 
 java.lang.reflect.Method.invoke(Method.java:483)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
 [11:17:10] :   [Step 2/4] Caused by: 
 org.apache.maven.plugin.PluginExecutionException: Execution default-test of 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:143)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
 [11:17:10] :   [Step 2/4] ... 19 more
 [11:17:10] :   [Step 2/4] Caused by: java.lang.RuntimeException: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 

[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550583#comment-14550583
 ] 

Kristian Rosenvold commented on SUREFIRE-1157:
--

What appears to be a simple solution escalates to a massive can of worms once 
you try to do this on millions of computers with various levels of 
(mis)configuration, firewall software and other security features. Additionally 
you can bet there's the odd CI server out there running tens of parallel jobs 
that will exhaust the available socket space (all available sockets in 
SO_LINGER).  The sockets themselves are also prone to various failures, at 
least when run a few hundred million times a day like we do. The comms are 
bidirectional BTW, and a regular file does not really provide the kind of 
interprocess visibility we'd like to have (AFAIK there is really *no* guarantee 
by most major OS'es in this regard...)

Of course, if we make it possible to plug the transport mechanism, there's 
nothing wrong in making a socket version. For specific usage I'm sure it might 
work fine enough; it just does not work very well as a default mechanism for 
everyone - the current solution is IMO a better all purpose solution.

 Surefire fork communication fails when a native library writes to stdout
 

 Key: SUREFIRE-1157
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1157
 Project: Maven Surefire
  Issue Type: Bug
  Components: process forking
Affects Versions: 2.17
Reporter: Dan Berindei

 We are seeing this exception in some of our CI builds:
 {noformat}
 [11:17:10]W:   [Step 2/4] [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
 project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null:
  NoSuchElementException - [Help 1]
 [11:17:10] :   [Step 2/4] 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) 
 on project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 [11:17:10] :   [Step 2/4] at 
 java.lang.reflect.Method.invoke(Method.java:483)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
 [11:17:10] :   [Step 2/4] at 
 org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
 [11:17:10] :   [Step 2/4] at 
 

[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550415#comment-14550415
 ] 

Kristian Rosenvold commented on SUREFIRE-1157:
--

I know from my work in the selenium project that allocating ports is a fast 
path to a place with guys wielding pitchforks and lots of flames. It's even 
worse than parsing [XML with regex | 
http://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags].
 So we dont allocate ports; ever. I will veto any change that allocates 
sockets. I will actually raise from the grave even after my death to haunt 
anyone that even tries to code a patch to allocate sockets for this. Even JNI 
is moderately acceptable when compared to the eternal damnation faced by Those 
Who Allocate Ports. JNI-based OS specific strategies with a fallback to the 
current strategy sounds infinitely plausible compared allocating TCP ports. 
Shared memory, Named pipes or unix domain sockets, morse code or screen 
scraping are all preferable.

If we were to try anything shared-memory like we must also consider that Unsafe 
is gone in java9, so there'd have to be something like a memory mapped file 
(but they are riddled with caveats on windows, so we'd need something different 
there :). Which would also mean we'd have to find some way to spoof the 
security manager (I /think/ it was possible to turn the security manage on 
*after* doing initial setup, but this is about 5 years ago for me and I have 
trouble remembering what I ate for dinner yesterday)

It would appear to me that it would be wise to start something like this by 
making it possible to choose different strategies, hopefully just by inspecting 
OS level features.

 Surefire fork communication fails when a native library writes to stdout
 

 Key: SUREFIRE-1157
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1157
 Project: Maven Surefire
  Issue Type: Bug
  Components: process forking
Affects Versions: 2.17
Reporter: Dan Berindei

 We are seeing this exception in some of our CI builds:
 {noformat}
 [11:17:10]W:   [Step 2/4] [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
 project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null:
  NoSuchElementException - [Help 1]
 [11:17:10] :   [Step 2/4] 
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute 
 goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) 
 on project infinispan-cachestore-leveldb: Execution default-test of goal 
 org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: 
 java.lang.RuntimeException: 
 1,org.infinispan.persistence.leveldb.LevelDBStoreTest,testStoreAndRemove(org.infinispan.persistence.leveldb.LevelDBStoreTest),unit,null,null
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
 [11:17:10] :   [Step 2/4] at 
 org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 [11:17:10] :   [Step 2/4] at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 [11:17:10] :   [Step 2/4] at 
 

[jira] [Commented] (MASSEMBLY-768) JarInputStream unable to find manifest created by version 2.5.4

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14548351#comment-14548351
 ] 

Kristian Rosenvold commented on MASSEMBLY-768:
--

Fixed in p-archiver f6dd0976c070440eca0d060cb8baf2b99567b615

 JarInputStream unable to find  manifest created by version 2.5.4
 

 Key: MASSEMBLY-768
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-768
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.4
 Environment: windows 64 bit, java 8. maven 3.3..3
Reporter: Vlad Skarzhevskyy
Assignee: Kristian Rosenvold
Priority: Critical
 Fix For: 2.5.5

 Attachments: mco.xml, pom.xml


 The problem is non trivial to reproduce. Changing back to version 2.5.3 
 resolves the problem.
 On some computers plugin creates a jar file with manifest unreadable by java. 
 JarInputStream
 see comments in JarInputStream(InputStream in, boolean verify)
 java expects manifest to be either the first or the second entry in archive.
 looking at the gnerated jar using winrar generate report i see that in broken 
 files MANIFEST.MF  is not in right place.
 In example below it is third place.
 {noformat}
 #  Archive D:\sample-java\target\sample-bad.jar
 2015-05-15 20:19FolderFolder  META-INF
 2015-05-15 20:19FolderFolder  META-INF\lib
 2015-05-15 20:19   274   203  META-INF\MANIFEST.MF
 2015-05-14 01:43 10106  8342  
 META-INF\lib\mco2-sample-java-2.6.0-SNAPSHOT.jar
 2015-03-04 15:46  8262  7790  mco2-sample-java.mco.png
 2015-03-04 15:46 10400  1564  mco2-sample-java.mco.xml
 #
 # Total   SizePacked  Files
 #29042 17899  6
 {noformat}
 Please let me know if you need additional info. Or a complete test project.
 My assembly descriptor and partial pom with configuration will be attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MASSEMBLY-768) JarInputStream unable to find manifest created by version 2.5.4

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MASSEMBLY-768:
-
Fix Version/s: 2.5.5

 JarInputStream unable to find  manifest created by version 2.5.4
 

 Key: MASSEMBLY-768
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-768
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.4
 Environment: windows 64 bit, java 8. maven 3.3..3
Reporter: Vlad Skarzhevskyy
Assignee: Kristian Rosenvold
Priority: Critical
 Fix For: 2.5.5

 Attachments: mco.xml, pom.xml


 The problem is non trivial to reproduce. Changing back to version 2.5.3 
 resolves the problem.
 On some computers plugin creates a jar file with manifest unreadable by java. 
 JarInputStream
 see comments in JarInputStream(InputStream in, boolean verify)
 java expects manifest to be either the first or the second entry in archive.
 looking at the gnerated jar using winrar generate report i see that in broken 
 files MANIFEST.MF  is not in right place.
 In example below it is third place.
 {noformat}
 #  Archive D:\sample-java\target\sample-bad.jar
 2015-05-15 20:19FolderFolder  META-INF
 2015-05-15 20:19FolderFolder  META-INF\lib
 2015-05-15 20:19   274   203  META-INF\MANIFEST.MF
 2015-05-14 01:43 10106  8342  
 META-INF\lib\mco2-sample-java-2.6.0-SNAPSHOT.jar
 2015-03-04 15:46  8262  7790  mco2-sample-java.mco.png
 2015-03-04 15:46 10400  1564  mco2-sample-java.mco.xml
 #
 # Total   SizePacked  Files
 #29042 17899  6
 {noformat}
 Please let me know if you need additional info. Or a complete test project.
 My assembly descriptor and partial pom with configuration will be attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (MASSEMBLY-768) JarInputStream unable to find manifest created by version 2.5.4

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold updated MASSEMBLY-768:
-
Priority: Critical  (was: Major)

 JarInputStream unable to find  manifest created by version 2.5.4
 

 Key: MASSEMBLY-768
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-768
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.4
 Environment: windows 64 bit, java 8. maven 3.3..3
Reporter: Vlad Skarzhevskyy
Assignee: Kristian Rosenvold
Priority: Critical
 Attachments: mco.xml, pom.xml


 The problem is non trivial to reproduce. Changing back to version 2.5.3 
 resolves the problem.
 On some computers plugin creates a jar file with manifest unreadable by java. 
 JarInputStream
 see comments in JarInputStream(InputStream in, boolean verify)
 java expects manifest to be either the first or the second entry in archive.
 looking at the gnerated jar using winrar generate report i see that in broken 
 files MANIFEST.MF  is not in right place.
 In example below it is third place.
 {noformat}
 #  Archive D:\sample-java\target\sample-bad.jar
 2015-05-15 20:19FolderFolder  META-INF
 2015-05-15 20:19FolderFolder  META-INF\lib
 2015-05-15 20:19   274   203  META-INF\MANIFEST.MF
 2015-05-14 01:43 10106  8342  
 META-INF\lib\mco2-sample-java-2.6.0-SNAPSHOT.jar
 2015-03-04 15:46  8262  7790  mco2-sample-java.mco.png
 2015-03-04 15:46 10400  1564  mco2-sample-java.mco.xml
 #
 # Total   SizePacked  Files
 #29042 17899  6
 {noformat}
 Please let me know if you need additional info. Or a complete test project.
 My assembly descriptor and partial pom with configuration will be attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (MASSEMBLY-768) JarInputStream unable to find manifest created by version 2.5.4

[Kristian Rosenvold (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MASSEMBLY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristian Rosenvold reassigned MASSEMBLY-768:


Assignee: Kristian Rosenvold

 JarInputStream unable to find  manifest created by version 2.5.4
 

 Key: MASSEMBLY-768
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-768
 Project: Maven Assembly Plugin
  Issue Type: Bug
Affects Versions: 2.5.4
 Environment: windows 64 bit, java 8. maven 3.3..3
Reporter: Vlad Skarzhevskyy
Assignee: Kristian Rosenvold
 Attachments: mco.xml, pom.xml


 The problem is non trivial to reproduce. Changing back to version 2.5.3 
 resolves the problem.
 On some computers plugin creates a jar file with manifest unreadable by java. 
 JarInputStream
 see comments in JarInputStream(InputStream in, boolean verify)
 java expects manifest to be either the first or the second entry in archive.
 looking at the gnerated jar using winrar generate report i see that in broken 
 files MANIFEST.MF  is not in right place.
 In example below it is third place.
 {noformat}
 #  Archive D:\sample-java\target\sample-bad.jar
 2015-05-15 20:19FolderFolder  META-INF
 2015-05-15 20:19FolderFolder  META-INF\lib
 2015-05-15 20:19   274   203  META-INF\MANIFEST.MF
 2015-05-14 01:43 10106  8342  
 META-INF\lib\mco2-sample-java-2.6.0-SNAPSHOT.jar
 2015-03-04 15:46  8262  7790  mco2-sample-java.mco.png
 2015-03-04 15:46 10400  1564  mco2-sample-java.mco.xml
 #
 # Total   SizePacked  Files
 #29042 17899  6
 {noformat}
 Please let me know if you need additional info. Or a complete test project.
 My assembly descriptor and partial pom with configuration will be attached



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-737) Generated WAR file does not contain the same default manifest entries as created by the Maven WAR Plugin

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14543944#comment-14543944
 ] 

Kristian Rosenvold commented on MASSEMBLY-737:
--

Funny you mention it :) There has been some refactoring done in plexus-archiver 
that now allows it to handle all kinds of weird merges properly, some of 
which was done with this issue in mind. I will take a look at your testcase 
now, this should be solvable now :)

 Generated WAR file does not contain the same default manifest entries as 
 created by the Maven WAR Plugin
 

 Key: MASSEMBLY-737
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-737
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: manifest, maven-archiver
Affects Versions: 2.5.2
Reporter: Michael Osipov
 Attachments: massembly-737.zip


 I am repackaging a WAR file with some files exchanged. The original fiel 
 contains following manifest entries:
 {noformat}
 Manifest-Version: 1.0
 Built-By: osipovmi
 Build-Jdk: 1.7.0_55
 Created-By: Apache Maven 3.2.2
 Archiver-Version: Plexus Archiver
 {noformat}
 The {{MANIFEST.MF}} generated by this plugin looks like:
 {noformat}
 Manifest-Version: 1.0
 Created-By: 24.55-b03 (Oracle Corporation)
 Archiver-Version: Plexus Archiver
 {noformat}
 while the descriptor looks very simple:
 {code}
 assembly
 
 xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 
 xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
  http://maven.apache.org/xsd/assembly-1.1.2.xsd;
 iddeployable/id
 formats
 formatwar/format
 /formats
 includeBaseDirectoryfalse/includeBaseDirectory
 dependencySets
 dependencySet
 unpacktrue/unpack
 useProjectArtifactfalse/useProjectArtifact
 /dependencySet
 /dependencySets
 /assembly
 {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SUREFIRE-1017) Failures do not show test-package since 2.13

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14541370#comment-14541370
 ] 

Kristian Rosenvold commented on SUREFIRE-1017:
--

How hard would it be to dynamically expand the amount of package info we show 
to ensure uniqueness ? /me wonders



 Failures do not show test-package since 2.13
 

 Key: SUREFIRE-1017
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1017
 Project: Maven Surefire
  Issue Type: Improvement
Affects Versions: 2.13, 2.14, 2.15
Reporter: Christian Spriegel
Assignee: Tibor Digana
 Fix For: 3.0


 Older versions of surefire always showed the package name of each failed test 
 in the result overview.
 Since surefire 2.13 I simply get the classname:
 {code}
 Results :
 Failed tests: 
  RoundtripTestAbstractTestNGSpringContextTests.run:196-test:115 error
  RoundtripTestAbstractTestNGSpringContextTests.run:196-test:115 error
 {code}
 As you can see I have two tests called RoundtripTest in the overview. These 
 testclasses are in different packages, but I do not know which one is which.
 My testsuite has 830 testcases, where ~650 are called RoundtripTest. So its 
 quite hard now for me to identify the failing tests.
 SUREFIRE-936 seems to have changed this. I have not checked the git commit, 
 but from the description I assume that was the change.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-766) OOM with 1CPU

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526844#comment-14526844
 ] 

Kristian Rosenvold commented on MASSEMBLY-766:
--

I am not entirely sure I understand this issue. You seemingly OOM'ed on a 
single cpu core, but it works fine with a bunch of cores ? Or did just too many 
things change when the problem went away ? My initial reaction was that this 
was a concurrency problem, but there may be a different explanation:

The semantics of unpacking zip files for including into other archives also 
changed; we tend to keep the underlying source zip files open for a longer 
time on 2.5.4 than we did on 2.5.3, this may have adverse effects on memory 
consumption when (for instance) unpacking a large number of zip/jar files into 
a larger file. From the stack trace you're supplying it actually may look like 
that's the case.

The simplest way to actually find the problem would be to diff a profiler run 
with 2.5.3 vs 2.5.4; any chance you could try that ?



 OOM with 1CPU
 -

 Key: MASSEMBLY-766
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-766
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: 2.5.4
 Environment: jdk 8, sles 11.3, 1G heap build large assemblies 100M +
Reporter: Dan Tran

 Just happen to run on 1CPU VM, and VM crash on OOM
 sample errors
 #
 # There is insufficient memory for the Java Runtime Environment to continue.
 # Native memory allocation (malloc) failed to allocate 82576 bytes for 
 Chunk::new
 # An error report file with more information is saved as:
 # /var/lib/jenkins/jobs/-all-bugId-template/workspace/hs_err_pid26261.log
 #
 # Compiler replay data is saved as:
 # /var/lib/jenkins/jobs/xxx-all-bugId-template/workspace/replay_pid26261.log
 Build step 'Invoke top-level Maven targets' marked build as failure
 another one
 [INFO] --- maven-assembly-plugin:2.5.4:single (uber-jar) @ xxx-configmgr ---
 mmap failed for CEN and END part of zip file
 java.lang.OutOfMemoryError
   at java.util.zip.ZipFile.open(Native Method)
 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$1.getResource(PlexusIoZipFileResourceCollection.java:69)
   at 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$ZipFileResourceIterator$1.getURL(PlexusIoZipFileResourceCollection.java:125)
   at 
 org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:37)
   at 
 org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:126)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:514)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:370)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:326)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:227)
   at 
 org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:990)
   at 
 org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:437)
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MASSEMBLY-766) OOM with 1CPU

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14525078#comment-14525078
 ] 

Kristian Rosenvold edited comment on MASSEMBLY-766 at 5/2/15 6:14 AM:
--

Exactly how large are your assemblies and how many cores does your CPU report ? 
(cat /proc/cpuinfo)


was (Author: krosenvold):
Exactly how large are your assemblies ?

 OOM with 1CPU
 -

 Key: MASSEMBLY-766
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-766
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: 2.5.4
 Environment: jdk 8, sles 11.3, 1G heap build large assemblies 100M +
Reporter: Dan Tran

 Just happen to run on 1CPU VM, and VM crash on OOM
 sample errors
 #
 # There is insufficient memory for the Java Runtime Environment to continue.
 # Native memory allocation (malloc) failed to allocate 82576 bytes for 
 Chunk::new
 # An error report file with more information is saved as:
 # /var/lib/jenkins/jobs/-all-bugId-template/workspace/hs_err_pid26261.log
 #
 # Compiler replay data is saved as:
 # /var/lib/jenkins/jobs/xxx-all-bugId-template/workspace/replay_pid26261.log
 Build step 'Invoke top-level Maven targets' marked build as failure
 another one
 [INFO] --- maven-assembly-plugin:2.5.4:single (uber-jar) @ xxx-configmgr ---
 mmap failed for CEN and END part of zip file
 java.lang.OutOfMemoryError
   at java.util.zip.ZipFile.open(Native Method)
 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$1.getResource(PlexusIoZipFileResourceCollection.java:69)
   at 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$ZipFileResourceIterator$1.getURL(PlexusIoZipFileResourceCollection.java:125)
   at 
 org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:37)
   at 
 org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:126)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:514)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:370)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:326)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:227)
   at 
 org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:990)
   at 
 org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:437)
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-766) OOM with 1CPU

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14525078#comment-14525078
 ] 

Kristian Rosenvold commented on MASSEMBLY-766:
--

Exactly how large are your assemblies ?

 OOM with 1CPU
 -

 Key: MASSEMBLY-766
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-766
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: 2.5.4
 Environment: jdk 8, sles 11.3, 1G heap build large assemblies 100M +
Reporter: Dan Tran

 Just happen to run on 1CPU VM, and VM crash on OOM
 sample errors
 #
 # There is insufficient memory for the Java Runtime Environment to continue.
 # Native memory allocation (malloc) failed to allocate 82576 bytes for 
 Chunk::new
 # An error report file with more information is saved as:
 # /var/lib/jenkins/jobs/-all-bugId-template/workspace/hs_err_pid26261.log
 #
 # Compiler replay data is saved as:
 # /var/lib/jenkins/jobs/xxx-all-bugId-template/workspace/replay_pid26261.log
 Build step 'Invoke top-level Maven targets' marked build as failure
 another one
 [INFO] --- maven-assembly-plugin:2.5.4:single (uber-jar) @ xxx-configmgr ---
 mmap failed for CEN and END part of zip file
 java.lang.OutOfMemoryError
   at java.util.zip.ZipFile.open(Native Method)
 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$1.getResource(PlexusIoZipFileResourceCollection.java:69)
   at 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$ZipFileResourceIterator$1.getURL(PlexusIoZipFileResourceCollection.java:125)
   at 
 org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:37)
   at 
 org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:126)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:514)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:370)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:326)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:227)
   at 
 org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:990)
   at 
 org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:437)
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MDEP-442) Failed to access file due to locked access when using more than one Maven worker thread

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522931#comment-14522931
 ] 

Kristian Rosenvold commented on MDEP-442:
-

@Karl; the bug is valid. Copy should not lock the source file

 Failed to access file due to locked access when using more than one Maven 
 worker thread
 ---

 Key: MDEP-442
 URL: https://issues.apache.org/jira/browse/MDEP-442
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.8
 Environment: MVN 3.0.4, JDK 1.7, Win 7 Pro SP1 64 Bit
Reporter: Markus Karg
Priority: Critical
 Fix For: waiting-for-feedback

 Attachments: maven-thread-test-update.zip, maven-thread-test.zip


 My multi-module POM contains of ten modules. Each of that modules does the 
 same: Invoke the 'copy' goal of the dependency plugin. The idea is to have 
 ten copies of the identical source, which then will end up in ten different 
 targets by getting furthere processed.
 As long as I do not use more than one Maven worker thread, everything works 
 well always. But when using -T 5 to have five worker threads, rather often 
 the reactor fails because the source file (!) is locked:
 {noformat}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project 
 MYARTIFACT: Unable to resolve artifact. Could not transfer artifact 
 mygroup:myartifact:dll:4.36.1-20140415.143537-37 from/to nexus 
 (http://nexus/nexus/content/groups/public): 
 C:\Users\jenkins.QUIPSY\.m2\repository\mygroup\myartifact\4.36.1-SNAPSHOT\myartifact-4.36.1-20140415.143537-37.dll
  (The process cannot access the file, because it is in use by another process)
 {noformat}
 So it seems that the 'copy' task actually is locking the source file, which 
 is not multi-threading-compatible. Hence, either that is a bug and should get 
 fixed, or it is on purpose, then this goal has to be marked as 
 non-multithreading-able.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MDEP-442) Failed to access file due to locked access when using more than one Maven worker thread

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MDEP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522931#comment-14522931
 ] 

Kristian Rosenvold edited comment on MDEP-442 at 5/1/15 8:23 AM:
-

@Karl; the bug is valid. Copy should not lock the source file. This is within 
the same JVM


was (Author: krosenvold):
@Karl; the bug is valid. Copy should not lock the source file

 Failed to access file due to locked access when using more than one Maven 
 worker thread
 ---

 Key: MDEP-442
 URL: https://issues.apache.org/jira/browse/MDEP-442
 Project: Maven Dependency Plugin
  Issue Type: Bug
  Components: copy
Affects Versions: 2.8
 Environment: MVN 3.0.4, JDK 1.7, Win 7 Pro SP1 64 Bit
Reporter: Markus Karg
Priority: Critical
 Fix For: waiting-for-feedback

 Attachments: maven-thread-test-update.zip, maven-thread-test.zip


 My multi-module POM contains of ten modules. Each of that modules does the 
 same: Invoke the 'copy' goal of the dependency plugin. The idea is to have 
 ten copies of the identical source, which then will end up in ten different 
 targets by getting furthere processed.
 As long as I do not use more than one Maven worker thread, everything works 
 well always. But when using -T 5 to have five worker threads, rather often 
 the reactor fails because the source file (!) is locked:
 {noformat}
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-dependency-plugin:2.8:copy (copy) on project 
 MYARTIFACT: Unable to resolve artifact. Could not transfer artifact 
 mygroup:myartifact:dll:4.36.1-20140415.143537-37 from/to nexus 
 (http://nexus/nexus/content/groups/public): 
 C:\Users\jenkins.QUIPSY\.m2\repository\mygroup\myartifact\4.36.1-SNAPSHOT\myartifact-4.36.1-20140415.143537-37.dll
  (The process cannot access the file, because it is in use by another process)
 {noformat}
 So it seems that the 'copy' task actually is locking the source file, which 
 is not multi-threading-compatible. Hence, either that is a bug and should get 
 fixed, or it is on purpose, then this goal has to be marked as 
 non-multithreading-able.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MASSEMBLY-766) OOM with 1CPU

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523992#comment-14523992
 ] 

Kristian Rosenvold commented on MASSEMBLY-766:
--

Oops. The intended behaviour was max 10mb per CPU core. It seems there was an 
extra 0 in there, making the maximum 100mb per cpu core and the effective 
minimum 10mb per core (in 10mb increments) This was definitely somewhat outside 
the intemded bounds. The idea was to use approx 160Mb on at 8 core + 8 ht cpu 
before offloading to disk, which should be an acceptable memory hit. But still, 
if your zip/jar file is in the region of 100mb it should only use somewhere in 
the region of  100-200mb even with the current algorithm. Does adding a little 
extra memory solve the problem ?

 OOM with 1CPU
 -

 Key: MASSEMBLY-766
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-766
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: 2.5.4
 Environment: jdk 8, sles 11.3, 1G heap build large assemblies 100M +
Reporter: Dan Tran

 Just happen to run on 1CPU VM, and VM crash on OOM
 sample errors
 #
 # There is insufficient memory for the Java Runtime Environment to continue.
 # Native memory allocation (malloc) failed to allocate 82576 bytes for 
 Chunk::new
 # An error report file with more information is saved as:
 # /var/lib/jenkins/jobs/-all-bugId-template/workspace/hs_err_pid26261.log
 #
 # Compiler replay data is saved as:
 # /var/lib/jenkins/jobs/xxx-all-bugId-template/workspace/replay_pid26261.log
 Build step 'Invoke top-level Maven targets' marked build as failure
 another one
 [INFO] --- maven-assembly-plugin:2.5.4:single (uber-jar) @ xxx-configmgr ---
 mmap failed for CEN and END part of zip file
 java.lang.OutOfMemoryError
   at java.util.zip.ZipFile.open(Native Method)
 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$1.getResource(PlexusIoZipFileResourceCollection.java:69)
   at 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$ZipFileResourceIterator$1.getURL(PlexusIoZipFileResourceCollection.java:125)
   at 
 org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:37)
   at 
 org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:126)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:514)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:370)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:326)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:227)
   at 
 org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:990)
   at 
 org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:437)
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MASSEMBLY-766) OOM with 1CPU

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523992#comment-14523992
 ] 

Kristian Rosenvold edited comment on MASSEMBLY-766 at 5/1/15 9:32 PM:
--

Oops. The intended behaviour was max 10mb per CPU core (effective minimum 1mb 
per core). It seems there was an extra 0 in there, making the maximum 100mb per 
cpu core and the effective minimum 10mb per core (increasing in 10mb 
increments) This was definitely somewhat outside the intended bounds. The idea 
was to use approx 160Mb on at 8 core + 8 ht cpu before offloading to disk, 
which should be an acceptable memory hit. But still, if your zip/jar file is in 
the region of 100mb it should only use somewhere in the region of  100-200mb 
even with the current algorithm. Does adding a little extra memory solve the 
problem ?


was (Author: krosenvold):
Oops. The intended behaviour was max 10mb per CPU core. It seems there was an 
extra 0 in there, making the maximum 100mb per cpu core and the effective 
minimum 10mb per core (in 10mb increments) This was definitely somewhat outside 
the intemded bounds. The idea was to use approx 160Mb on at 8 core + 8 ht cpu 
before offloading to disk, which should be an acceptable memory hit. But still, 
if your zip/jar file is in the region of 100mb it should only use somewhere in 
the region of  100-200mb even with the current algorithm. Does adding a little 
extra memory solve the problem ?

 OOM with 1CPU
 -

 Key: MASSEMBLY-766
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-766
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: 2.5.4
 Environment: jdk 8, sles 11.3, 1G heap build large assemblies 100M +
Reporter: Dan Tran

 Just happen to run on 1CPU VM, and VM crash on OOM
 sample errors
 #
 # There is insufficient memory for the Java Runtime Environment to continue.
 # Native memory allocation (malloc) failed to allocate 82576 bytes for 
 Chunk::new
 # An error report file with more information is saved as:
 # /var/lib/jenkins/jobs/-all-bugId-template/workspace/hs_err_pid26261.log
 #
 # Compiler replay data is saved as:
 # /var/lib/jenkins/jobs/xxx-all-bugId-template/workspace/replay_pid26261.log
 Build step 'Invoke top-level Maven targets' marked build as failure
 another one
 [INFO] --- maven-assembly-plugin:2.5.4:single (uber-jar) @ xxx-configmgr ---
 mmap failed for CEN and END part of zip file
 java.lang.OutOfMemoryError
   at java.util.zip.ZipFile.open(Native Method)
 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$1.getResource(PlexusIoZipFileResourceCollection.java:69)
   at 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$ZipFileResourceIterator$1.getURL(PlexusIoZipFileResourceCollection.java:125)
   at 
 org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:37)
   at 
 org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:126)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:514)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:370)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:326)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:227)
   at 
 org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:990)
   at 
 org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:437)
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MASSEMBLY-766) OOM with 1CPU

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523992#comment-14523992
 ] 

Kristian Rosenvold edited comment on MASSEMBLY-766 at 5/1/15 9:43 PM:
--

Sorry, I read the code all wrong in mu initial response.

The current code is aligned for using 10mb per cpu core before offloading to 
disk. So if you CPU has 8 cores + 8 ht you're looking at 160mb increased memory 
usage. All of this is an increase when compared with 2.5.3. Would this seem to 
fit for your case ? (I.e. does increasin -Xmx with 150-ish megs solve the 
problem ?)




was (Author: krosenvold):
Oops. The intended behaviour was max 10mb per CPU core (effective minimum 1mb 
per core). It seems there was an extra 0 in there, making the maximum 100mb per 
cpu core and the effective minimum 10mb per core (increasing in 10mb 
increments) This was definitely somewhat outside the intended bounds. The idea 
was to use approx 160Mb on at 8 core + 8 ht cpu before offloading to disk, 
which should be an acceptable memory hit. But still, if your zip/jar file is in 
the region of 100mb it should only use somewhere in the region of  100-200mb 
even with the current algorithm. Does adding a little extra memory solve the 
problem ?

 OOM with 1CPU
 -

 Key: MASSEMBLY-766
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-766
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: 2.5.4
 Environment: jdk 8, sles 11.3, 1G heap build large assemblies 100M +
Reporter: Dan Tran

 Just happen to run on 1CPU VM, and VM crash on OOM
 sample errors
 #
 # There is insufficient memory for the Java Runtime Environment to continue.
 # Native memory allocation (malloc) failed to allocate 82576 bytes for 
 Chunk::new
 # An error report file with more information is saved as:
 # /var/lib/jenkins/jobs/-all-bugId-template/workspace/hs_err_pid26261.log
 #
 # Compiler replay data is saved as:
 # /var/lib/jenkins/jobs/xxx-all-bugId-template/workspace/replay_pid26261.log
 Build step 'Invoke top-level Maven targets' marked build as failure
 another one
 [INFO] --- maven-assembly-plugin:2.5.4:single (uber-jar) @ xxx-configmgr ---
 mmap failed for CEN and END part of zip file
 java.lang.OutOfMemoryError
   at java.util.zip.ZipFile.open(Native Method)
 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$1.getResource(PlexusIoZipFileResourceCollection.java:69)
   at 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$ZipFileResourceIterator$1.getURL(PlexusIoZipFileResourceCollection.java:125)
   at 
 org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:37)
   at 
 org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:126)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:514)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:370)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:326)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:227)
   at 
 org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:990)
   at 
 org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:437)
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (MASSEMBLY-766) OOM with 1CPU

[Kristian Rosenvold (JIRA)]

[ 
https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523992#comment-14523992
 ] 

Kristian Rosenvold edited comment on MASSEMBLY-766 at 5/1/15 9:43 PM:
--

Sorry, I read the code all wrong in my initial response.

The current code is aligned for using 10mb per cpu core before offloading to 
disk. So if you CPU has 8 cores + 8 ht you're looking at 160mb increased memory 
usage. All of this is an increase when compared with 2.5.3. Would this seem to 
fit for your case ? (I.e. does increasin -Xmx with 150-ish megs solve the 
problem ?)




was (Author: krosenvold):
Sorry, I read the code all wrong in mu initial response.

The current code is aligned for using 10mb per cpu core before offloading to 
disk. So if you CPU has 8 cores + 8 ht you're looking at 160mb increased memory 
usage. All of this is an increase when compared with 2.5.3. Would this seem to 
fit for your case ? (I.e. does increasin -Xmx with 150-ish megs solve the 
problem ?)



 OOM with 1CPU
 -

 Key: MASSEMBLY-766
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-766
 Project: Maven Assembly Plugin
  Issue Type: Bug
  Components: maven-archiver
Affects Versions: 2.5.4
 Environment: jdk 8, sles 11.3, 1G heap build large assemblies 100M +
Reporter: Dan Tran

 Just happen to run on 1CPU VM, and VM crash on OOM
 sample errors
 #
 # There is insufficient memory for the Java Runtime Environment to continue.
 # Native memory allocation (malloc) failed to allocate 82576 bytes for 
 Chunk::new
 # An error report file with more information is saved as:
 # /var/lib/jenkins/jobs/-all-bugId-template/workspace/hs_err_pid26261.log
 #
 # Compiler replay data is saved as:
 # /var/lib/jenkins/jobs/xxx-all-bugId-template/workspace/replay_pid26261.log
 Build step 'Invoke top-level Maven targets' marked build as failure
 another one
 [INFO] --- maven-assembly-plugin:2.5.4:single (uber-jar) @ xxx-configmgr ---
 mmap failed for CEN and END part of zip file
 java.lang.OutOfMemoryError
   at java.util.zip.ZipFile.open(Native Method)
 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$1.getResource(PlexusIoZipFileResourceCollection.java:69)
   at 
 org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection$ZipFileResourceIterator$1.getURL(PlexusIoZipFileResourceCollection.java:125)
   at 
 org.codehaus.plexus.components.io.resources.PlexusIoURLResource.getContents(PlexusIoURLResource.java:37)
   at 
 org.codehaus.plexus.archiver.ArchiveEntry.getInputStream(ArchiveEntry.java:126)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.zipFile(AbstractZipArchiver.java:514)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.addResources(AbstractZipArchiver.java:370)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:326)
   at 
 org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:227)
   at 
 org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:990)
   at 
 org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:437)
   at 
 org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
   at 
 org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
   at 
 org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MASSEMBLY-764) Upgrade to plexus-archiver 2.10 and io 2.5

[Kristian Rosenvold (JIRA)]

Kristian Rosenvold created MASSEMBLY-764:


 Summary: Upgrade to plexus-archiver 2.10 and io 2.5
 Key: MASSEMBLY-764
 URL: https://issues.apache.org/jira/browse/MASSEMBLY-764
 Project: Maven Assembly Plugin
  Issue Type: Improvement
Reporter: Kristian Rosenvold
Assignee: Kristian Rosenvold
 Fix For: 2.5.4






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)