[jira] [Created] (MNG-6235) Properties from .mvn/maven.config cannot be overwritten from command line
Mariusz Smykuła created MNG-6235:
Summary: Properties from .mvn/maven.config cannot be overwritten
from command line
Key: MNG-6235
URL: https://issues.apache.org/jira/browse/MNG-6235
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 3.5.0
Reporter: Mariusz Smykuła
Whole procedure is described in blog post:
http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/
I have setted version in {{.mvn/maven.config}}
{code}
-Drevision=1.0.0-SNAPSHOT
{code}
and when invoking build with command:
{{mvn clean package -Drevision=2.0.0-SNAPSHOT}}
version is still 1.0.0-SNAPSHOT, should be 2.0.0-SNAPSHOT.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-6235) Properties from .mvn/maven.config cannot be overwritten from command line
[
https://issues.apache.org/jira/browse/MNG-6235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015349#comment-16015349
]
Mariusz Smykuła commented on MNG-6235:
--
Ok, this bug is related to maven wrapper, from standalone maven this works
> Properties from .mvn/maven.config cannot be overwritten from command line
> -
>
> Key: MNG-6235
> URL: https://issues.apache.org/jira/browse/MNG-6235
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
>Reporter: Mariusz Smykuła
>
> Whole procedure is described in blog post:
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/
> I have setted version in {{.mvn/maven.config}}
> {code}
> -Drevision=1.0.0-SNAPSHOT
> {code}
> and when invoking build with command:
> {{mvn clean package -Drevision=2.0.0-SNAPSHOT}}
> version is still 1.0.0-SNAPSHOT, should be 2.0.0-SNAPSHOT.
--
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=16015374#comment-16015374
]
Olivier Peyrusse commented on SUREFIRE-1302:
Hello Tibor,
I did not manage to reproduce the issue on my machine. I am trying on a bigger
one.
> 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:
> 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] (MNG-5728) Switch the default checksum policy from "warn" to "fail"
[ https://issues.apache.org/jira/browse/MNG-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015428#comment-16015428 ] Michael Benz commented on MNG-5728: --- In a larger Maven project with external repositories we had quite a few occurrences with corrupt downloaded jars. After finding out the default policy on checksums I also try to use the -C option. > Switch the default checksum policy from "warn" to "fail" > > > Key: MNG-5728 > URL: https://issues.apache.org/jira/browse/MNG-5728 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Nicolas Juneau >Priority: Minor > Fix For: Issues to be reviewed for 4.x > > > The default checksum policy when obtaining artifacts during a build is > currently, by default, "warn". This seems a bit odd for me since a checksum > is usually used to prevent the use of corrupted data. > Since Maven produces a lot of output (and some IDEs sometimes hide it), it is > easy to miss a bad checksum warning. I am aware that there is a > checksumPolicy setting in Maven, but, unless I am mistaken, it cannot be > defined for all repositories at once. It has to be done either on a > per-repository basis or by using the "strict-checksum" flag in the command > line. > After searching around a bit on the Web and with the help of a coworker, we > discovered that the default "warn" setting was mainly there because some > repositories were not handling checksums quite well. Issue MNG-339 contains > some information about this. > My colleague also chatted briefly with "trygvis" on IRC. Apparently, the > default "warn" setting is really there for historical reasons. > I believe that a default value of "fail" would greatly reduce the likelihood > of errors and also slightly increase the security of Maven. Corrupted > artifacts should not, by default, be used for builds. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEP-562) Make extended tokens default for displaying trees
[ https://issues.apache.org/jira/browse/MDEP-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015476#comment-16015476 ] Keir commented on MDEP-562: --- Ok so what is the next step to implement this? Should I prepare a pull request doing the locale detection in line with tree? > Make extended tokens default for displaying trees > - > > Key: MDEP-562 > URL: https://issues.apache.org/jira/browse/MDEP-562 > Project: Maven Dependency Plugin > Issue Type: Wish > Components: tree >Affects Versions: 3.0.0 >Reporter: Keir > > Now that MSHARED-615 has been merged I would like to propose that this be > made the default behavior. By this point most developers have > unicode-compatible terminals and given the extended characters make the tree > more readable it would be nice to have this as the default option. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MNG-6236) maven-metadata-local.xml polluted with whitespaces
Tomer Cohen created MNG-6236: Summary: maven-metadata-local.xml polluted with whitespaces Key: MNG-6236 URL: https://issues.apache.org/jira/browse/MNG-6236 Project: Maven Issue Type: Bug Affects Versions: 3.5.0 Reporter: Tomer Cohen Attachments: stacktrace.txt After starting to use Maven 3.5.0 multiple instances of the attached exceptions started occurring when multiple builds are using and installing modules of the same reactor. I sanitized the module name. Maven 3.3.9 did not have this issue -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (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:all-tabpanel
]
Olivier Peyrusse updated SUREFIRE-1302:
---
Attachment: surefire-logs
2017-05-18T05-48-08_685-jvmRun1.dumpstream
> 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-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-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=16015668#comment-16015668
]
Olivier Peyrusse commented on SUREFIRE-1302:
Hello Tibor,
running surefire 2.21-SNAPSHOT, I got once again the VM shutdown. I attached to
the issue the maven logs. My personal logs seems to show that a small thread
supposed to print a message every 250 ms was not scheduled during 12s.
GC logs available as error in jvmRun1 show that a pause of ~12s, confirming my
diagnostic.
{quote}
# Created on 2017-05-18T05:50:30.395
Corrupted stdin stream in forked JVM 1. Stream '[GC pause (G1 Evacuation Pause)
(young)-- 888M->820M(1024M), 11.8820911 secs]'.
{quote}
So the current adaptive ping seems not to be enough. Tell me if you want me to
test something else.
Best regards
> 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-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] [Assigned] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko reassigned MNG-6233: --- Assignee: Igor Fedorenko > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1-candidate > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MNG-6235) Properties from .mvn/maven.config cannot be overwritten from command line
[
https://issues.apache.org/jira/browse/MNG-6235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015992#comment-16015992
]
Mariusz Smykuła commented on MNG-6235:
--
please close, I have old maven wrapper
> Properties from .mvn/maven.config cannot be overwritten from command line
> -
>
> Key: MNG-6235
> URL: https://issues.apache.org/jira/browse/MNG-6235
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
>Reporter: Mariusz Smykuła
>
> Whole procedure is described in blog post:
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/
> I have setted version in {{.mvn/maven.config}}
> {code}
> -Drevision=1.0.0-SNAPSHOT
> {code}
> and when invoking build with command:
> {{mvn clean package -Drevision=2.0.0-SNAPSHOT}}
> version is still 1.0.0-SNAPSHOT, should be 2.0.0-SNAPSHOT.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (MNG-6235) Properties from .mvn/maven.config cannot be overwritten from command line
[
https://issues.apache.org/jira/browse/MNG-6235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mariusz Smykuła closed MNG-6235.
Resolution: Invalid
> Properties from .mvn/maven.config cannot be overwritten from command line
> -
>
> Key: MNG-6235
> URL: https://issues.apache.org/jira/browse/MNG-6235
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0
>Reporter: Mariusz Smykuła
>
> Whole procedure is described in blog post:
> http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/
> I have setted version in {{.mvn/maven.config}}
> {code}
> -Drevision=1.0.0-SNAPSHOT
> {code}
> and when invoking build with command:
> {{mvn clean package -Drevision=2.0.0-SNAPSHOT}}
> version is still 1.0.0-SNAPSHOT, should be 2.0.0-SNAPSHOT.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MRESOURCES-236) Copying of files with permissions broken
[ https://issues.apache.org/jira/browse/MRESOURCES-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16016011#comment-16016011 ] dinwath commented on MRESOURCES-236: I have the same problem as Nikolai Grigoriev in https://issues.apache.org/jira/browse/MRESOURCES-132?focusedCommentId=15235927&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15235927 Tested with Maven 3.3.9 and maven-resource-plugin 2.6 > Copying of files with permissions broken > > > Key: MRESOURCES-236 > URL: https://issues.apache.org/jira/browse/MRESOURCES-236 > Project: Maven Resources Plugin > Issue Type: Bug > Components: copy >Affects Versions: 2.4.3 >Reporter: Gili > > Please reopen MRESOURCES-132 as multiple reporters indicate that the bug > still exists (some provided more concrete repro steps). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MDEP-541) Allow for a space character as a pathSeparator in dependency:build-classpath
[
https://issues.apache.org/jira/browse/MDEP-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16016050#comment-16016050
]
dinwath commented on MDEP-541:
--
Another use Case: I'm dealing with an application that uses ATG Dynamo
framework and thus I need to build an EAR manifest which contains an entry with
an "ATG-Class-Path" key (instead of "Class-Path"), so right now I'm using the
same workaround suggested by opener:
{code:xml}
<...>
org.apache.maven.plugins
maven-dependency-plugin
get-classpath-for-manifest
generate-sources
build-classpath
atg-classpath
@_@
/
${lib-path}
war
org.codehaus.mojo
build-helper-maven-plugin
${plugin.build-helper-maven-plugin.version}
fix-classpath-for-manifest
generate-sources
regex-property
atg-classpath
${atg-classpath}
@_@
false
org.apache.maven.plugins
maven-ear-plugin
DAS
${war.artifactId}-${war.version}.war
${maven.build.timestamp}
classes
${atg-classpath}
${lib-path}
true
my.group.id
${war.artifactId}
/
<...>
{code}
> Allow for a space character as a pathSeparator in dependency:build-classpath
>
>
> Key: MDEP-541
> URL: https://issues.apache.org/jira/browse/MDEP-541
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: build-classpath
>Reporter: Giedrius Noreikis
>
> Currently, the {{dependency:build-classpath}} goal does not allow a space
> character to be specified as a {{pathSeparator}}, which is necessary to
> generate {{Class-Path}} values for manifests.
> Because of a check {{isPathSepSet = StringUtils.isNotEmpty( pathSeparator )}}
> in {{BuildClasspathMojo.java}}, the parameter gets ignored in this case, and
> the classpath is built with a default separator.
> The possible workaround is to fix the path with
> {{build-helper:regex-property}}:
> {code:xml}
>
> org.codehaus.mojo
> build-helper-maven-plugin
>
>
> fix-classpath-for-manifest
> prepare-package
> regex-property
>
> appClasspath
> ${appClasspath}
> ;
>
> false
>
>
>
>
> {code}
> but a fix would allow for a more straightforward solution.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MDEP-541) Allow for a space character as a pathSeparator in dependency:build-classpath
[
https://issues.apache.org/jira/browse/MDEP-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16016050#comment-16016050
]
dinwath edited comment on MDEP-541 at 5/18/17 4:48 PM:
---
Another use Case: I'm dealing with an application that uses ATG Dynamo
framework and thus I need to build an EAR manifest which contains an entry with
an {noformat}ATG-Class-Path{noformat} key (instead of
{noformat}Class-Path{noformat}), so right now I'm using the same workaround
suggested by opener:
{code:xml}
<...>
org.apache.maven.plugins
maven-dependency-plugin
get-classpath-for-manifest
generate-sources
build-classpath
atg-classpath
@_@
/
${lib-path}
war
org.codehaus.mojo
build-helper-maven-plugin
${plugin.build-helper-maven-plugin.version}
fix-classpath-for-manifest
generate-sources
regex-property
atg-classpath
${atg-classpath}
@_@
false
org.apache.maven.plugins
maven-ear-plugin
DAS
${war.artifactId}-${war.version}.war
${maven.build.timestamp}
classes
${atg-classpath}
${lib-path}
true
my.group.id
${war.artifactId}
/
<...>
{code}
as he says, a fix would provide fora a more straightforward usage
was (Author: dinwath):
Another use Case: I'm dealing with an application that uses ATG Dynamo
framework and thus I need to build an EAR manifest which contains an entry with
an "ATG-Class-Path" key (instead of "Class-Path"), so right now I'm using the
same workaround suggested by opener:
{code:xml}
<...>
org.apache.maven.plugins
maven-dependency-plugin
get-classpath-for-manifest
generate-sources
build-classpath
atg-classpath
@_@
/
${lib-path}
war
org.codehaus.mojo
build-helper-maven-plugin
${plugin.build-helper-maven-plugin.version}
fix-classpath-for-manifest
generate-sources
regex-property
atg-classpath
${atg-classpath}
@_@
false
org.apache.maven.plugins
maven-ear-plugin
[jira] [Comment Edited] (MDEP-541) Allow for a space character as a pathSeparator in dependency:build-classpath
[
https://issues.apache.org/jira/browse/MDEP-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16016050#comment-16016050
]
dinwath edited comment on MDEP-541 at 5/18/17 4:51 PM:
---
Another use Case: I'm dealing with an application that uses ATG Dynamo
framework and thus I need to build an EAR manifest which contains an entry with
an {{ATG-Class-Path}} key (instead of {{Class-Path}}), so right now I'm using
the same workaround suggested by opener:
{code:xml}
<...>
org.apache.maven.plugins
maven-dependency-plugin
get-classpath-for-manifest
generate-sources
build-classpath
atg-classpath
@_@
/
${lib-path}
war
org.codehaus.mojo
build-helper-maven-plugin
${plugin.build-helper-maven-plugin.version}
fix-classpath-for-manifest
generate-sources
regex-property
atg-classpath
${atg-classpath}
@_@
false
org.apache.maven.plugins
maven-ear-plugin
DAS
${war.artifactId}-${war.version}.war
${maven.build.timestamp}
classes
${atg-classpath}
${lib-path}
true
my.group.id
${war.artifactId}
/
<...>
{code}
as he says, a fix would provide fora a more straightforward usage
was (Author: dinwath):
Another use Case: I'm dealing with an application that uses ATG Dynamo
framework and thus I need to build an EAR manifest which contains an entry with
an {noformat}ATG-Class-Path{noformat} key (instead of
{noformat}Class-Path{noformat}), so right now I'm using the same workaround
suggested by opener:
{code:xml}
<...>
org.apache.maven.plugins
maven-dependency-plugin
get-classpath-for-manifest
generate-sources
build-classpath
atg-classpath
@_@
/
${lib-path}
war
org.codehaus.mojo
build-helper-maven-plugin
${plugin.build-helper-maven-plugin.version}
fix-classpath-for-manifest
generate-sources
regex-property
atg-classpath
${atg-classpath}
@_@
false
org.apache.maven.plugins
maven-ear-plugin
[jira] [Comment Edited] (MDEP-541) Allow for a space character as a pathSeparator in dependency:build-classpath
[
https://issues.apache.org/jira/browse/MDEP-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16016050#comment-16016050
]
dinwath edited comment on MDEP-541 at 5/18/17 4:52 PM:
---
Another use Case: I'm dealing with an application that uses ATG Dynamo
framework and thus I need to build an EAR manifest which contains an entry with
an {{ATG-Class-Path}} key (instead of {{Class-Path}}), so right now I'm using
the same workaround suggested by opener:
{code:xml}
<...>
org.apache.maven.plugins
maven-dependency-plugin
get-classpath-for-manifest
generate-sources
build-classpath
atg-classpath
@_@
/
${lib-path}
war
org.codehaus.mojo
build-helper-maven-plugin
${plugin.build-helper-maven-plugin.version}
fix-classpath-for-manifest
generate-sources
regex-property
atg-classpath
${atg-classpath}
@_@
false
org.apache.maven.plugins
maven-ear-plugin
DAS
${war.artifactId}-${war.version}.war
${maven.build.timestamp}
classes
${atg-classpath}
${lib-path}
true
my.group.id
${war.artifactId}
/
<...>
{code}
as he says, a fix would provide for a a more straightforward usage
was (Author: dinwath):
Another use Case: I'm dealing with an application that uses ATG Dynamo
framework and thus I need to build an EAR manifest which contains an entry with
an {{ATG-Class-Path}} key (instead of {{Class-Path}}), so right now I'm using
the same workaround suggested by opener:
{code:xml}
<...>
org.apache.maven.plugins
maven-dependency-plugin
get-classpath-for-manifest
generate-sources
build-classpath
atg-classpath
@_@
/
${lib-path}
war
org.codehaus.mojo
build-helper-maven-plugin
${plugin.build-helper-maven-plugin.version}
fix-classpath-for-manifest
generate-sources
regex-property
atg-classpath
${atg-classpath}
@_@
false
org.apache.maven.plugins
maven-ear-plugin
[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=16016136#comment-16016136
]
Tibor Digana commented on SUREFIRE-1302:
[~opeyrusse]
I guess this this 1GB of committed memory: 888M->820M(1024M)
According to my equation 1GB should be 17 seconds. But 12 is less than 17. So
the ping should be tolerant.
Could you please print a log in the ping thread? It should print a message
every second.
In other words the ping of 10 seconds should turn to 17 seconds when committed
memory is 1 GB.
Debugging the code would be hard but putting more logs, according to your
preference, may help.
> 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-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=16016136#comment-16016136
]
Tibor Digana edited comment on SUREFIRE-1302 at 5/18/17 5:37 PM:
-
[~opeyrusse]
I guess this is 1GB of committed memory: 888M->820M(1024M)
According to my equation 1GB should be 17 seconds. But 12 is less than 17. So
the ping should be tolerant.
Could you please print a log in the ping thread? It should print a message
every second.
In other words the ping of 10 seconds should turn to 17 seconds when committed
memory is 1 GB.
Debugging the code would be hard but putting more logs, according to your
preference, may help.
was (Author: tibor17):
[~opeyrusse]
I guess this this 1GB of committed memory: 888M->820M(1024M)
According to my equation 1GB should be 17 seconds. But 12 is less than 17. So
the ping should be tolerant.
Could you please print a log in the ping thread? It should print a message
every second.
In other words the ping of 10 seconds should turn to 17 seconds when committed
memory is 1 GB.
Debugging the code would be hard but putting more logs, according to your
preference, may help.
> 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-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] (MNG-6233) maven-resolver-provider mixes jsr330 and plexus annotations
[ https://issues.apache.org/jira/browse/MNG-6233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16016154#comment-16016154 ] Jason Dillon commented on MNG-6233: --- [~igorf] changes look reasonable, and tested locally seems to function as expected. > maven-resolver-provider mixes jsr330 and plexus annotations > --- > > Key: MNG-6233 > URL: https://issues.apache.org/jira/browse/MNG-6233 > Project: Maven > Issue Type: Bug >Affects Versions: 3.3.9, 3.5.0 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.5.1-candidate > > > Mixed annotations confuse guice/sisu and result in hard to troubleshoot and > impossible to workaround problems in applications that embed Maven core > runtime, like m2e and gshell. > I believe plugins annotations where left in the code by mistake so the plan > is to update the code to use jsr330 exclusively and completely remove plexus > annotations. This change is fully transparent to the users (and we've been > using it internally for couple of months now). > See also https://github.com/apache/maven/pull/116 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
