[jira] [Created] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
J.Cranendonk created MNG-6583: - Summary: Relative path for parent pom on Windows fails depending on case of drive letter Key: MNG-6583 URL: https://issues.apache.org/jira/browse/MNG-6583 Project: Maven Issue Type: Bug Components: POM Affects Versions: 3.6.0, 3.5.4, 3.5.3, 3.5.2, 3.5.0 Environment: Windows 7 Enterprise Reporter: J.Cranendonk Hi! I've found an odd issue with Maven 3.5.0 and higher (including current: 3.6.0) This issue does not appear in Maven 3.3.9 or older. Works: 3.3.3, 3.3.9 Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0 It seems to be related to whether the cmd current path either starts with a upper case (works) or lower case (doesn't work) driver letter. With an upper case drive letter, relative paths to the parent pom resolve correctly. With a lower case driver letter, relative paths to the parent pom do not resolve correctly. (I will add a sample after creating the issue) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
[
https://issues.apache.org/jira/browse/MNG-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.Cranendonk updated MNG-6583:
--
Description:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
For example, this cmd works:
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+C+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
And this cmd fails, the only difference is the drive letter in the second 'cd'.
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+c+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
I have attached a full minimal example in [^RelativelyInsane.7z]
Extract it to C:\Temp, change the paths to your maven install, and run the cmd's
Log of failed run:
{{[INFO] Scanning for projects...}}
{{[ERROR] [ERROR] Some problems were encountered while processing the POMs:}}
{{[FATAL] Non-resolvable parent POM for reltest.mine:ArtiA:[unknown-version]:
Could not find artifact reltest.mine:parenty:pom:0.0.1-SNAPSHOT and
'parent.relativePath' points at wrong local POM @ line 4, column 13 @}}
{{[ERROR] The build could not read 1 project -> [Help 1]}}
{{[ERROR]}}
{{[ERROR] The project reltest.mine:ArtiA:[unknown-version]
(C:\Temp\RelativelyInsane\ArtiA\pom.xml) has 1 error}}
{{[ERROR] Non-resolvable parent POM for
reltest.mine:ArtiA:[unknown-version]: Could not find artifact
reltest.mine:parenty:pom:0.0.1-SNAPSHOT and 'parent.relativePath' points at
wrong local POM @ line 4, column 13 -> [Help 2]}}
{{[ERROR]}}
{{[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.}}
{{[ERROR] Re-run Maven using the -X switch to enable full debug logging.}}
{{[ERROR]}}
{{[ERROR] For more information about the errors and possible solutions, please
read the following articles:}}
{{[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException}}
{{[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException}}
{{Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3;
2018-10-24T20:41:47+02:00)}}
{{Maven home: C:\Portable\Tools\apache-maven-3.6.0\bin\..}}
{{Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: C:\Program
Files (x86)\Java\jdk1.8.0_192\jre}}
{{Default locale: en_US, platform encoding: Cp1252}}
{{OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"}}
{{Press any key to continue . . .}}
Log of succesfull run:
{{[INFO] Scanning for projects...}}
{{[INFO]
}}
{{[INFO] Reactor Build Order:}}
{{[INFO]}}
{{[INFO] parenty
[pom]}}
{{[INFO] ArtiA
[pom]}}
{{[INFO] rooty
[pom]}}
{{[INFO]}}
{{[INFO] < reltest.mine:parenty
>}}
{{[INFO] Building parenty 0.0.1-SNAPSHOT
[1/3]}}
{{[INFO] [ pom
]-}}
{{[INFO]}}
{{[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ parenty ---}}
{{[INFO]}}
{{[INFO] -< reltest.mine:ArtiA
>-}}
{{[INFO] Building ArtiA 0.0.1-SNAPSHOT
[2/3]}}
{{[INFO] [ pom
]-}}
{{[INFO]}}
{{[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ArtiA ---}}
{{[INFO]}}
{{[INFO] -< reltest.mine:rooty
>-}}
{{[INFO] Building rooty 0.0.1-SNAPSHOT
[3/3]}}
{{[INFO] [ pom
]-}}
{{[INFO]}}
{{[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ rooty ---}}
{{[INFO]
}}
{{[INFO] Reactor Summary for rooty 0.0.1-SNAPSHOT:}}
{{[INFO]}}
{{[INFO] parenty SUCCESS [ 0.141
s]}}
{{[INFO] ArtiA .. SUCCESS [ 0.011
s]}}
{{[INFO] rooty .. SUCCESS [ 0.009
[jira] [Updated] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
[
https://issues.apache.org/jira/browse/MNG-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.Cranendonk updated MNG-6583:
--
Description:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
For example, this cmd works:
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+C+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
And this cmd fails, the only difference is the drive letter in the second 'cd'.
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+c+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
I have attached a full minimal example in [^RelativelyInsane.7z]
Extract it to C:\Temp, change the paths to your maven install, and run the cmd's
was:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
For example, this cmd works:
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+C+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
And this cmd fails, the only difference is the drive letter in the second 'cd'.
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+c+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
> Relative path for parent pom on Windows fails depending on case of drive
> letter
> ---
>
> Key: MNG-6583
> URL: https://issues.apache.org/jira/browse/MNG-6583
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> Environment: Windows 7 Enterprise
>Reporter: J.Cranendonk
>Priority: Major
> Attachments: RelativelyInsane.7z
>
>
> Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
> 3.6.0)
> This issue does not appear in Maven 3.3.9 or older.
> Works: 3.3.3, 3.3.9
> Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> It seems to be related to whether the cmd current path either starts with a
> upper case (works) or lower case (doesn't work) driver letter.
> With an upper case drive letter, relative paths to the parent pom resolve
> correctly.
> With a lower case driver letter, relative paths to the parent pom do not
> resolve correctly.
> For example, this cmd works:
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+C+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
> And this cmd fails, the only difference is the drive letter in the second
> 'cd'.
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+c+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
> I have attached a full minimal example in [^RelativelyInsane.7z]
> Extract it to C:\Temp, change the paths to your maven install, and run the
> cmd's
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
[ https://issues.apache.org/jira/browse/MNG-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] J.Cranendonk updated MNG-6583: -- Attachment: RelativelyInsane.7z > Relative path for parent pom on Windows fails depending on case of drive > letter > --- > > Key: MNG-6583 > URL: https://issues.apache.org/jira/browse/MNG-6583 > Project: Maven > Issue Type: Bug > Components: POM >Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0 > Environment: Windows 7 Enterprise >Reporter: J.Cranendonk >Priority: Major > Attachments: RelativelyInsane.7z > > > Hi! I've found an odd issue with Maven 3.5.0 and higher (including current: > 3.6.0) > This issue does not appear in Maven 3.3.9 or older. > Works: 3.3.3, 3.3.9 > Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0 > It seems to be related to whether the cmd current path either starts with a > upper case (works) or lower case (doesn't work) driver letter. > With an upper case drive letter, relative paths to the parent pom resolve > correctly. > With a lower case driver letter, relative paths to the parent pom do not > resolve correctly. > (I will add a sample after creating the issue) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MNG-6583) Relative path for parent pom on Windows fails depending on case of drive letter
[
https://issues.apache.org/jira/browse/MNG-6583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
J.Cranendonk updated MNG-6583:
--
Description:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
For example, this cmd works:
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+C+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
And this cmd fails, the only difference is the drive letter in the second 'cd'.
{{@ECHO OFF}}
{{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
{{SET PATH=%M2_HOME%\bin;%PATH%}}
{{cd ..}}
{{cd *+c+*:\Temp\RelativelyInsane}}
{{call mvn clean}}
{{call mvn -vesion}}
{{pause}}
was:
Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
3.6.0)
This issue does not appear in Maven 3.3.9 or older.
Works: 3.3.3, 3.3.9
Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
It seems to be related to whether the cmd current path either starts with a
upper case (works) or lower case (doesn't work) driver letter.
With an upper case drive letter, relative paths to the parent pom resolve
correctly.
With a lower case driver letter, relative paths to the parent pom do not
resolve correctly.
(I will add a sample after creating the issue)
> Relative path for parent pom on Windows fails depending on case of drive
> letter
> ---
>
> Key: MNG-6583
> URL: https://issues.apache.org/jira/browse/MNG-6583
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> Environment: Windows 7 Enterprise
>Reporter: J.Cranendonk
>Priority: Major
> Attachments: RelativelyInsane.7z
>
>
> Hi! I've found an odd issue with Maven 3.5.0 and higher (including current:
> 3.6.0)
> This issue does not appear in Maven 3.3.9 or older.
> Works: 3.3.3, 3.3.9
> Fails: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0
> It seems to be related to whether the cmd current path either starts with a
> upper case (works) or lower case (doesn't work) driver letter.
> With an upper case drive letter, relative paths to the parent pom resolve
> correctly.
> With a lower case driver letter, relative paths to the parent pom do not
> resolve correctly.
> For example, this cmd works:
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+C+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
> And this cmd fails, the only difference is the drive letter in the second
> 'cd'.
> {{@ECHO OFF}}
> {{SET M2_HOME=C:\Portable\Tools\apache-maven-3.6.0}}
> {{SET PATH=%M2_HOME%\bin;%PATH%}}
> {{cd ..}}
> {{cd *+c+*:\Temp\RelativelyInsane}}
> {{call mvn clean}}
> {{call mvn -vesion}}
> {{pause}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAR-253) Since 3.0.0 builds fail with You have to use a classifier to attach supplemental artifacts to the project instead of replacing them.
[ https://issues.apache.org/jira/browse/MJAR-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16517880#comment-16517880 ] J.Cranendonk commented on MJAR-253: --- Wrong is a big word, but uncommon possibly :) The artifact is a zip containing files in a distribution format suitable for our customer. I can't create the jar's in sub modules, because they require data/dependencies from the module which creates the zip. The jar's themselves do not become artifacts, they are not uploaded on install/deploy/release, they are included in the zip. We just want to use the jar plugin to create some different jars, in our case actually to hold some classpath information in the metadata :) But I see a workaround in using the assembly plugin to rename the jars, that should work, so I will try that. It might be a cleaner way do achieve the same result :) > Since 3.0.0 builds fail with You have to use a classifier to attach > supplemental artifacts to the project instead of replacing them. > > > Key: MJAR-253 > URL: https://issues.apache.org/jira/browse/MJAR-253 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.0.0, 3.0.1, 3.0.2, 3.1.0 >Reporter: J.Cranendonk >Priority: Minor > > See also: > [https://stackoverflow.com/questions/40964500/maven-jar-plugin-3-0-2-error-you-have-to-use-a-classifier-to-attach-supplementa] > https://issues.apache.org/jira/browse/MJAR-198?focusedCommentId=16420958=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16420958 > https://issues.apache.org/jira/browse/MJAR-198?focusedCommentId=16516772=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16516772 > Builds where multiple jars were created with different names using the > finalName field (for example to create jars to put together in an assembly) > are failing since version 3.0.0 of the plugin. > Apparently cause they now require a classifier field to be set: > You have to use a classifier to attach supplemental artifacts to the project > instead of replacing them. > The problem with fixing this by setting a classifier is that it gets added > after the finalName field, including a dash, which means the final jar has > the wrong name. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MJAR-253) Since 3.0.0 builds fail with You have to use a classifier to attach supplemental artifacts to the project instead of replacing them.
J.Cranendonk created MJAR-253: - Summary: Since 3.0.0 builds fail with You have to use a classifier to attach supplemental artifacts to the project instead of replacing them. Key: MJAR-253 URL: https://issues.apache.org/jira/browse/MJAR-253 Project: Maven JAR Plugin Issue Type: Bug Affects Versions: 3.1.0, 3.0.2, 3.0.1, 3.0.0 Reporter: J.Cranendonk See also: [https://stackoverflow.com/questions/40964500/maven-jar-plugin-3-0-2-error-you-have-to-use-a-classifier-to-attach-supplementa] https://issues.apache.org/jira/browse/MJAR-198?focusedCommentId=16420958=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16420958 https://issues.apache.org/jira/browse/MJAR-198?focusedCommentId=16516772=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16516772 Builds where multiple jars were created with different names using the finalName field (for example to create jars to put together in an assembly) are failing since version 3.0.0 of the plugin. Apparently cause they now require a classifier field to be set: You have to use a classifier to attach supplemental artifacts to the project instead of replacing them. The problem with fixing this by setting a classifier is that it gets added after the finalName field, including a dash, which means the final jar has the wrong name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAR-198) jar:jar without classifier replaces default jar
[ https://issues.apache.org/jira/browse/MJAR-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516772#comment-16516772 ] J.Cranendonk commented on MJAR-198: --- Was an issue made for the comment Archie Cobbs mentioned? We have the same issue, broken build with multiple jar plugins configurations with different finalName's. I'm whitelisted, so can't reach the user or dev list, and google sends me here regarding this issue. What is the workaround? Adding classifier modifies the final name of the jar, instead of just using finalName, it becomes finalName-classifier.. > jar:jar without classifier replaces default jar > --- > > Key: MJAR-198 > URL: https://issues.apache.org/jira/browse/MJAR-198 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 2.3.1, 2.3.2, 2.4, 2.5, 2.6 > Environment: Windows 8.1 Pro > JDK 1.8 45 > Maven 3.2.5 >Reporter: Elias Elmqvist Wulcan >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: newbie > Fix For: 3.0.0 > > Attachments: 0.tar, mvn.install.debug.txt > > > If I add an execution of jar:jar in a project of packaging jar and do not > configure a classifier for the additional jar, the additional jar will be > installed instead of the default jar. > Omitting a classifier in the configuration for the goal jar:jar is documented > to have the effect that the jar will not be attached and this is the behavior > that I want. Instead, the jar is attached and replaces the default jar. > AbstractJarMojo.java:254 checks nullness of classifier to decide whether to > attach or not. JarMojo.java:51 declares a default value the empty string for > classifier. Maybe the combination of these lines cause the bug. > http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/AbstractJarMojo.java?revision=1664111=markup > http://svn.apache.org/viewvc/maven/plugins/tags/maven-jar-plugin-2.6/src/main/java/org/apache/maven/plugin/jar/JarMojo.java?revision=1664111=markup -- 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
