[jira] [Commented] (MSHARED-494) Impossible to generate a reproducible build due to timestamp in pom.properties
[ https://issues.apache.org/jira/browse/MSHARED-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&view=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
[
https://issues.apache.org/jira/browse/MDEP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MSOURCES-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> org.apache.commons.compress.archivers.zip.ParallelScatterZipCreator.access$100(ParallelScatterZi
[jira] [Assigned] (MASSEMBLY-774) too many open files
[ 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
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MSHARED-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MJAR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-416) Odd number of quotes in command-line fails
[
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] [Updated] (MSHARED-297) Commandline class shell injection vulnerabilities
[
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] [Commented] (MSHARED-317) Analyzer reports unused dependencies between modules in multi-module project
[ https://issues.apache.org/jira/browse/MSHARED-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Updated] (MSHARED-428) maven-dependency-analyzer does not detect method references
[ 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] [Closed] (MSHARED-428) maven-dependency-analyzer does not detect method references
[ 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] [Closed] (MSHADE-171) "Access Denied" on Windows because shade plugin seems to try to open a directory as Zip-File
[
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
> org.apache.maven.plugin.Def
[jira] [Closed] (MSHADE-214) Update jdepenency to 1.1 to fix resource leaks
[ 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] [Created] (MSHADE-214) Update jdepenency to 1.1 to fix resource leaks
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] [Updated] (MSHADE-213) Clarify contract of ResourceTransformer wrt closing of streams
[ 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] [Closed] (MSHADE-213) Clarify contract of ResourceTransformer wrt closing of streams
[ 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] [Assigned] (MSHADE-213) Clarify contract of ResourceTransformer wrt closing of streams
[ 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] [Created] (MSHADE-213) Clarify contract of ResourceTransformer wrt closing of streams
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] [Commented] (MSHADE-171) "Access Denied" on Windows because shade plugin seems to try to open a directory as Zip-File
[
https://issues.apache.org/jira/browse/MSHADE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> org.apache.maven.lifecycle.intern
[jira] [Commented] (MSHADE-171) "Access Denied" on Windows because shade plugin seems to try to open a directory as Zip-File
[
https://issues.apache.org/jira/browse/MSHADE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> org.apache.maven.plugin.DefaultBuildPluginManager.e
[jira] [Closed] (MASSEMBLY-788) Entry names in ZIP file are not correctly parsed when unzipping it
[
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
[
https://issues.apache.org/jira/browse/MASSEMBLY-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MNG-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Reopened] (MNG-5750) Sporadic failures in concurrent build
[
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] [Updated] (MSHARED-391) org.apache.maven.shared.repository.DefaultRepositoryAssembler#findCentralRepository does not understand mirrors
[ 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
[
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] [Commented] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core
[ https://issues.apache.org/jira/browse/SUREFIRE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > java.util
[jira] [Commented] (MNG-5750) Sporadic failures in concurrent build
[
https://issues.apache.org/jira/browse/MNG-5750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core
[ https://issues.apache.org/jira/browse/SUREFIRE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > java.ut
[jira] [Commented] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core
[ https://issues.apache.org/jira/browse/SUREFIRE-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.ja
[jira] [Created] (SUREFIRE-1182) Surefire 2.19 rc hangs when building maven core
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 java.util.concurrent
[jira] [Commented] (MSHARED-442) Remove shading of artifact instead of using simple jar
[ https://issues.apache.org/jira/browse/MSHARED-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
https://issues.apache.org/jira/browse/MDEP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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 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
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Comment Edited] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:
> http://repo.cloudbees.
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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]
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (MNG-5869) Frozen downloads with HTTP repositories and Maven 3.2 or 3.3
[
https://issues.apache.org/jira/browse/MNG-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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/
[jira] [Closed] (MASSEMBLY-781) Execution make-assembly fails: user id is too big
[
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}
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 2.5.5
>
>
> src/assembly/bin-assembly.xml
> src/assembly/src-assembly.xml
>
>
>
>
> make-assembly
> package
>
> single
>
>
>
>
> {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
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at
[jira] [Closed] (MASSEMBLY-704) Remove all goals which are marked deprecated
[ 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
[
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.jav
[jira] [Commented] (MNG-5847) Maven controls java.library.path
[ https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 * (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
[ https://issues.apache.org/jira/browse/MNG-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 * (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
[ 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
[ 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] [Commented] (MASSEMBLY-774) too many open files
[ https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: > > 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] [Comment Edited] (MASSEMBLY-774) too many open files
[ https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: > > 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] [Comment Edited] (MNGSITE-242) not able to compile a module named as "RCS" and "SCCS"
[ https://issues.apache.org/jira/browse/MNGSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] (MNGSITE-242) not able to compile a module named as "RCS" and "SCCS"
[ https://issues.apache.org/jira/browse/MNGSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] (MNGSITE-242) not able to compile a module named as "RCS" and "SCCS"
[ https://issues.apache.org/jira/browse/MNGSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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"
[ https://issues.apache.org/jira/browse/MNGSITE-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] (MASSEMBLY-759) tar outputs missing entries for target directory.
[
https://issues.apache.org/jira/browse/MASSEMBLY-759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
> 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";>
> tarball
>
> tar
> tbz2
>
> false
>
>
> ./lib
> 0755
> true
> false
> runtime
>
> *:javaee-web-api
>
>
>
>
> {quote}
> Does not output a tar record for the created "lib"directory, 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] [Comment Edited] (MASSEMBLY-774) too many open files
[ https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: > > 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] [Comment Edited] (MASSEMBLY-774) too many open files
[ https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: > > 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] (MASSEMBLY-774) too many open files
[ https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: > > 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] [Comment Edited] (MASSEMBLY-774) too many open files
[ https://issues.apache.org/jira/browse/MASSEMBLY-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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: > > 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] [Updated] (MSHARED-426) Upgrade maven-assembly-plugin to Version 2.5.5
[ 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] [Resolved] (MSHARED-426) Upgrade maven-assembly-plugin to Version 2.5.5
[ 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] [Closed] (MASSEMBLY-773) MetaInfServicesHandler catalog is not cleared between invocations in multimodule projects
[
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
[ https://issues.apache.org/jira/browse/MASSEMBLY-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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) > > CP850 > > 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] [Updated] (MASSEMBLY-772) tar.gz contents owned by user who ran build
[ 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] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows
[ 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] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows
[ https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (MASSEMBLY-771) Regression: Unable to create tar.gz in cross-platform build without error messages on Windows
[ https://issues.apache.org/jira/browse/MASSEMBLY-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Closed] (MSHARED-331) Sections in own manifest file are mixed up
[
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}
>
> org.apache.maven.plugins
> maven-jar-plugin
> 2.4
>
>
>
>
> ${project.version}
>
> manifest.mf
>
>
>
> {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 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] (MSHARED-331) Sections in own manifest file are mixed up
[
https://issues.apache.org/jira/browse/MSHARED-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14577636#comment-14577636
]
Kristian Rosenvold commented on MSHARED-331:
Sections are preserved as long as the blank line separating sections does not
contain anything, like spaces. I am quite certain this is the JDK parsing code
that acts this way, so I believe the issue is invalid.
> 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
>
> I'm using my own manifest file as described
> [here|http://maven.apache.org/shared/maven-archiver/examples/manifestFile.html].
> Plugin-Config:
> {code:xml}
>
> org.apache.maven.plugins
> maven-jar-plugin
> 2.4
>
>
>
>
> ${project.version}
>
> manifest.mf
>
>
>
> {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 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] [Updated] (MASSEMBLY-752) [PATCH] Option to ignore empty directories in fileSet directory
[ 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 : > > src > / > > 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 : > > src > / > false > > 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] [Updated] (MASSEMBLY-767) Schema missing from the web site
[ 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
[ 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-767) Schema missing from the web site
[ https://issues.apache.org/jira/browse/MASSEMBLY-767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Closed] (MASSEMBLY-768) JarInputStream unable to find manifest created by version 2.5.4
[
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
[
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}
>
> /
>
> test:child1
>
> true
> true
> false
> true
>
>
> l4g
> l4g.cmd
>
>
> 0755
>
> {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
[
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}
>
> /
>
> test:child1
>
> true
> true
> false
> true
>
>
> l4g
> l4g.cmd
>
>
> 0755
>
> {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-769) ZIP fileMode permissions not properly set with dependencySet and unpackOptions
[
https://issues.apache.org/jira/browse/MASSEMBLY-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
>
> /
>
> test:child1
>
> true
> true
> false
> true
>
>
> l4g
> l4g.cmd
>
>
> 0755
>
> {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
[
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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,testStoreAndRem
[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout
[
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:1
[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout
[
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:1
[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout
[
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> sun.reflect.Deleg
[jira] [Commented] (SUREFIRE-1157) Surefire fork communication fails when a native library writes to stdout
[
https://issues.apache.org/jira/browse/SUREFIRE-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.DefaultBui
[jira] [Commented] (MASSEMBLY-768) JarInputStream unable to find manifest created by version 2.5.4
[
https://issues.apache.org/jira/browse/MASSEMBLY-768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[
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
[
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
[
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
[
https://issues.apache.org/jira/browse/MASSEMBLY-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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}
>
> 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";>
> deployable
>
> war
>
> false
>
>
> true
> false
>
>
>
> {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
[
https://issues.apache.org/jira/browse/SUREFIRE-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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:
> RoundtripTest>AbstractTestNGSpringContextTests.run:196->test:115 error
> RoundtripTest>AbstractTestNGSpringContextTests.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
[ https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (MASSEMBLY-766) OOM with 1CPU
[ https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Comment Edited] (MASSEMBLY-766) OOM with 1CPU
[ https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (MASSEMBLY-766) OOM with 1CPU
[ https://issues.apache.org/jira/browse/MASSEMBLY-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] (MDEP-442) Failed to access file due to locked access when using more than one Maven worker thread
[
https://issues.apache.org/jira/browse/MDEP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] (MDEP-442) Failed to access file due to locked access when using more than one Maven worker thread
[
https://issues.apache.org/jira/browse/MDEP-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
