[jira] [Commented] (ARCHETYPE-311) Basedir property in archetype:generate cannot be overriden
[
https://issues.apache.org/jira/browse/ARCHETYPE-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336854#comment-16336854
]
Yan Zhang commented on ARCHETYPE-311:
-
{{Same for me.}}
{{maven-archetype-plugin:3.0.1, }}`-Dbasedir` doesn't work at all.
Others also suffer from the same issue:
[https://stackoverflow.com/questions/46439296/how-can-i-specify-the-directory-where-to-create-the-project-for-archetypegenera]
After so many years, is there any update?
> Basedir property in archetype:generate cannot be overriden
> --
>
> Key: ARCHETYPE-311
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-311
> Project: Maven Archetype
> Issue Type: Bug
> Environment: Windows XP, maven 2.2.0
>Reporter: Samuli Saarinen
>Priority: Major
> Attachments: patch.txt
>
>
> Following is the output when trying to execute archetype:generate using
> alternative directory for basedir
> D:\tmp>mvn -o -npr archetype:generate *-Dbasedir=d:/foo*
>
> [INFO]
>
> [INFO] Using following parameters for creating OldArchetype:
> maven-archetype-quickstart:RELEASE
> [INFO]
>
> [INFO] Parameter: groupId, Value: test
> [INFO] Parameter: packageName, Value: test
> [INFO] Parameter: package, Value: test
> [INFO] Parameter: artifactId, Value: test
> [INFO] Parameter: basedir, Value: *D:\tmp*
> [INFO] Parameter: version, Value: 1.0-SNAPSHOT
> [INFO] * End of debug info from resources from generated
> POM ***
> [INFO] OldArchetype created in dir: D:\tmp\test
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 8 seconds
> [INFO] Finished at: Fri Apr 16 10:53:06 EEST 2010
> [INFO] Final Memory: 10M/19M
> [INFO]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MRESOLVER-39) deadlock during multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MRESOLVER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336734#comment-16336734
]
Yegor Borovikov edited comment on MRESOLVER-39 at 1/24/18 1:52 AM:
---
Thank you for hunting it down!
Attaching [^MRESOLVER-39.tar.gz] (3 tiny poms) for easy reproduction:
{code:java}
rm -rf ~/.m2/repository/com/google/code/findbugs/jsr305/3.0.2
mvn -T2 compiler:compile
{code}
was (Author: yborovikov):
Thank you for hunting it down!
Attaching [^MRESOLVER-39.tar.gz] (3 tiny poms) for easy reproduction:
{code:java}
rm -rf ~/.m2/repository/com/google/code/findbugs/jsr305/3.0.2
mvn -T2 compiler:compile
{code}
> deadlock during multithreaded dependency resolution
> ---
>
> Key: MRESOLVER-39
> URL: https://issues.apache.org/jira/browse/MRESOLVER-39
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Priority: Major
> Attachments: MRESOLVER-39.tar.gz
>
>
> narrowed down a resolution problem to the commit ad50215 ; which belongs to
> MRESOLVER-13
> Probably the changes in PartialFile might be the most relevant wrt to this
> problem.
> for stack traces, see MNG-6323, MNG-6324
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOLVER-39) deadlock during multithreaded dependency resolution
[
https://issues.apache.org/jira/browse/MRESOLVER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336734#comment-16336734
]
Yegor Borovikov commented on MRESOLVER-39:
--
Thank you for hunting it down!
Attaching [^MRESOLVER-39.tar.gz] (3 tiny poms) for easy reproduction:
{code:java}
rm -rf ~/.m2/repository/com/google/code/findbugs/jsr305/3.0.2
mvn -T2 compiler:compile
{code}
> deadlock during multithreaded dependency resolution
> ---
>
> Key: MRESOLVER-39
> URL: https://issues.apache.org/jira/browse/MRESOLVER-39
> Project: Maven Resolver
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Priority: Major
> Attachments: MRESOLVER-39.tar.gz
>
>
> narrowed down a resolution problem to the commit ad50215 ; which belongs to
> MRESOLVER-13
> Probably the changes in PartialFile might be the most relevant wrt to this
> problem.
> for stack traces, see MNG-6323, MNG-6324
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MRESOLVER-39) deadlock during multithreaded dependency resolution
[ https://issues.apache.org/jira/browse/MRESOLVER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yegor Borovikov updated MRESOLVER-39: - Attachment: MRESOLVER-39.tar.gz > deadlock during multithreaded dependency resolution > --- > > Key: MRESOLVER-39 > URL: https://issues.apache.org/jira/browse/MRESOLVER-39 > Project: Maven Resolver > Issue Type: Bug >Reporter: Zoltan Haindrich >Priority: Major > Attachments: MRESOLVER-39.tar.gz > > > narrowed down a resolution problem to the commit ad50215 ; which belongs to > MRESOLVER-13 > Probably the changes in PartialFile might be the most relevant wrt to this > problem. > for stack traces, see MNG-6323, MNG-6324 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-39) deadlock during multithreaded dependency resolution
[ https://issues.apache.org/jira/browse/MRESOLVER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yegor Borovikov updated MRESOLVER-39: - Attachment: (was: MRESOLVER-39.tar.gz) > deadlock during multithreaded dependency resolution > --- > > Key: MRESOLVER-39 > URL: https://issues.apache.org/jira/browse/MRESOLVER-39 > Project: Maven Resolver > Issue Type: Bug >Reporter: Zoltan Haindrich >Priority: Major > > narrowed down a resolution problem to the commit ad50215 ; which belongs to > MRESOLVER-13 > Probably the changes in PartialFile might be the most relevant wrt to this > problem. > for stack traces, see MNG-6323, MNG-6324 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MRESOLVER-39) deadlock during multithreaded dependency resolution
[ https://issues.apache.org/jira/browse/MRESOLVER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yegor Borovikov updated MRESOLVER-39: - Attachment: MRESOLVER-39.tar.gz > deadlock during multithreaded dependency resolution > --- > > Key: MRESOLVER-39 > URL: https://issues.apache.org/jira/browse/MRESOLVER-39 > Project: Maven Resolver > Issue Type: Bug >Reporter: Zoltan Haindrich >Priority: Major > Attachments: MRESOLVER-39.tar.gz > > > narrowed down a resolution problem to the commit ad50215 ; which belongs to > MRESOLVER-13 > Probably the changes in PartialFile might be the most relevant wrt to this > problem. > for stack traces, see MNG-6323, MNG-6324 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1467) Custom junit listener is not executed with java 9
[
https://issues.apache.org/jira/browse/SUREFIRE-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milan Mimica updated SUREFIRE-1467:
---
Component/s: (was: Maven Failsafe Plugin)
> Custom junit listener is not executed with java 9
> -
>
> Key: SUREFIRE-1467
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1467
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.20.1
>Reporter: Milan Mimica
>Priority: Major
> Labels: java9
>
> Custom junit {{RunListener}} is not executed when using java 9.0.4. Works
> fine with java 1.8.0u144.
> Check [the minimal project|https://github.com/mmimica/surefire-listener-fail]
> and [debug
> output|https://gist.github.com/mmimica/f55789c6d57a42c398e2fd9042ebfa31] from
> {{mvn -X test}}. Line "testRunSatrted" should be present in the output but it
> isn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1467) Custom junit listener is not executed with java 9
[
https://issues.apache.org/jira/browse/SUREFIRE-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milan Mimica updated SUREFIRE-1467:
---
Labels: java9 (was: )
> Custom junit listener is not executed with java 9
> -
>
> Key: SUREFIRE-1467
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1467
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.20.1
>Reporter: Milan Mimica
>Priority: Major
> Labels: java9
>
> Custom junit {{RunListener}} is not executed when using java 9.0.4. Works
> fine with java 1.8.0u144.
> Check [the minimal project|https://github.com/mmimica/surefire-listener-fail]
> and [debug
> output|https://gist.github.com/mmimica/f55789c6d57a42c398e2fd9042ebfa31] from
> {{mvn -X test}}. Line "testRunSatrted" should be present in the output but it
> isn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1467) Custom junit listener is not executed with java 9
[
https://issues.apache.org/jira/browse/SUREFIRE-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milan Mimica updated SUREFIRE-1467:
---
Description:
Custom junit {{RunListener}} is not executed when using java 9.0.4. Works fine
with java 1.8.0u144.
Check [the minimal project|https://github.com/mmimica/surefire-listener-fail]
and [debug
output|https://gist.github.com/mmimica/f55789c6d57a42c398e2fd9042ebfa31] from
{{mvn -X test}}. Line "testRunSatrted" should be present in the output but it
isn't.
was:
Custom junit {{RunListener}} is not executed when using java 9.0.4. Works fine
with java 1.8.0u144.
Attached is the minimal project and debug output from {{mvn clean verify}}.
> Custom junit listener is not executed with java 9
> -
>
> Key: SUREFIRE-1467
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1467
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Failsafe Plugin
>Affects Versions: 2.20.1
>Reporter: Milan Mimica
>Priority: Major
>
> Custom junit {{RunListener}} is not executed when using java 9.0.4. Works
> fine with java 1.8.0u144.
> Check [the minimal project|https://github.com/mmimica/surefire-listener-fail]
> and [debug
> output|https://gist.github.com/mmimica/f55789c6d57a42c398e2fd9042ebfa31] from
> {{mvn -X test}}. Line "testRunSatrted" should be present in the output but it
> isn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1467) Custom junit listener is not executed with java 9
[
https://issues.apache.org/jira/browse/SUREFIRE-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milan Mimica updated SUREFIRE-1467:
---
Attachment: (was: iz)
> Custom junit listener is not executed with java 9
> -
>
> Key: SUREFIRE-1467
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1467
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Failsafe Plugin
>Affects Versions: 2.20.1
>Reporter: Milan Mimica
>Priority: Major
>
> Custom junit {{RunListener}} is not executed when using java 9.0.4. Works
> fine with java 1.8.0u144.
> Check [the minimal project|https://github.com/mmimica/surefire-listener-fail]
> and [debug
> output|https://gist.github.com/mmimica/f55789c6d57a42c398e2fd9042ebfa31] from
> {{mvn -X test}}. Line "testRunSatrted" should be present in the output but it
> isn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1467) Custom junit listener is not executed with java 9
[
https://issues.apache.org/jira/browse/SUREFIRE-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Milan Mimica updated SUREFIRE-1467:
---
Attachment: (was: junit-listener-test.tar.gz)
> Custom junit listener is not executed with java 9
> -
>
> Key: SUREFIRE-1467
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1467
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Failsafe Plugin
>Affects Versions: 2.20.1
>Reporter: Milan Mimica
>Priority: Major
>
> Custom junit {{RunListener}} is not executed when using java 9.0.4. Works
> fine with java 1.8.0u144.
> Check [the minimal project|https://github.com/mmimica/surefire-listener-fail]
> and [debug
> output|https://gist.github.com/mmimica/f55789c6d57a42c398e2fd9042ebfa31] from
> {{mvn -X test}}. Line "testRunSatrted" should be present in the output but it
> isn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MJMOD-10) Upgrade maven-plugin-plugin to 3.5.1
[ https://issues.apache.org/jira/browse/MJMOD-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MJMOD-10. Resolution: Fixed Done in [cd8aa8d0177cf2e893b18c9c712991542eaf2b24|https://gitbox.apache.org/repos/asf?p=maven-jmod-plugin.git;a=commitdiff;h=cd8aa8d0177cf2e893b18c9c712991542eaf2b24] > Upgrade maven-plugin-plugin to 3.5.1 > > > Key: MJMOD-10 > URL: https://issues.apache.org/jira/browse/MJMOD-10 > Project: Maven JMod Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-alpha-1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0-alpha-2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJLINK-10) Upgrade maven-plugin-plugin to 3.5.1
[ https://issues.apache.org/jira/browse/MJLINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MJLINK-10. - Resolution: Fixed Done [de540b99609fde2ac85962e046c1915cd6414c50|https://gitbox.apache.org/repos/asf?p=maven-jlink-plugin.git;a=commitdiff;h=de540b99609fde2ac85962e046c1915cd6414c50] > Upgrade maven-plugin-plugin to 3.5.1 > > > Key: MJLINK-10 > URL: https://issues.apache.org/jira/browse/MJLINK-10 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-alpha-1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0-alpha-2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJLINK-10) Upgrade maven-plugin-plugin to 3.5.1
[ https://issues.apache.org/jira/browse/MJLINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336459#comment-16336459 ] Hudson commented on MJLINK-10: -- Build succeeded in Jenkins: Maven TLP » maven-jlink-plugin » master #3 See https://builds.apache.org/job/maven-box/job/maven-jlink-plugin/job/master/3/ > Upgrade maven-plugin-plugin to 3.5.1 > > > Key: MJLINK-10 > URL: https://issues.apache.org/jira/browse/MJLINK-10 > Project: Maven JLink Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-alpha-1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0-alpha-2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJMOD-10) Upgrade maven-plugin-plugin to 3.5.1
[ https://issues.apache.org/jira/browse/MJMOD-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336457#comment-16336457 ] Hudson commented on MJMOD-10: - Build succeeded in Jenkins: Maven TLP » maven-jmod-plugin » master #3 See https://builds.apache.org/job/maven-box/job/maven-jmod-plugin/job/master/3/ > Upgrade maven-plugin-plugin to 3.5.1 > > > Key: MJMOD-10 > URL: https://issues.apache.org/jira/browse/MJMOD-10 > Project: Maven JMod Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-alpha-1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.0.0-alpha-2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJMOD-10) Upgrade maven-plugin-plugin to 3.5.1
Karl Heinz Marbaise created MJMOD-10: Summary: Upgrade maven-plugin-plugin to 3.5.1 Key: MJMOD-10 URL: https://issues.apache.org/jira/browse/MJMOD-10 Project: Maven JMod Plugin Issue Type: Dependency upgrade Affects Versions: 3.0.0-alpha-1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.0.0-alpha-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJLINK-10) Upgrade maven-plugin-plugin to 3.5.1
Karl Heinz Marbaise created MJLINK-10: - Summary: Upgrade maven-plugin-plugin to 3.5.1 Key: MJLINK-10 URL: https://issues.apache.org/jira/browse/MJLINK-10 Project: Maven JLink Plugin Issue Type: Dependency upgrade Affects Versions: 3.0.0-alpha-1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.0.0-alpha-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MENFORCER-295) Upgrade maven-plugin-plugin to 3.5.1
Karl Heinz Marbaise created MENFORCER-295: - Summary: Upgrade maven-plugin-plugin to 3.5.1 Key: MENFORCER-295 URL: https://issues.apache.org/jira/browse/MENFORCER-295 Project: Maven Enforcer Plugin Issue Type: Dependency upgrade Affects Versions: 3.0.0-M1 Reporter: Karl Heinz Marbaise Assignee: Karl Heinz Marbaise Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SUREFIRE-1467) Custom junit listener is not executed with java 9
Milan Mimica created SUREFIRE-1467:
--
Summary: Custom junit listener is not executed with java 9
Key: SUREFIRE-1467
URL: https://issues.apache.org/jira/browse/SUREFIRE-1467
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support, Maven Failsafe Plugin
Affects Versions: 2.20.1
Reporter: Milan Mimica
Attachments: iz, junit-listener-test.tar.gz
Custom junit {{RunListener}} is not executed when using java 9.0.4. Works fine
with java 1.8.0u144.
Attached is the minimal project and debug output from {{mvn clean verify}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336414#comment-16336414
]
Robert Scholte commented on MASSEMBLY-775:
--
When using {{File}} such path (starting with a slash!) is resolved as absolute
on Linux and relative to the working directory on Windows.
This can be done on purpose, so maybe a warning is better. However in general I
would expect that it should be relative to the project directory, so the
starting slash would be a mistake with consequences.
I think we should start using {{Path}}, so the behavior is the same for all
OSes.
{{project.getBasedir().toPath().resolve( "/a/b/c" );}}
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1445) Properties from configuration POM are not passed to Provider on JDK 9
[
https://issues-test.apache.org/jira/browse/SUREFIRE-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265597#comment-16265597
]
Marc Philipp commented on SUREFIRE-1445:
AFAIK that should fix it and this issue can be closed. Thanks!
> Properties from configuration POM are not passed to Provider on JDK 9
> -
>
> Key: SUREFIRE-1445
> URL: https://issues-test.apache.org/jira/browse/SUREFIRE-1445
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.19.1, 2.20, 2.20.1
> Environment: JDK 9
>Reporter: Marc Philipp
>Assignee: Tibor Digana
>Priority: Blocker
>
> Given the POM below, the {{JUnitPlatformProvider}} can read {{"excludeTags"}}
> = {{"slow"}} from {{ProviderParameters.getProviderProperties()}} when it runs
> on JDK 8 but not on JDK 9.
> The reason is that the constructor of {{SurefireProperties}} relies on an
> implementation detail of the class it extends, namely that {{putAll()}} will
> call {{put()}} for each entry. However, while {{Properties}} does that on JDK
> 8, it doesn't on JDK 9.
> Here's a link to the line in {{SurefireProperties}}:
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/SurefireProperties.java#L62
> {code:xml}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> junit5
> tagging
> 1.0-SNAPSHOT
>
>
>
> maven-surefire-plugin
> 2.19.1
>
>
> slow
>
>
>
>
> org.junit.platform
>
> junit-platform-surefire-provider
> 1.0.2
>
>
> org.junit.jupiter
> junit-jupiter-engine
> 5.0.2
>
>
>
>
>
>
>
> org.junit.jupiter
> junit-jupiter-api
> 5.0.2
> test
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.0#76001)
[jira] [Comment Edited] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336194#comment-16336194
]
Gordon Pettey edited comment on MASSEMBLY-775 at 1/23/18 6:33 PM:
--
I submitted a PR to completely remove these checks. The error messages are
simply wrong. {{/}} is a valid path separator on Windows (especially since any
file access here is done via Java). {{:}} is a valid second character in a
Linux filename.
was (Author: gpettey):
I submitted a PR to completely remove these checks. The error messages are
simply wrong. {{/}} is a valid path separator on Windows. {{:}} is a valid
second character in a Linux filename.
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-775) Emit WARNING instead of ERROR
[
https://issues.apache.org/jira/browse/MASSEMBLY-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16336194#comment-16336194
]
Gordon Pettey commented on MASSEMBLY-775:
-
I submitted a PR to completely remove these checks. The error messages are
simply wrong. {{/}} is a valid path separator on Windows. {{:}} is a valid
second character in a Linux filename.
> Emit WARNING instead of ERROR
> -
>
> Key: MASSEMBLY-775
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-775
> Project: Maven Assembly Plugin
> Issue Type: Improvement
>Affects Versions: 2.5.5
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> I have currently a build which creates several tar/tar.gz/zip archives etc.
> {code}
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor-inner-tar.xml
> [INFO] Reading assembly descriptor: src/main/assembly/descriptor.xml
> [INFO] Building tar: C:\...\xyz-X.y.z-SNAPSHOT-dist.tar
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> [ERROR] OS=Windows and the assembly descriptor contains a *nix-specific
> root-relative-reference (starting with slash) /
> {code}
> In my opinion the message could be a WARNING instead of an error ? WDYT ?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1466) Surefire fails on a dummy:dummy dependency with a authenticating proxy
[
https://issues.apache.org/jira/browse/SUREFIRE-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1466:
---
Fix Version/s: 3.0
> Surefire fails on a dummy:dummy dependency with a authenticating proxy
> --
>
> Key: SUREFIRE-1466
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1466
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.18.1, 2.20.1
> Environment: Stack traces with Maven 3.3.9, but also tried with latest
>Reporter: J.Cranendonk
>Priority: Major
> Fix For: 3.0
>
>
> We have a rather limited environment, internet is available through an
> authenticated proxy, and most things we get from a company nexus.
> Getting artifacts from either works fine, but it seems surefire does
> something fancy that breaks and ends in a ArtifactResolutionException
> regarding proxy authentication, related to a dummy:dummy artifact (which
> seems to be some hacky provider classpath resolving things in surefire?).
> Error message:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
> project BsnkInterfaceHandlerService: Unable to generate classpath:
> org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get
> dependency information for
> org.apache.maven.surefire:surefire-junit4:jar:2.18.1: Failed to retrieve POM
> for org.apache.maven.surefire:surefire-junit4:jar:2.18.1: Could not transfer
> artifact org.apache.maven.surefire:surefire-junit4:pom:2.18.1 from/to
> prog-sys-development (https:// to know :)>/nexus/content/groups/prog-sys-development): Not authorized by
> proxy , ReasonPhrase:authenticationrequired.
> [ERROR] org.apache.maven.surefire:surefire-junit4:jar:2.18.1
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] prog-sys-development (https:// want you to know :)>/nexus/content/groups/prog-sys-development,
> releases=true, snapshots=false)
> [ERROR] Path to dependency:
> [ERROR] 1) dummy:dummy:jar:1.0
> [ERROR] -> [Help 1]{noformat}
> Stack trace of the issue (first):
> {noformat}
> Thread [main] (Suspended (exception ArtifactResolutionException))
>
> DefaultArtifactCollector(DefaultLegacyArtifactCollector).recurse(ArtifactResolutionResult,
> ResolutionNode, Map>, ManagedVersionMap,
> ArtifactResolutionRequest, ArtifactMetadataSource, ArtifactFilter,
> List, List) line: 576
>
> DefaultArtifactCollector(DefaultLegacyArtifactCollector).collect(Set,
> Artifact, Map, ArtifactResolutionRequest,
> ArtifactMetadataSource, ArtifactFilter, List,
> List) line: 144
> DefaultArtifactResolver.resolve(ArtifactResolutionRequest) line: 493
> DefaultArtifactResolver.resolveWithExceptions(ArtifactResolutionRequest)
> line: 348
> DefaultArtifactResolver.resolveTransitively(Set, Artifact,
> Map, ArtifactRepository, List,
> ArtifactMetadataSource, ArtifactFilter, List,
> List) line: 342
> DefaultArtifactResolver.resolveTransitively(Set, Artifact,
> Map, ArtifactRepository, List,
> ArtifactMetadataSource, ArtifactFilter, List) line: 321
>
> DefaultArtifactResolver.resolveTransitively(Set, Artifact,
> Map, ArtifactRepository, List,
> ArtifactMetadataSource, ArtifactFilter) line: 286
> DefaultArtifactResolver.resolveTransitively(Set, Artifact,
> ArtifactRepository, List, ArtifactMetadataSource,
> ArtifactFilter) line: 261
> SurefireDependencyResolver.resolveArtifact(Artifact, Artifact) line: 125
>
> SurefireDependencyResolver.getProviderClasspath(String, String, Artifact)
> line: 140
> AbstractSurefireMojo$JUnit4ProviderInfo.getProviderClasspath() line: 2392
>
>
> SurefirePlugin(AbstractSurefireMojo).createStartupConfiguration(ProviderInfo,
> ClassLoaderConfiguration) line: 1473
> SurefirePlugin(AbstractSurefireMojo).createForkStarter(ProviderInfo,
> ForkConfiguration, ClassLoaderConfiguration, RunOrderParameters, Log) line:
> 1758
> SurefirePlugin(AbstractSurefireMojo).executeProvider(ProviderInfo,
> DefaultScanResult) line: 987
>
> SurefirePlugin(AbstractSurefireMojo).executeAfterPreconditionsChecked(DefaultScanResult)
> line: 824
> SurefirePlugin(AbstractSurefireMojo).execute() line: 722
> DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line:
> 134
> MojoExecutor.execute(MavenSession, MojoExecution, ProjectIndex,
> DependencyContext) line: 207
> MojoExecutor.execute(MavenSession, MojoExecution, ProjectIndex,
> DependencyContext, PhaseRecorder) line: 153
> MojoExecutor.execute(MavenSession, List, ProjectIndex)
> line: 145
> LifecycleModuleBuilder.buildProject(Mave
[jira] [Updated] (ARCHETYPE-538) When re-entering property values after answering 'N' to confirm properties configuration during archetype:generate, prompts should default to the previously-entered va
[ https://issues.apache.org/jira/browse/ARCHETYPE-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Scourfield updated ARCHETYPE-538: --- Description: Let's say I define a value for groupId, artifactId, version, and a handful of custom properties via the interactive prompt when using archetype:generate, but at the confirmation stage I notice a mistake and hit 'N'. I've now got to retype everything again, which is extremely annoying. When the second prompt appears, default values should now be the values which were entered above, allowing the user to just hit ENTER for the values that were correctly entered last time around. This is especially frustrating given custom required properties which have default values that can't be edited during the first prompt (see ARCHETYPE-308) as you may enter a handful of correct values, but then need to choose N at the end to alter the default value of a property that you weren't allowed to enter a value for first time around. was: Let's say I define a value for groupId, artifactId, version, and a handful of custom properties via the interactive prompt when using archetype:generate, but at the confirmation stage I notice a mistake and hit 'N'. I've now got to retype everything again, which is extremely annoying. When the second prompt appears, default values should now be those which were previously entered, allowing the user to just hit ENTER for the values that were correctly entered last time around. This is especially frustrating given custom required properties which have default values that can't be edited during the first prompt (see ARCHETYPE-308) as you may enter a handful of correct values, but then need to choose N at the end to alter the default value of a property that you weren't allowed to enter a value for first time around. > When re-entering property values after answering 'N' to confirm properties > configuration during archetype:generate, prompts should default to the > previously-entered values. > > > Key: ARCHETYPE-538 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-538 > Project: Maven Archetype > Issue Type: Bug >Reporter: David Scourfield >Priority: Minor > > Let's say I define a value for groupId, artifactId, version, and a handful of > custom properties via the interactive prompt when using archetype:generate, > but at the confirmation stage I notice a mistake and hit 'N'. I've now got > to retype everything again, which is extremely annoying. > When the second prompt appears, default values should now be the values which > were entered above, allowing the user to just hit ENTER for the values that > were correctly entered last time around. > This is especially frustrating given custom required properties which have > default values that can't be edited during the first prompt (see > ARCHETYPE-308) as you may enter a handful of correct values, but then need to > choose N at the end to alter the default value of a property that you weren't > allowed to enter a value for first time around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SUREFIRE-1466) Surefire fails on a dummy:dummy dependency with a authenticating proxy
J.Cranendonk created SUREFIRE-1466:
--
Summary: Surefire fails on a dummy:dummy dependency with a
authenticating proxy
Key: SUREFIRE-1466
URL: https://issues.apache.org/jira/browse/SUREFIRE-1466
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.20.1, 2.18.1
Environment: Stack traces with Maven 3.3.9, but also tried with latest
Reporter: J.Cranendonk
We have a rather limited environment, internet is available through an
authenticated proxy, and most things we get from a company nexus.
Getting artifacts from either works fine, but it seems surefire does something
fancy that breaks and ends in a ArtifactResolutionException regarding proxy
authentication, related to a dummy:dummy artifact (which seems to be some hacky
provider classpath resolving things in surefire?).
Error message:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on
project BsnkInterfaceHandlerService: Unable to generate classpath:
org.apache.maven.artifact.resolver.ArtifactResolutionException: Unable to get
dependency information for
org.apache.maven.surefire:surefire-junit4:jar:2.18.1: Failed to retrieve POM
for org.apache.maven.surefire:surefire-junit4:jar:2.18.1: Could not transfer
artifact org.apache.maven.surefire:surefire-junit4:pom:2.18.1 from/to
prog-sys-development (https:///nexus/content/groups/prog-sys-development): Not authorized by proxy ,
ReasonPhrase:authenticationrequired.
[ERROR] org.apache.maven.surefire:surefire-junit4:jar:2.18.1
[ERROR]
[ERROR] from the specified remote repositories:
[ERROR] prog-sys-development (https:///nexus/content/groups/prog-sys-development, releases=true,
snapshots=false)
[ERROR] Path to dependency:
[ERROR] 1) dummy:dummy:jar:1.0
[ERROR] -> [Help 1]{noformat}
Stack trace of the issue (first):
{noformat}
Thread [main] (Suspended (exception ArtifactResolutionException))
DefaultArtifactCollector(DefaultLegacyArtifactCollector).recurse(ArtifactResolutionResult,
ResolutionNode, Map>, ManagedVersionMap,
ArtifactResolutionRequest, ArtifactMetadataSource, ArtifactFilter,
List, List) line: 576
DefaultArtifactCollector(DefaultLegacyArtifactCollector).collect(Set,
Artifact, Map, ArtifactResolutionRequest,
ArtifactMetadataSource, ArtifactFilter, List,
List) line: 144
DefaultArtifactResolver.resolve(ArtifactResolutionRequest) line: 493
DefaultArtifactResolver.resolveWithExceptions(ArtifactResolutionRequest)
line: 348
DefaultArtifactResolver.resolveTransitively(Set, Artifact,
Map, ArtifactRepository, List,
ArtifactMetadataSource, ArtifactFilter, List,
List) line: 342
DefaultArtifactResolver.resolveTransitively(Set, Artifact,
Map, ArtifactRepository, List,
ArtifactMetadataSource, ArtifactFilter, List) line: 321
DefaultArtifactResolver.resolveTransitively(Set, Artifact,
Map, ArtifactRepository, List,
ArtifactMetadataSource, ArtifactFilter) line: 286
DefaultArtifactResolver.resolveTransitively(Set, Artifact,
ArtifactRepository, List, ArtifactMetadataSource,
ArtifactFilter) line: 261
SurefireDependencyResolver.resolveArtifact(Artifact, Artifact) line: 125
SurefireDependencyResolver.getProviderClasspath(String, String, Artifact)
line: 140
AbstractSurefireMojo$JUnit4ProviderInfo.getProviderClasspath() line: 2392
SurefirePlugin(AbstractSurefireMojo).createStartupConfiguration(ProviderInfo,
ClassLoaderConfiguration) line: 1473
SurefirePlugin(AbstractSurefireMojo).createForkStarter(ProviderInfo,
ForkConfiguration, ClassLoaderConfiguration, RunOrderParameters, Log) line:
1758
SurefirePlugin(AbstractSurefireMojo).executeProvider(ProviderInfo,
DefaultScanResult) line: 987
SurefirePlugin(AbstractSurefireMojo).executeAfterPreconditionsChecked(DefaultScanResult)
line: 824
SurefirePlugin(AbstractSurefireMojo).execute() line: 722
DefaultBuildPluginManager.executeMojo(MavenSession, MojoExecution) line:
134
MojoExecutor.execute(MavenSession, MojoExecution, ProjectIndex,
DependencyContext) line: 207
MojoExecutor.execute(MavenSession, MojoExecution, ProjectIndex,
DependencyContext, PhaseRecorder) line: 153
MojoExecutor.execute(MavenSession, List, ProjectIndex) line:
145
LifecycleModuleBuilder.buildProject(MavenSession, MavenSession,
ReactorContext, MavenProject, TaskSegment) line: 116
LifecycleModuleBuilder.buildProject(MavenSession, ReactorContext,
MavenProject, TaskSegment) line: 80
SingleThreadedBuilder.build(MavenSession, ReactorContext, ProjectBuildList,
List, ReactorBuildStatus) line: 51
LifecycleStarter.execute(MavenSession) line: 128
DefaultMaven.doExecute(MavenExecutionRequest, MavenSession,
MavenExecutionResult, DefaultReposi
[jira] [Created] (ARCHETYPE-538) When re-entering property values after answering 'N' to confirm properties configuration during archetype:generate, prompts should default to the previously-entered va
David Scourfield created ARCHETYPE-538: -- Summary: When re-entering property values after answering 'N' to confirm properties configuration during archetype:generate, prompts should default to the previously-entered values. Key: ARCHETYPE-538 URL: https://issues.apache.org/jira/browse/ARCHETYPE-538 Project: Maven Archetype Issue Type: Bug Reporter: David Scourfield Let's say I define a value for groupId, artifactId, version, and a handful of custom properties via the interactive prompt when using archetype:generate, but at the confirmation stage I notice a mistake and hit 'N'. I've now got to retype everything again, which is extremely annoying. When the second prompt appears, default values should now be those which were previously entered, allowing the user to just hit ENTER for the values that were correctly entered last time around. This is especially frustrating given custom required properties which have default values that can't be edited during the first prompt (see ARCHETYPE-308) as you may enter a handful of correct values, but then need to choose N at the end to alter the default value of a property that you weren't allowed to enter a value for first time around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARCHETYPE-538) When re-entering property values after answering 'N' to confirm properties configuration during archetype:generate, prompts should default to the previously-entered va
[ https://issues.apache.org/jira/browse/ARCHETYPE-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Scourfield updated ARCHETYPE-538: --- Priority: Minor (was: Major) > When re-entering property values after answering 'N' to confirm properties > configuration during archetype:generate, prompts should default to the > previously-entered values. > > > Key: ARCHETYPE-538 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-538 > Project: Maven Archetype > Issue Type: Bug >Reporter: David Scourfield >Priority: Minor > > Let's say I define a value for groupId, artifactId, version, and a handful of > custom properties via the interactive prompt when using archetype:generate, > but at the confirmation stage I notice a mistake and hit 'N'. I've now got > to retype everything again, which is extremely annoying. > When the second prompt appears, default values should now be those which were > previously entered, allowing the user to just hit ENTER for the values that > were correctly entered last time around. > This is especially frustrating given custom required properties which have > default values that can't be edited during the first prompt (see > ARCHETYPE-308) as you may enter a handful of correct values, but then need to > choose N at the end to alter the default value of a property that you weren't > allowed to enter a value for first time around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
