[jira] [Commented] (SUREFIRE-1374) std/in stream corrupted error
[
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16034205#comment-16034205
]
Hudson commented on SUREFIRE-1374:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1711 (See
[https://builds.apache.org/job/maven-surefire/1711/])
[SUREFIRE-1374] std/in stream corrupted error (tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git&a=commit&h=fac376c5f7d1b5ca9b2ec220b39b35397d04326a])
* (edit)
surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java
> std/in stream corrupted error
> -
>
> Key: SUREFIRE-1374
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: matteo rulli
>Assignee: Tibor Digana
>
> We bumbed surefire version to 2.20 (from 2.19.1) and our tests started
> generating this kind of errors:
> {code}
> # Created on 2017-05-26T10:24:04.032
> [SUREFIRE] std/in stream corrupted
> java.io.IOException: Command BYE_ACK unexpectedly read Void data with length
> 4.
> at
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Related stacktrace:
> {code}
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error
> occurred in starting fork, check output in log
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [
> {code}
> Everything worked fine with 2.19.1.
> Environment: macOS sierra, java version "1.8.0_74", Apache Maven 3.5.0
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16034169#comment-16034169
]
Tibor Digana commented on SUREFIRE-1302:
[~elecharny]
I have pushed a fix, please see my comment in SUREFIRE-1374. Thx.
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: 2017-05-18T05-48-08_685-jvmRun1.dumpstream,
> surefire-gclog.log, surefire-logs,
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1374) std/in stream corrupted error
[
https://issues.apache.org/jira/browse/SUREFIRE-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16034168#comment-16034168
]
Tibor Digana commented on SUREFIRE-1374:
[~elecharny]
[~matteor]
https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=fac376c5f7d1b5ca9b2ec220b39b35397d04326a
Can you guys check it out with this change?
The SNAPSHOT version will be available in cca 2 hours. You will need to add
section {{pluginRepositories}} with URL for snapshots
{{https://repository.apache.org/content/groups/snapshots/}}.
Maybe you are facing {{SUREFIRE-1302}} with different error message but that
should be fixed separately.
> std/in stream corrupted error
> -
>
> Key: SUREFIRE-1374
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1374
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: matteo rulli
>Assignee: Tibor Digana
>
> We bumbed surefire version to 2.20 (from 2.19.1) and our tests started
> generating this kind of errors:
> {code}
> # Created on 2017-05-26T10:24:04.032
> [SUREFIRE] std/in stream corrupted
> java.io.IOException: Command BYE_ACK unexpectedly read Void data with length
> 4.
> at
> org.apache.maven.surefire.booter.MasterProcessCommand.decode(MasterProcessCommand.java:130)
> at
> org.apache.maven.surefire.booter.CommandReader$CommandRunnable.run(CommandReader.java:386)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Related stacktrace:
> {code}
> [ERROR] Error occurred in starting fork, check output in log
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: Error
> occurred in starting fork, check output in log
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:634)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.lang.reflect.Method.invoke(Method.java:498)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [
> {code}
> Everything worked fine with 2.19.1.
> Environment: macOS sierra, java version "1.8.0_74", Apache Maven 3.5.0
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033799#comment-16033799
]
Emmanuel Lecharny commented on SUREFIRE-1302:
-
Hi Tibor,
you are right, this is more likely to be related to SUREFIRE-1374. However, I
do think it's also time related (the 20 s it takes to run the module). OTOH, it
only fails when cutting a release, so there must be something else...
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: 2017-05-18T05-48-08_685-jvmRun1.dumpstream,
> surefire-gclog.log, surefire-logs,
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030507#comment-16030507
]
Tibor Digana edited comment on SUREFIRE-1302 at 6/1/17 9:42 PM:
[~elecharny]
Your problem refers to another issue {{SUREFIRE-1374}}.
We do not understand the root cause yet.
was (Author: tibor17):
[~elecharny]
Your problem refers to another issue {{SUREFIRE-1376}}.
We do not understand the root cause yet.
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: 2017-05-18T05-48-08_685-jvmRun1.dumpstream,
> surefire-gclog.log, surefire-logs,
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (SUREFIRE-1378) Nice to have systemPropertiesFile configurable by user property
[
https://issues.apache.org/jira/browse/SUREFIRE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033730#comment-16033730
]
Tibor Digana edited comment on SUREFIRE-1378 at 6/1/17 9:31 PM:
System properties are simple but we have another config parameters which are
complicated and users have different needs. So I would like to give you chance
with all parameters with same principle of extensions in version 3.0 and not
partially with this parameter in current version.
was (Author: tibor17):
System properties are simple but we have another config parameters which are
complicated and users have different needs. So I would like to give you chance
with all parameter with same principle of extensions in version 3.0 and not
partially with this parameter in current version.
> Nice to have systemPropertiesFile configurable by user property
> ---
>
> Key: SUREFIRE-1378
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1378
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Michal Domagala
>Priority: Minor
>
> I would like to have option to configure my tests with property files. But
> property file is not required, because in 95% my tests work fine with default
> configuration.
> I used the following workaround: I configured failsafe plugin in the
> following way
> {code:xml}
>
>
>
> (...)
> maven-failsafe-plugin
> (...)
> ${my.test.props.file}
> {code}
> In 95% I call *mvn verify*, systemPropertiesFile is not found and ignored
> -all pass
> In 5% I call *mvn verify -Dmy.test.props.file=x.props*
> The problem is in 95% I get warning about missing files. Also configuration
> is unnecessary complicated
> I would like drop whole connfiguration from pom.xml and use:
> In 95% *mvn verify*
> In 5% *mvn verify -Dfailsafe.systemPropertiesFile=x.props*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1378) Nice to have systemPropertiesFile configurable by user property
[
https://issues.apache.org/jira/browse/SUREFIRE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033730#comment-16033730
]
Tibor Digana commented on SUREFIRE-1378:
System properties are simple but we have another config parameters which are
complicated and users have different needs. So I would like to give you chance
with all parameter with same principle of extensions in version 3.0 and not
partially with this parameter in current version.
> Nice to have systemPropertiesFile configurable by user property
> ---
>
> Key: SUREFIRE-1378
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1378
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Michal Domagala
>Priority: Minor
>
> I would like to have option to configure my tests with property files. But
> property file is not required, because in 95% my tests work fine with default
> configuration.
> I used the following workaround: I configured failsafe plugin in the
> following way
> {code:xml}
>
>
>
> (...)
> maven-failsafe-plugin
> (...)
> ${my.test.props.file}
> {code}
> In 95% I call *mvn verify*, systemPropertiesFile is not found and ignored
> -all pass
> In 5% I call *mvn verify -Dmy.test.props.file=x.props*
> The problem is in 95% I get warning about missing files. Also configuration
> is unnecessary complicated
> I would like drop whole connfiguration from pom.xml and use:
> In 95% *mvn verify*
> In 5% *mvn verify -Dfailsafe.systemPropertiesFile=x.props*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1378) Nice to have systemPropertiesFile configurable by user property
[
https://issues.apache.org/jira/browse/SUREFIRE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033701#comment-16033701
]
Tibor Digana commented on SUREFIRE-1378:
[~michaldo]
This is my plan with the extension
{{}}, where
{{UsersExtensionImpl}} is your class implementing
{{SyrefireSystemPropertiesExtension}} interface. Maybe we would create a module
with default implementations of interfaces.
> Nice to have systemPropertiesFile configurable by user property
> ---
>
> Key: SUREFIRE-1378
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1378
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Michal Domagala
>Priority: Minor
>
> I would like to have option to configure my tests with property files. But
> property file is not required, because in 95% my tests work fine with default
> configuration.
> I used the following workaround: I configured failsafe plugin in the
> following way
> {code:xml}
>
>
>
> (...)
> maven-failsafe-plugin
> (...)
> ${my.test.props.file}
> {code}
> In 95% I call *mvn verify*, systemPropertiesFile is not found and ignored
> -all pass
> In 5% I call *mvn verify -Dmy.test.props.file=x.props*
> The problem is in 95% I get warning about missing files. Also configuration
> is unnecessary complicated
> I would like drop whole connfiguration from pom.xml and use:
> In 95% *mvn verify*
> In 5% *mvn verify -Dfailsafe.systemPropertiesFile=x.props*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MSHADE-247) NullpointerException when createSourcesJar = true and source jar cannot be found
[
https://issues.apache.org/jira/browse/MSHADE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué closed MSHADE-247.
-
Resolution: Fixed
Assignee: Guillaume Boué
Fix Version/s: 3.0.1
> NullpointerException when createSourcesJar = true and source jar cannot be
> found
> -
>
> Key: MSHADE-247
> URL: https://issues.apache.org/jira/browse/MSHADE-247
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Sodasmile
>Assignee: Guillaume Boué
>Priority: Critical
> Fix For: 3.0.1
>
> Attachments:
> Resolving_nullpointer_exception_when_resolvedArtifact_is_null_.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Configuration as follows:
> {code}
>
> org.apache.maven.plugins
> maven-shade-plugin
>
> true
>
>
>
> package
>
> shade
>
>
>
>
> {code}
> Dependency defined as follows:
> {code}
>
> javax.jnlp
> jnlp-api
> 1.7.0_06
>
> {code}
> Sources for javax.jnlp for some reason disappeared from our maven repo proxy,
> which made maven-shade-plugin to output:
> {code}
> [INFO] Including javax.jnlp:jnlp-api:jar:1.7.0_06 in the shaded jar.
> [WARNING] Could not get sources for javax.jnlp:jnlp-api:jar:1.7.0_06:compile
> {code}
> and in turn:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on project
> x: Execution default of goal
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade failed.
> NullPointerException -> [Help 1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MSHADE-247) NullpointerException when createSourcesJar = true and source jar cannot be found
[
https://issues.apache.org/jira/browse/MSHADE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033684#comment-16033684
]
Hudson commented on MSHADE-247:
---
SUCCESS: Integrated in Jenkins build maven-plugins #8980 (See
[https://builds.apache.org/job/maven-plugins/8980/])
[MSHADE-247] NullpointerException when createSourcesJar = true and source jar
cannot be found
Submitted by: Anders Smestad
Applied after adding an IT. (gboue:
[http://svn.apache.org/viewvc/?view=rev&rev=1797263])
* (add) maven-shade-plugin/src/it/MSHADE-247
* (add) maven-shade-plugin/src/it/MSHADE-247/pom.xml
* (add) maven-shade-plugin/src/it/MSHADE-247/repo
* (add) maven-shade-plugin/src/it/MSHADE-247/repo/org
* (add) maven-shade-plugin/src/it/MSHADE-247/repo/org/apache
* (add) maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven
* (add) maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its
* (add) maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade
* (add) maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj
* (add)
maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj/mshade-247-one
* (add)
maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj/mshade-247-one/0.1
* (add)
maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj/mshade-247-one/0.1/mshade-247-one-0.1-sources.jar
* (add)
maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj/mshade-247-one/0.1/mshade-247-one-0.1.jar
* (add)
maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj/mshade-247-one/0.1/mshade-247-one-0.1.pom
* (add)
maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj/mshade-247-two
* (add)
maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj/mshade-247-two/0.1
* (add)
maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj/mshade-247-two/0.1/mshade-247-two-0.1.jar
* (add)
maven-shade-plugin/src/it/MSHADE-247/repo/org/apache/maven/its/shade/csj/mshade-247-two/0.1/mshade-247-two-0.1.pom
* (edit)
maven-shade-plugin/src/main/java/org/apache/maven/plugins/shade/mojo/ShadeMojo.java
> NullpointerException when createSourcesJar = true and source jar cannot be
> found
> -
>
> Key: MSHADE-247
> URL: https://issues.apache.org/jira/browse/MSHADE-247
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Sodasmile
>Priority: Critical
> Attachments:
> Resolving_nullpointer_exception_when_resolvedArtifact_is_null_.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Configuration as follows:
> {code}
>
> org.apache.maven.plugins
> maven-shade-plugin
>
> true
>
>
>
> package
>
> shade
>
>
>
>
> {code}
> Dependency defined as follows:
> {code}
>
> javax.jnlp
> jnlp-api
> 1.7.0_06
>
> {code}
> Sources for javax.jnlp for some reason disappeared from our maven repo proxy,
> which made maven-shade-plugin to output:
> {code}
> [INFO] Including javax.jnlp:jnlp-api:jar:1.7.0_06 in the shaded jar.
> [WARNING] Could not get sources for javax.jnlp:jnlp-api:jar:1.7.0_06:compile
> {code}
> and in turn:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on project
> x: Execution default of goal
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade failed.
> NullPointerException -> [Help 1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MDEP-420) The dependency:get goal does not download the associate pom, or provide an option to do that
[ https://issues.apache.org/jira/browse/MDEP-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Boué closed MDEP-420. --- Resolution: Fixed Fix Version/s: 3.0.1 > The dependency:get goal does not download the associate pom, or provide an > option to do that > > > Key: MDEP-420 > URL: https://issues.apache.org/jira/browse/MDEP-420 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: get >Affects Versions: 2.8 >Reporter: Martin Todorov > Fix For: 3.0.1 > > > The dependency:get goal does not download the associate .pom, or provide an > option to do that. Instead one needs to do a second invocation in order to > resolve the pom. It would be great if you could add this feature. > Much appreciated! :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MSHADE-247) NullpointerException when createSourcesJar = true and source jar cannot be found
[
https://issues.apache.org/jira/browse/MSHADE-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033661#comment-16033661
]
Guillaume Boué commented on MSHADE-247:
---
Fixed in [r1797263|http://svn.apache.org/viewvc?rev=1797263&view=rev].
> NullpointerException when createSourcesJar = true and source jar cannot be
> found
> -
>
> Key: MSHADE-247
> URL: https://issues.apache.org/jira/browse/MSHADE-247
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Sodasmile
>Priority: Critical
> Attachments:
> Resolving_nullpointer_exception_when_resolvedArtifact_is_null_.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Configuration as follows:
> {code}
>
> org.apache.maven.plugins
> maven-shade-plugin
>
> true
>
>
>
> package
>
> shade
>
>
>
>
> {code}
> Dependency defined as follows:
> {code}
>
> javax.jnlp
> jnlp-api
> 1.7.0_06
>
> {code}
> Sources for javax.jnlp for some reason disappeared from our maven repo proxy,
> which made maven-shade-plugin to output:
> {code}
> [INFO] Including javax.jnlp:jnlp-api:jar:1.7.0_06 in the shaded jar.
> [WARNING] Could not get sources for javax.jnlp:jnlp-api:jar:1.7.0_06:compile
> {code}
> and in turn:
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade (default) on project
> x: Execution default of goal
> org.apache.maven.plugins:maven-shade-plugin:3.0.0:shade failed.
> NullPointerException -> [Help 1]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MDEP-560) maven-dependency-plugin ignores method references passed as parameter
[
https://issues.apache.org/jira/browse/MDEP-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033544#comment-16033544
]
Robert Gettys edited comment on MDEP-560 at 6/1/17 7:37 PM:
I believe I'm having a similar issue. The docs say that the plugin depends on
the bytecode generated by the test-compile phase.
I checked the bytecode generated, and my test class' bytecode directly
references my DAO class, which directly references the datastax class from the
library but, after running "mvn clean dependency:analyze", I see the following:
{noformat}
[WARNING] Unused declared dependencies found:
...
[WARNING]com.datastax.cassandra:cassandra-driver-core:jar:3.1.2:compile
...
{noformat}
was (Author: rgettys):
I believe I'm having a similar issue. The docs say that the plugin depends on
the bytecode generated by the test-compile phase.
I checked the bytecode generated, and my test class' bytecode directly
references my DAO class, which directly references the datastax class from the
library but, after running "mvn clean dependency:analyze", I see the following:
[WARNING] Unused declared dependencies found:
...
[WARNING]com.datastax.cassandra:cassandra-driver-core:jar:3.1.2:compile
...
> maven-dependency-plugin ignores method references passed as parameter
> -
>
> Key: MDEP-560
> URL: https://issues.apache.org/jira/browse/MDEP-560
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Vladimir Dergachev
>Priority: Minor
>
> I created example for commons-lang library
> https://gist.github.com/vdergachev/3dd0908ec0301b1e0357005e669cc726
> My applications contains few modules, in parent pom.xml i have regular entry
> {code}
>
> 1.8
> ...
>
>
>
>
>
> commons-lang
> commons-lang
> 2.6
>
> ...
>
>
> {code}
> in module's pom ONLY spring deps, so i don't have commons-lang library in
> module dependencies, but test runs fine. As you can see I passed reference
> StringUtils::isEmpty as a parameter to method. When part 2 uncommented and
> method StringUtils.isEmpty called directly in code i will have correct error
> message from maven-dependency-plugin
> {code}
> [INFO] — maven-dependency-plugin:3.0.0:analyze-only (analyze-dependencies)
> [WARNING] Used undeclared dependencies found:
> [WARNING] commons-lang:commons-lang:jar:2.6:compile
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MDEP-560) maven-dependency-plugin ignores method references passed as parameter
[
https://issues.apache.org/jira/browse/MDEP-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033544#comment-16033544
]
Robert Gettys edited comment on MDEP-560 at 6/1/17 7:36 PM:
I believe I'm having a similar issue. The docs say that the plugin depends on
the bytecode generated by the test-compile phase.
I checked the bytecode generated, and my test class' bytecode directly
references my DAO class, which directly references the datastax class from the
library but, after running "mvn clean dependency:analyze", I see the following:
[WARNING] Unused declared dependencies found:
...
[WARNING]com.datastax.cassandra:cassandra-driver-core:jar:3.1.2:compile
...
was (Author: rgettys):
I believe I'm having a similar issue. The docs say that the plugin depends on
the bytecode generated by the test-compile phase.
I checked the bytecode generated, and my test class' bytecode directly
references my DAO class, which directly references the datastax class from the
library but, after running ``mvn clean dependency:analyze``, I see the
following:
```
[WARNING] Unused declared dependencies found:
...
[WARNING]com.datastax.cassandra:cassandra-driver-core:jar:3.1.2:compile
...
```
> maven-dependency-plugin ignores method references passed as parameter
> -
>
> Key: MDEP-560
> URL: https://issues.apache.org/jira/browse/MDEP-560
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Vladimir Dergachev
>Priority: Minor
>
> I created example for commons-lang library
> https://gist.github.com/vdergachev/3dd0908ec0301b1e0357005e669cc726
> My applications contains few modules, in parent pom.xml i have regular entry
> {code}
>
> 1.8
> ...
>
>
>
>
>
> commons-lang
> commons-lang
> 2.6
>
> ...
>
>
> {code}
> in module's pom ONLY spring deps, so i don't have commons-lang library in
> module dependencies, but test runs fine. As you can see I passed reference
> StringUtils::isEmpty as a parameter to method. When part 2 uncommented and
> method StringUtils.isEmpty called directly in code i will have correct error
> message from maven-dependency-plugin
> {code}
> [INFO] — maven-dependency-plugin:3.0.0:analyze-only (analyze-dependencies)
> [WARNING] Used undeclared dependencies found:
> [WARNING] commons-lang:commons-lang:jar:2.6:compile
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-560) maven-dependency-plugin ignores method references passed as parameter
[
https://issues.apache.org/jira/browse/MDEP-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033544#comment-16033544
]
Robert Gettys commented on MDEP-560:
I believe I'm having a similar issue. The docs say that the plugin depends on
the bytecode generated by the test-compile phase.
I checked the bytecode generated, and my test class' bytecode directly
references my DAO class, which directly references the datastax class from the
library but, after running ``mvn clean dependency:analyze``, I see the
following:
```
[WARNING] Unused declared dependencies found:
...
[WARNING]com.datastax.cassandra:cassandra-driver-core:jar:3.1.2:compile
...
```
> maven-dependency-plugin ignores method references passed as parameter
> -
>
> Key: MDEP-560
> URL: https://issues.apache.org/jira/browse/MDEP-560
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Vladimir Dergachev
>Priority: Minor
>
> I created example for commons-lang library
> https://gist.github.com/vdergachev/3dd0908ec0301b1e0357005e669cc726
> My applications contains few modules, in parent pom.xml i have regular entry
> {code}
>
> 1.8
> ...
>
>
>
>
>
> commons-lang
> commons-lang
> 2.6
>
> ...
>
>
> {code}
> in module's pom ONLY spring deps, so i don't have commons-lang library in
> module dependencies, but test runs fine. As you can see I passed reference
> StringUtils::isEmpty as a parameter to method. When part 2 uncommented and
> method StringUtils.isEmpty called directly in code i will have correct error
> message from maven-dependency-plugin
> {code}
> [INFO] — maven-dependency-plugin:3.0.0:analyze-only (analyze-dependencies)
> [WARNING] Used undeclared dependencies found:
> [WARNING] commons-lang:commons-lang:jar:2.6:compile
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MCHECKSTYLE-337) checkstyle:check only supports xml output format, but the docs say it supports plain as well
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stig Rohde Døssing updated MCHECKSTYLE-337: --- Attachment: MCHECKSTYLE-337.patch Figured it out :) > checkstyle:check only supports xml output format, but the docs say it > supports plain as well > > > Key: MCHECKSTYLE-337 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-337 > Project: Maven Checkstyle Plugin > Issue Type: Bug > Components: checkstyle:check >Affects Versions: 2.17 >Reporter: Stig Rohde Døssing >Priority: Minor > Attachments: MCHECKSTYLE-337.patch > > > The documentation for the check goal at > https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#outputFileFormat > mentions "plain" as a valid option for file output. This is not true, the > mojo only supports XML. > I'd prefer added support for plain output, but the docs should be fixed if > that is not possible. > Taking a look at the code, it looks like the only reason plain isn't > supported is because the check mojo needs to parse the output file to figure > out if there were style violations. An option would be counting errors with > the AuditListener instead, but this would break support for skipExec. An > alternative would be to output an extra XML result file if the output format > isn't XML. > I'd be happy to implement either solution. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MCHECKSTYLE-337) checkstyle:check only supports xml output format, but the docs say it supports plain as well
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033529#comment-16033529
]
Stig Rohde Døssing commented on MCHECKSTYLE-337:
I have a solution working where an extra XML file is generated in the tmpdir if
the outputFileFormat isn't {{xml}}. How do I put it up for review? (I'm more
familiar with git where this would be done via PR)
> checkstyle:check only supports xml output format, but the docs say it
> supports plain as well
>
>
> Key: MCHECKSTYLE-337
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-337
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Affects Versions: 2.17
>Reporter: Stig Rohde Døssing
>Priority: Minor
>
> The documentation for the check goal at
> https://maven.apache.org/plugins/maven-checkstyle-plugin/check-mojo.html#outputFileFormat
> mentions "plain" as a valid option for file output. This is not true, the
> mojo only supports XML.
> I'd prefer added support for plain output, but the docs should be fixed if
> that is not possible.
> Taking a look at the code, it looks like the only reason plain isn't
> supported is because the check mojo needs to parse the output file to figure
> out if there were style violations. An option would be counting errors with
> the AuditListener instead, but this would break support for skipExec. An
> alternative would be to output an extra XML result file if the output format
> isn't XML.
> I'd be happy to implement either solution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-569) copy fails on artifacts previously downloaded via get from repo specified via CLI
[
https://issues.apache.org/jira/browse/MDEP-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16033422#comment-16033422
]
Guillaume Boué commented on MDEP-569:
-
[{{dependency:get}}|https://maven.apache.org/plugins/maven-dependency-plugin/get-mojo.html]
currently has a restriction that it will always check the central repository,
before the repositories configured in {{remoteRepositories}}. Since the
artifact {{io.confluent:kafka-schema-registry:3.1.1}} does not exist on
Central, and exists in the given remote repository, Maven will create a
{{.lastUpdated}} storing this information.
When {{dependency:copy}} is ran, Maven will try to work on the artifact
{{io.confluent:kafka-schema-registry:3.1.1}} but, at that moment, the active
remote repository is only Maven Central. Since the download from Central failed
before, Maven also fails, and says it will try to resolve it from central if
forced or the update interval has passed. This change was introduced in Maven
3, see MNG-5181 for more info.
So a possible work-around is to work on a project where the
{{http://packages.confluent.io/maven/}} repository is active, or add this
repository to your settings. After that, the command {{mvn
org.apache.maven.plugins:maven-dependency-plugin:3.0.1:get
org.apache.maven.plugins:maven-dependency-plugin:3.0.1:copy
-Dartifact=io.confluent:kafka-schema-registry:3.1.1}} will work fine (because
Maven detects that the artifact {{io.confluent:kafka-schema-registry:3.1.1}}
was downloaded from the Confluent repo, and this is an active repository for
the build).
> copy fails on artifacts previously downloaded via get from repo specified via
> CLI
> -
>
> Key: MDEP-569
> URL: https://issues.apache.org/jira/browse/MDEP-569
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: copy, get
>Affects Versions: 3.0.1
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
> Maven home: /usr/share/maven
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8-openjdk/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.8.0-52-generic", arch: "amd64", family: "unix"
>Reporter: Tom Wieczorek
> Attachments: dependency-copy-problem-output.txt
>
>
> {{dependency:copy}} fails to copy artifacts that were previously downloaded
> via {{dependency:get}} from a remote repository that has been specified on
> the command line. The error message is:
> bq. The POM for artifact is missing, no dependency information available
> and later on
> bq. Failed to execute goal dependency:copy (default-cli) on project
> standalone-pom: Unable to find/resolve artifact. Failure to find artifact in
> https://repo.maven.apache.org/maven2 was cached in the local repository,
> resolution will not be reattempted until the update interval of central has
> elapsed or updates are forced
> But: {{dependency:get}} actually succeeded and the artifact and its POM are
> in the local repo.
> {code:none|title=Reproducing shell snippet}
> mvn -version
> mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:get \
> org.apache.maven.plugins:maven-dependency-plugin:3.0.1:copy \
> -DremoteRepositories=http://packages.confluent.io/maven/ \
> -Dartifact=io.confluent:kafka-schema-registry:3.1.1
> ls -la ~/.m2/repository/io/confluent/kafka-schema-registry/3.1.1
> {code}
> I've attached the output of the above test snippets.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-420) The dependency:get goal does not download the associate pom, or provide an option to do that
[
https://issues.apache.org/jira/browse/MDEP-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1609#comment-1609
]
Guillaume Boué commented on MDEP-420:
-
I cannot reproduce this issue anymore with version 3.0.1 of the plugin. The
behaviour is correct with and without transitivite dependencies disabled. This
was probably fixed along with MDEP-548.
{noformat}
$ mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:get
-Dartifact=asm:asm-analysis:3.2 -Dtransitive=false
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Maven Stub Project (No POM) 1
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:3.0.1:get (default-cli) @ standalone-pom ---
[INFO] Resolving asm:asm-analysis:jar:3.2
Downloading:
https://repo.maven.apache.org/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.pom
Downloaded:
https://repo.maven.apache.org/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.pom
(417 B at 1.0 kB/s)
Downloading:
https://repo.maven.apache.org/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.jar
Downloaded:
https://repo.maven.apache.org/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.jar
(18 kB at 200 kB/s)
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 2.615 s
[INFO] Finished at: 2017-06-01T19:21:49+02:00
[INFO] Final Memory: 17M/198M
[INFO]
{noformat}
> The dependency:get goal does not download the associate pom, or provide an
> option to do that
>
>
> Key: MDEP-420
> URL: https://issues.apache.org/jira/browse/MDEP-420
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: get
>Affects Versions: 2.8
>Reporter: Martin Todorov
>
> The dependency:get goal does not download the associate .pom, or provide an
> option to do that. Instead one needs to do a second invocation in order to
> resolve the pom. It would be great if you could add this feature.
> Much appreciated! :)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MASSEMBLY-856) Ability to overwrite existing files
Kamal Mettananda created MASSEMBLY-856:
--
Summary: Ability to overwrite existing files
Key: MASSEMBLY-856
URL: https://issues.apache.org/jira/browse/MASSEMBLY-856
Project: Maven Assembly Plugin
Issue Type: Improvement
Affects Versions: 3.0.0, 2.5.4, 2.2-beta-5
Reporter: Kamal Mettananda
This is a request to add element to in assembly file.
Currently, it is not possible to overwrite the already existing files inside
the expected archive with new files.
e.g.:
Expectation of below assembly file is to have the conf.properties file in dir2
after the zip file is generated.
{code:xml}
dist
zip
false
dir1
release
dir2
release
true
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MASSEMBLY-855) Remote repositories ignores in a multi-module project
John Farrelly created MASSEMBLY-855:
---
Summary: Remote repositories ignores in a multi-module project
Key: MASSEMBLY-855
URL: https://issues.apache.org/jira/browse/MASSEMBLY-855
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 3.0.0
Reporter: John Farrelly
Attachments: test-parent.tar.gz
I have attached a small multi-module project to demonstrate the behaviour.
I have a {{test-parent}} project with a child module, {{test-child}}.
I have defined a repositories section in {{test-parent}}:
{code:xml}
jboss-public-repository-group
JBoss Public Maven Repository Group
https://repository.jboss.org/nexus/content/groups/public-jboss/
default
true
never
true
never
{code}
I have defined the executing of {{maven-assembly-plugin}} in
{{test-child/pom.xml}}:
{code:xml}
maven-assembly-plugin
3.0.0
src/assembly/repository.xml
create-repository
package
single
{code}
When I run {{mvn clean package}} from {{test-child}}, I can see that it is
using {{repository.jboss.org}} to resolve dependencies:
{noformat}
[test-parent/test-child] $ mvn clean package
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building test-child 1.0.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-child ---
[INFO]
[INFO] --- maven-assembly-plugin:3.0.0:single (create-repository) @ test-child
---
[INFO] Reading assembly descriptor: src/assembly/repository.xml
Downloading:
https://repository.jboss.org/nexus/content/groups/public-jboss/org/jboss/spec/javax/servlet/jboss-servlet-api_3.0_spec/1.0.0.Beta2/jboss-servlet-api_3.0_spec-1.0.0.Beta2.pom
{noformat}
However, if I run {{mvn clean package}} from the parent project
{{test-parent}}, it will only try to resolve dependencies from maven central,
ignoring all repository settings:
{noformat}
[test-parent] $ mvn clean package
[INFO] Scanning for projects...
[INFO]
[INFO] Reactor Build Order:
[INFO]
[INFO] test-parent
[INFO] test-child
[INFO]
[INFO]
[INFO] Building test-parent 1.0.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-parent ---
[INFO]
[INFO]
[INFO] Building test-child 1.0.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-child ---
[INFO] Deleting /media/sf_SharedFolder/Temp/test-parent/test-child/target
[INFO]
[INFO] --- maven-assembly-plugin:3.0.0:single (create-repository) @ test-child
---
[INFO] Reading assembly descriptor: src/assembly/repository.xml
Downloading:
https://repo.maven.apache.org/maven2/org/jboss/spec/javax/servlet/jboss-servlet-api_3.0_spec/1.0.0.Beta2/jboss-servlet-api_3.0_spec-1.0.0.Beta2.pom
{noformat}
This causes issues for us when we reference dependencies that don't exist in
maven central.
{panel:title=Note|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
I am using maven version 3.3.3
{panel}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MASSEMBLY-855) Remote repositories ignored in a multi-module project
[
https://issues.apache.org/jira/browse/MASSEMBLY-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Farrelly updated MASSEMBLY-855:
Summary: Remote repositories ignored in a multi-module project (was:
Remote repositories ignores in a multi-module project)
> Remote repositories ignored in a multi-module project
> -
>
> Key: MASSEMBLY-855
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-855
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 3.0.0
>Reporter: John Farrelly
> Attachments: test-parent.tar.gz
>
>
> I have attached a small multi-module project to demonstrate the behaviour.
> I have a {{test-parent}} project with a child module, {{test-child}}.
> I have defined a repositories section in {{test-parent}}:
> {code:xml}
>
>
> jboss-public-repository-group
> JBoss Public Maven Repository Group
>
> https://repository.jboss.org/nexus/content/groups/public-jboss/
> default
>
> true
> never
>
>
> true
> never
>
>
>
> {code}
> I have defined the executing of {{maven-assembly-plugin}} in
> {{test-child/pom.xml}}:
> {code:xml}
>
> maven-assembly-plugin
> 3.0.0
>
>
> src/assembly/repository.xml
>
>
>
>
> create-repository
> package
>
> single
>
>
>
>
> {code}
> When I run {{mvn clean package}} from {{test-child}}, I can see that it is
> using {{repository.jboss.org}} to resolve dependencies:
> {noformat}
> [test-parent/test-child] $ mvn clean package
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building test-child 1.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-child ---
> [INFO]
> [INFO] --- maven-assembly-plugin:3.0.0:single (create-repository) @
> test-child ---
> [INFO] Reading assembly descriptor: src/assembly/repository.xml
> Downloading:
> https://repository.jboss.org/nexus/content/groups/public-jboss/org/jboss/spec/javax/servlet/jboss-servlet-api_3.0_spec/1.0.0.Beta2/jboss-servlet-api_3.0_spec-1.0.0.Beta2.pom
> {noformat}
> However, if I run {{mvn clean package}} from the parent project
> {{test-parent}}, it will only try to resolve dependencies from maven central,
> ignoring all repository settings:
> {noformat}
> [test-parent] $ mvn clean package
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] test-parent
> [INFO] test-child
> [INFO]
>
> [INFO]
>
> [INFO] Building test-parent 1.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-parent ---
> [INFO]
>
> [INFO]
>
> [INFO] Building test-child 1.0.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ test-child ---
> [INFO] Deleting /media/sf_SharedFolder/Temp/test-parent/test-child/target
> [INFO]
> [INFO] --- maven-assembly-plugin:3.0.0:single (create-repository) @
> test-child ---
> [INFO] Reading assembly descriptor: src/assembly/repository.xml
> Downloading:
> https://repo.maven.apache.org/maven2/org/jboss/spec/javax/servlet/jboss-servlet-api_3.0_spec/1.0.0.Beta2/jboss-servlet-api_3.0_spec-1.0.0.Beta2.pom
> {noformat}
> This causes issues for us when we reference dependencies that don't exist in
> maven central.
> {panel:title=Note|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> I am using maven version 3.3.3
> {panel}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1378) Nice to have systemPropertiesFile configurable by user property
[
https://issues.apache.org/jira/browse/SUREFIRE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032703#comment-16032703
]
Michal Domagala commented on SUREFIRE-1378:
---
SUREFIRE-1365 is similar but different. My issue refers to Java system
property, SUREFIRE-1365 to OS environment variable.
I'm new to Java interface in pom.xml. If you give me a link to piece of
documentation I will check if this will solve my problem.
(But my commit solves the problem here and now)
> Nice to have systemPropertiesFile configurable by user property
> ---
>
> Key: SUREFIRE-1378
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1378
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Michal Domagala
>Priority: Minor
>
> I would like to have option to configure my tests with property files. But
> property file is not required, because in 95% my tests work fine with default
> configuration.
> I used the following workaround: I configured failsafe plugin in the
> following way
> {code:xml}
>
>
>
> (...)
> maven-failsafe-plugin
> (...)
> ${my.test.props.file}
> {code}
> In 95% I call *mvn verify*, systemPropertiesFile is not found and ignored
> -all pass
> In 5% I call *mvn verify -Dmy.test.props.file=x.props*
> The problem is in 95% I get warning about missing files. Also configuration
> is unnecessary complicated
> I would like drop whole connfiguration from pom.xml and use:
> In 95% *mvn verify*
> In 5% *mvn verify -Dfailsafe.systemPropertiesFile=x.props*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1302) Surefire does not wait long enough for the forked VM and assumes it to be dead
[
https://issues.apache.org/jira/browse/SUREFIRE-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032589#comment-16032589
]
Emmanuel Lecharny commented on SUREFIRE-1302:
-
Same pb with 2.19.1.
All the tests went through without error :
{noformat}
[INFO] Results :
[INFO]
[INFO] Tests run: 50, Failures: 0, Errors: 0, Skipped: 0
[INFO]
{noformat}
Same thing in the surefire-reports.
> Surefire does not wait long enough for the forked VM and assumes it to be dead
> --
>
> Key: SUREFIRE-1302
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1302
> Project: Maven Surefire
> Issue Type: Request
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Yuriy Zaplavnov
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: 2017-05-18T05-48-08_685-jvmRun1.dumpstream,
> surefire-gclog.log, surefire-logs,
> surefire-tests-terminated-master-aa9330316038f6b46316ce36ff40714ffc7cf299.zip,
> tests_log_01.txt, tests_log_02.txt
>
>
> This issue happens because surefire kills the forked container if it times
> out waiting for the 'ping'.
> In org.apache.maven.surefire.booter.ForkedBooter class there is hardcoded
> constant PING_TIMEOUT_IN_SECONDS = 20 which is used in the following method:
> {code}
> private static ScheduledFuture listenToShutdownCommands( CommandReader
> reader )
> {
> reader.addShutdownListener( createExitHandler( reader ) );
> AtomicBoolean pingDone = new AtomicBoolean( true );
> reader.addNoopListener( createPingHandler( pingDone ) );
> return JVM_TERMINATOR.scheduleAtFixedRate( createPingJob( pingDone,
> reader ),
>0,PING_TIMEOUT_IN_SECONDS,
> SECONDS );
> }
> {code}
> to create ScheduledFuture.
> In some of the cases the forked container might respond a bit later than it's
> expected and surefire kills it
> {code}
> private static Runnable createPingJob( final AtomicBoolean pingDone, final
> CommandReader reader )
> {
> return new Runnable()
> {
> public void run()
> {
> boolean hasPing = pingDone.getAndSet( false );
> if ( !hasPing )
> {
> exit( 1, KILL, reader, true );
> }
> }
> };
> }
> {code}
> As long as we need to terminate it anyway, It would be really helpful if the
> problem could be solved making the PING_TIMEOUT_IN_SECONDS configurable with
> the ability to specify the value from maven-surefire-plugin.
> It would help to configure this timeout based on needs and factors of the
> projects where surefire runs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MDEP-569) copy fails on artifacts previously downloaded via get from repo specified via CLI
Tom Wieczorek created MDEP-569:
--
Summary: copy fails on artifacts previously downloaded via get
from repo specified via CLI
Key: MDEP-569
URL: https://issues.apache.org/jira/browse/MDEP-569
Project: Maven Dependency Plugin
Issue Type: Bug
Components: copy, get
Affects Versions: 3.0.1
Environment: Apache Maven 3.5.0
(ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T19:39:06Z)
Maven home: /usr/share/maven
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8-openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.8.0-52-generic", arch: "amd64", family: "unix"
Reporter: Tom Wieczorek
Attachments: dependency-copy-problem-output.txt
{{dependency:copy}} fails to copy artifacts that were previously downloaded via
{{dependency:get}} from a remote repository that has been specified on the
command line. The error message is:
bq. The POM for artifact is missing, no dependency information available
and later on
bq. Failed to execute goal dependency:copy (default-cli) on project
standalone-pom: Unable to find/resolve artifact. Failure to find artifact in
https://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced
But: {{dependency:get}} actually succeeded and the artifact and its POM are in
the local repo.
{code:none|title=Reproducing shell snippet}
mvn -version
mvn org.apache.maven.plugins:maven-dependency-plugin:3.0.1:get \
org.apache.maven.plugins:maven-dependency-plugin:3.0.1:copy \
-DremoteRepositories=http://packages.confluent.io/maven/ \
-Dartifact=io.confluent:kafka-schema-registry:3.1.1
ls -la ~/.m2/repository/io/confluent/kafka-schema-registry/3.1.1
{code}
I've attached the output of the above test snippets.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (SUREFIRE-1378) Nice to have systemPropertiesFile configurable by user property
[
https://issues.apache.org/jira/browse/SUREFIRE-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032570#comment-16032570
]
ASF GitHub Bot commented on SUREFIRE-1378:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/152
@michaldo
Version 3.0 will have configurable via Java interface in pom.xml.
This way you can turn the behavior to file system.
Please check Jira [1] with version 3.0. Maybe we already have this request.
[1]: https://issues.apache.org/jira/browse/SUREFIRE
> Nice to have systemPropertiesFile configurable by user property
> ---
>
> Key: SUREFIRE-1378
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1378
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Michal Domagala
>Priority: Minor
>
> I would like to have option to configure my tests with property files. But
> property file is not required, because in 95% my tests work fine with default
> configuration.
> I used the following workaround: I configured failsafe plugin in the
> following way
> {code:xml}
>
>
>
> (...)
> maven-failsafe-plugin
> (...)
> ${my.test.props.file}
> {code}
> In 95% I call *mvn verify*, systemPropertiesFile is not found and ignored
> -all pass
> In 5% I call *mvn verify -Dmy.test.props.file=x.props*
> The problem is in 95% I get warning about missing files. Also configuration
> is unnecessary complicated
> I would like drop whole connfiguration from pom.xml and use:
> In 95% *mvn verify*
> In 5% *mvn verify -Dfailsafe.systemPropertiesFile=x.props*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MDEP-420) The dependency:get goal does not download the associate pom, or provide an option to do that
[
https://issues.apache.org/jira/browse/MDEP-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032560#comment-16032560
]
Tom Wieczorek commented on MDEP-420:
It's actually happening if you disable transitive dependency download:
{noformat}
$ mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get
-Dartifact=asm:asm-analysis:3.2 -Dtransitive=false
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Maven Stub Project (No POM) 1
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.8:get (default-cli) @ standalone-pom ---
[INFO] Resolving asm:asm-analysis:jar:3.2
Downloading:
https://repo.maven.apache.org/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.jar
Downloaded:
https://repo.maven.apache.org/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.jar
(18 kB at 38 kB/s)
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.940 s
[INFO] Finished at: 2017-06-01T07:04:04Z
[INFO] Final Memory: 15M/249M
[INFO]
$ ls -la ~/.m2/repository/asm/asm-analysis/3.2/
total 36
drwxr-xr-x2 towi towi 4096 Jun 1 07:04 .
drwxr-xr-x3 towi towi 4096 Jun 1 07:04 ..
-rw-r--r--1 towi towi 163 Jun 1 07:04 _remote.repositories
-rw-r--r--1 towi towi 17985 Jun 1 07:04 asm-analysis-3.2.jar
-rw-r--r--1 towi towi40 Jun 1 07:04
asm-analysis-3.2.jar.sha1
$
{noformat}
> The dependency:get goal does not download the associate pom, or provide an
> option to do that
>
>
> Key: MDEP-420
> URL: https://issues.apache.org/jira/browse/MDEP-420
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: get
>Affects Versions: 2.8
>Reporter: Martin Todorov
>
> The dependency:get goal does not download the associate .pom, or provide an
> option to do that. Instead one needs to do a second invocation in order to
> resolve the pom. It would be great if you could add this feature.
> Much appreciated! :)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
