[jira] [Created] (SUREFIRE-1926) Console logs should be synchronized
Tibor Digana created SUREFIRE-1926: -- Summary: Console logs should be synchronized Key: SUREFIRE-1926 URL: https://issues.apache.org/jira/browse/SUREFIRE-1926 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin, Maven Surefire Plugin Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 3.0.0-M6 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-584) Resulting root pom.xml from archetype generation has additional newlines with JDK11
[
https://issues.apache.org/jira/browse/ARCHETYPE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374137#comment-17374137
]
Elliotte Rusty Harold commented on ARCHETYPE-584:
-
I wonder is there's some change in the JDK XML classes between 8 and 11 that
could explain this?
> Resulting root pom.xml from archetype generation has additional newlines with
> JDK11
> ---
>
> Key: ARCHETYPE-584
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-584
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 3.1.1, 3.1.2
>Reporter: Andre Prata
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This issue does not apply to version 3.1.0, it was introduced in version
> 3.1.1.
>
> In our project, we have the default configuration of the root pom.xml that
> contains lines such as this:
> {code:java}
>
> 11
> Greenwich.RELEASE
>
> {code}
> These lines are still in good shape when added to the jar artifact. However,
> upon generating the project from the archetype, we get the following (note
> also the whitespace on the blank lines hinting at some indentation attempts,
> not just the unexpected line breaks)
> {code:java}
>
>
>
> 11
>
>
> Greenwich.RELEASE
>
>
>
> {code}
> This issue does *not* occur in in child module pom.xml files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1881:
---
Fix Version/s: 3.0.0-M6
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Alexander Kriegisch
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Attachments: Bildschirmfoto von 2021-03-29 21-50-25.png,
> image-2021-02-08-12-07-34-183.png, image-2021-03-26-09-48-11-398.png,
> image-2021-03-26-09-52-36-881.png, image-2021-03-26-18-00-37-889.png,
> image-2021-03-31-11-22-50-682.png, image-2021-03-31-11-38-11-119.png,
> image-2021-03-31-12-31-55-818.png, image-2021-03-31-12-32-41-589.png,
> maven-failsafe-debug-log.txt, screenshot-1.png, screenshot-2.png
>
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{ implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1881.
--
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=dcccd2330e5365a575a2b782854d58b5ed2f98b0
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Alexander Kriegisch
>Assignee: Tibor Digana
>Priority: Major
> Attachments: Bildschirmfoto von 2021-03-29 21-50-25.png,
> image-2021-02-08-12-07-34-183.png, image-2021-03-26-09-48-11-398.png,
> image-2021-03-26-09-52-36-881.png, image-2021-03-26-18-00-37-889.png,
> image-2021-03-31-11-22-50-682.png, image-2021-03-31-11-38-11-119.png,
> image-2021-03-31-12-31-55-818.png, image-2021-03-31-12-32-41-589.png,
> maven-failsafe-debug-log.txt, screenshot-1.png, screenshot-2.png
>
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{ implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (SUREFIRE-1924) Upgrade plexus-java to Version 1.0.7
[ https://issues.apache.org/jira/browse/SUREFIRE-1924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1924. -- Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=773451c6874b02e26854a8763e0889e2126d4f95 > Upgrade plexus-java to Version 1.0.7 > > > Key: SUREFIRE-1924 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1924 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 merged pull request #354: [SUREFIRE-1881] Adds additional debug log and fork connection timeout
Tibor17 merged pull request #354: URL: https://github.com/apache/maven-surefire/pull/354 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (ARCHETYPE-584) Resulting root pom.xml from archetype generation has additional newlines with JDK11
[
https://issues.apache.org/jira/browse/ARCHETYPE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374124#comment-17374124
]
Ruwen Reddig edited comment on ARCHETYPE-584 at 7/3/21, 7:45 PM:
-
[~elharo] this depends on your definition of 'only occur with JDK 11'. I tested
it with Java 11 and 16, and both show the described problem. In contrast to JDK
8, which does not show any problems.
But don't take my word for it. I posted a self contained
[example|https://issues.apache.org/jira/browse/ARCHETYPE-584?focusedCommentId=17008264=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008264]
here in the comments. So you can do further checks easily.
was (Author: newur):
[~elharo] this depends on your definition of 'only occur with JDK 11'. I tested
it with Java 11 and 16, and both show the described problem. In contrast to JDK
8, which does not show any problems.
But don't take my word for it. I posted example here in the comments. So you
can do further checks easily.
> Resulting root pom.xml from archetype generation has additional newlines with
> JDK11
> ---
>
> Key: ARCHETYPE-584
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-584
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 3.1.1, 3.1.2
>Reporter: Andre Prata
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This issue does not apply to version 3.1.0, it was introduced in version
> 3.1.1.
>
> In our project, we have the default configuration of the root pom.xml that
> contains lines such as this:
> {code:java}
>
> 11
> Greenwich.RELEASE
>
> {code}
> These lines are still in good shape when added to the jar artifact. However,
> upon generating the project from the archetype, we get the following (note
> also the whitespace on the blank lines hinting at some indentation attempts,
> not just the unexpected line breaks)
> {code:java}
>
>
>
> 11
>
>
> Greenwich.RELEASE
>
>
>
> {code}
> This issue does *not* occur in in child module pom.xml files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-584) Resulting root pom.xml from archetype generation has additional newlines with JDK11
[
https://issues.apache.org/jira/browse/ARCHETYPE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374124#comment-17374124
]
Ruwen Reddig commented on ARCHETYPE-584:
[~elharo] this depends on your definition of 'only occur with JDK 11'. I tested
it with Java 11 and 16, and both show the described problem. In contrast to JDK
8, which does not show any problems.
But don't take my word for it. I posted example here in the comments. So you
can do further checks easily.
> Resulting root pom.xml from archetype generation has additional newlines with
> JDK11
> ---
>
> Key: ARCHETYPE-584
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-584
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 3.1.1, 3.1.2
>Reporter: Andre Prata
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This issue does not apply to version 3.1.0, it was introduced in version
> 3.1.1.
>
> In our project, we have the default configuration of the root pom.xml that
> contains lines such as this:
> {code:java}
>
> 11
> Greenwich.RELEASE
>
> {code}
> These lines are still in good shape when added to the jar artifact. However,
> upon generating the project from the archetype, we get the following (note
> also the whitespace on the blank lines hinting at some indentation attempts,
> not just the unexpected line breaks)
> {code:java}
>
>
>
> 11
>
>
> Greenwich.RELEASE
>
>
>
> {code}
> This issue does *not* occur in in child module pom.xml files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7181) Make --version support -q
[
https://issues.apache.org/jira/browse/MNG-7181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374121#comment-17374121
]
Hudson commented on MNG-7181:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #180
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/180/
> Make --version support -q
> -
>
> Key: MNG-7181
> URL: https://issues.apache.org/jira/browse/MNG-7181
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> Maven should support the following: {{mvn -v -q}} which will resturn in
> {{}} only.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-584) Resulting root pom.xml from archetype generation has additional newlines with JDK11
[
https://issues.apache.org/jira/browse/ARCHETYPE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374120#comment-17374120
]
Elliotte Rusty Harold commented on ARCHETYPE-584:
-
I suspect JDK11 is a red herring, or does this really only occur with JDK 11?
> Resulting root pom.xml from archetype generation has additional newlines with
> JDK11
> ---
>
> Key: ARCHETYPE-584
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-584
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes
>Affects Versions: 3.1.1, 3.1.2
>Reporter: Andre Prata
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This issue does not apply to version 3.1.0, it was introduced in version
> 3.1.1.
>
> In our project, we have the default configuration of the root pom.xml that
> contains lines such as this:
> {code:java}
>
> 11
> Greenwich.RELEASE
>
> {code}
> These lines are still in good shape when added to the jar artifact. However,
> upon generating the project from the archetype, we get the following (note
> also the whitespace on the blank lines hinting at some indentation attempts,
> not just the unexpected line breaks)
> {code:java}
>
>
>
> 11
>
>
> Greenwich.RELEASE
>
>
>
> {code}
> This issue does *not* occur in in child module pom.xml files.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7181) Make --version support -q
[
https://issues.apache.org/jira/browse/MNG-7181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374119#comment-17374119
]
Hudson commented on MNG-7181:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #42
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/42/
> Make --version support -q
> -
>
> Key: MNG-7181
> URL: https://issues.apache.org/jira/browse/MNG-7181
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> Maven should support the following: {{mvn -v -q}} which will resturn in
> {{}} only.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7180) Make --color option behave more like BSD/GNU grep's --color option
[
https://issues.apache.org/jira/browse/MNG-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374113#comment-17374113
]
Hudson commented on MNG-7180:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #179
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/179/
> Make --color option behave more like BSD/GNU grep's --color option
> --
>
> Key: MNG-7180
> URL: https://issues.apache.org/jira/browse/MNG-7180
> Project: Maven
> Issue Type: Improvement
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> Since MNG-7080 introduced this option we mimic grep's behavior, but not the
> way grep actually does.
> GNU grep: https://git.savannah.gnu.org/cgit/grep.git/tree/src/grep.c#n2751
> FreeBSD grep:
> https://github.com/freebsd/freebsd-src/blob/781c3b51193e5bd99773439192ca68fdfdd9c330/usr.bin/grep/grep.c#L576-L596
> * Both make the value for {{--color}} optional and default to {{auto}}
> * They also accept {{tty}}, {{if-tty}}, {{yes}}, {{force}}, {{none}}, {{no}}
> We should support that approach too: Optional value and privately accepting
> additional values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374109#comment-17374109
]
Alexander Kriegisch edited comment on MSHADE-398 at 7/3/21, 5:53 PM:
-
Like I said, I am not knowlegeable around Invoker, but pretty sure that there
is a setting to tweak it the right way. As for a command line, I am lazy and
simply added {{setup-parent,MSHADE-185}} to the
Invoker config in the POM, then calling {{mvn verify}}. _(Sorry for Jira
striking through what it thinks is a closed issue reference.)_
Update: I run the tests from within the IDE, yes, but still via Maven.
was (Author: kriegaex):
Like I said, I am not knowlegeable around Invoker, but pretty sure that there
is a setting to tweak it the right way. As for a command line, I am lazy and
simply added {{setup-parent,MSHADE-185}} to the
Invoker config in the POM, then calling {{mvn verify}}. _(Sorry for Jira
striking through what it thinks is a closed issue reference.)_
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374109#comment-17374109
]
Alexander Kriegisch edited comment on MSHADE-398 at 7/3/21, 5:49 PM:
-
Like I said, I am not knowlegeable around Invoker, but pretty sure that there
is a setting to tweak it the right way. As for a command line, I am lazy and
simply added {{setup-parent,MSHADE-185}} to the
Invoker config in the POM, then calling {{mvn verify}}. _(Sorry for Jira
striking through what it thinks is a closed issue reference.)_
was (Author: kriegaex):
Like I said, I am not knowlegeable around Invoker, but pretty sure that there
is a setting to tweak it the right way. As for a command line, I am lazy and
simply added {{setup-parent,MSHADE-185}} to the
Invoker config in the POM, then calling {{mvn verify}}.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7115) MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
[
https://issues.apache.org/jira/browse/MNG-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374111#comment-17374111
]
Hudson commented on MNG-7115:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #41
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/41/
> MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
>
>
> Key: MNG-7115
> URL: https://issues.apache.org/jira/browse/MNG-7115
> Project: Maven
> Issue Type: Bug
> Components: core, Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The IT fails reliably because of:
> {noformat}
> [INFO] --- maven-it-plugin-core-extensions-client:0.1:validate-component
> (validate-extensions) @ test ---
> [DEBUG]
> org.apache.maven.its.it-core-extensions:maven-it-plugin-core-extensions-client:jar:0.1
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> [INFO] Downloading from repoman:
> http://localhost:11669/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> 75193 [qtp1198759714-300] WARN org.eclipse.jetty.server.HttpChannel -
> /org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> java.io.FileNotFoundException:
> /var/mosipov/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5771-core-extensions/repo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at
> org.apache.maven.it.HttpServer$HttpServerBuilder$2.stream(HttpServer.java:174)
> at
> org.apache.maven.it.HttpServer$StreamSourceHandler.handle(HttpServer.java:210)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:529)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:267)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
> at java.lang.Thread.run(Thread.java:748)
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.029 s
> [INFO] Finished at: 2021-03-14T14:04:20+01:00
> [INFO]
>
> {noformat}
> The reason is that Maven Core constantly adds Plexus Utils 1.1 dynamically to
> the extension classpath. This annoyance has been fixed for Maven 4 in:
> {noformat}
> commit c61e63032f71c32c4060c8a94ce792bf47824e3c (slawekjaranowski/master)
> Author: Sylwester Lachiewicz
> Date: 2020-07-24T01:59:50+02:00
> [MNG-6965] Extensions suddenly have
> org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
> This closes #367
> {noformat}
> I don't know what the best solution would be here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7180) Make --color option behave more like BSD/GNU grep's --color option
[
https://issues.apache.org/jira/browse/MNG-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374110#comment-17374110
]
Hudson commented on MNG-7180:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #41
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/41/
> Make --color option behave more like BSD/GNU grep's --color option
> --
>
> Key: MNG-7180
> URL: https://issues.apache.org/jira/browse/MNG-7180
> Project: Maven
> Issue Type: Improvement
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> Since MNG-7080 introduced this option we mimic grep's behavior, but not the
> way grep actually does.
> GNU grep: https://git.savannah.gnu.org/cgit/grep.git/tree/src/grep.c#n2751
> FreeBSD grep:
> https://github.com/freebsd/freebsd-src/blob/781c3b51193e5bd99773439192ca68fdfdd9c330/usr.bin/grep/grep.c#L576-L596
> * Both make the value for {{--color}} optional and default to {{auto}}
> * They also accept {{tty}}, {{if-tty}}, {{yes}}, {{force}}, {{none}}, {{no}}
> We should support that approach too: Optional value and privately accepting
> additional values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374109#comment-17374109
]
Alexander Kriegisch commented on MSHADE-398:
Like I said, I am not knowlegeable around Invoker, but pretty sure that there
is a setting to tweak it the right way. As for a command line, I am lazy and
simply added {{setup-parent,MSHADE-185}} to the
Invoker config in the POM, then calling {{mvn verify}}.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374108#comment-17374108
]
Michael Osipov commented on MSHADE-398:
---
Take your time. All JAVA_HOME magic happens in the mvn booter script. Maybe
Invoker can be smarter here.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374106#comment-17374106
]
Michael Osipov edited comment on MSHADE-398 at 7/3/21, 5:45 PM:
Generally, we don't recommend to run ITs in the IDE. I sometimes have failing
tests in Eclipse which work in the shell.
Can you exactly describe your command line environment for me how I can
reproduce this?
was (Author: michael-o):
Generally, we don't recommend to run ITs in the ITs. I sometimes have failing
tests in Eclipse which work in the shell.
Can you exactly describe your command line environment for me how I can
reproduce this?
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374107#comment-17374107
]
Alexander Kriegisch edited comment on MSHADE-398 at 7/3/21, 5:44 PM:
-
Ah yes, there it is. Cool, thanks. It is somewhat difficult to search on a page
on my small mobile phone (Samsung S7), lots of scrolling. Not to mention
editing typos on JIRA. Sorry, too lazy to get out of bed at 00.43.
was (Author: kriegaex):
Ah yes, there it is. Cool, thanks. It is somewhat difficult to search on a page
on my small mobile phone (Samsung S7), lots of scrolling. Not to mention
editing types on JIRA. Sorry, too lazy to get out of bed at 00.43.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374107#comment-17374107
]
Alexander Kriegisch commented on MSHADE-398:
Ah yes, there it is. Cool, thanks. It is somewhat difficult to search on a page
on my small mobile phone (Samsung S7), lots of scrolling. Not to mention
editing types on JIRA. Sorry, too lazy to get out of bed at 00.43.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374106#comment-17374106
]
Michael Osipov commented on MSHADE-398:
---
Generally, we don't recommend to run ITs in the ITs. I sometimes have failing
tests in Eclipse which work in the shell.
Can you exactly describe your command line environment for me how I can
reproduce this?
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374105#comment-17374105
]
Michael Osipov commented on MSHADE-398:
---
It is documented:
https://maven.apache.org/plugins/maven-invoker-plugin/examples/selector-conditions.html
Let me test too.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6913) Use Java 8
[ https://issues.apache.org/jira/browse/MNG-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374102#comment-17374102 ] Michael Osipov commented on MNG-6913: - I had to revert one file to Java 7 because Maven 3.8.x was not able to run tests with Java 7. For as long as we support Maven 3.x we cannot move tests to Java 8. > Use Java 8 > -- > > Key: MNG-6913 > URL: https://issues.apache.org/jira/browse/MNG-6913 > Project: Maven > Issue Type: Task > Components: Integration Tests >Reporter: Maarten Mulders >Priority: Trivial > > It would be great if we could use Java 8 constructs and API's in the > Integration Test project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374099#comment-17374099
]
Alexander Kriegisch edited comment on MSHADE-398 at 7/3/21, 5:29 PM:
-
Attention, {{9-}} is not the same as {{9+}}. This is cryptic and undocumented,
I also had to find out by experimenting. The documentation shows examples, but
never explains their meanings, maybe assuming they would speak for themselves,
which obviously they don't, if even a Maven guru like you does not know. Same
goes for tests: no explanation.
Of course {{java.home}} is not the same as {{JAVA_HOME}} and can be overridden,
but defaults to it. I recommend to simply give it a try, running the test,
trying to reproduce what I described. I should not have to convince anyone, the
facts speak for themselves.
was (Author: kriegaex):
Attention, {{9-}} is not the same as {{9+}}. This is cryptic and undocumented,
I also had to find out by experimenting. The documentation shows examples, but
never explains their meanings, maybe assuming they would speak for themselves,
which obviously they don't, if even a Maven guru like you does not know. Same
goes for tests: no explanation.
Of course {{java.home}} is not the same as {{JAVA_HOME}} and can be overridden,
but defaults to it. I recommend to simply give it a try, running the test,
trying to reproduce what I described? I should not have to convince anyone, the
facts speak for themselves.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374099#comment-17374099
]
Alexander Kriegisch edited comment on MSHADE-398 at 7/3/21, 5:28 PM:
-
Attention, {{9-}} is not the same as {{9+}}. This is cryptic and undocumented,
I also had to find out by experimenting. The documentation shows examples, but
never explains their meanings, maybe assuming they would speak for themselves,
which obviously they don't, if even a Maven guru like you does not know. Same
goes for tests: no explanation.
Of course {{java.home}} is not the same as {{JAVA_HOME}} and can be overridden,
but defaults to it. I recommend to simply give it a try, running the test,
trying to reproduce what I described? I should not have to convince anyone, the
facts speak for themselves.
was (Author: kriegaex):
Attention, {{9-}} is not the same as {{9+}}. This is cryptic and undocumented,
I also had to find out by experimenting. The documentation shows examples, but
never explains their meanings, maybe assuming they would speak for themselves,
which obviously they don't, if even a Maven guru like you does not know. Same
goes for tests: no explanation.
Of course {{java.home}} is not the same as {{JAVA_HOME}} and can be overridden,
but defaults to it. I recommend to simply give it a try, simply running the
test, trying to reproduce what I described? I should not have to convince
anyone, the facts speak for themselves.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374099#comment-17374099
]
Alexander Kriegisch edited comment on MSHADE-398 at 7/3/21, 5:27 PM:
-
Attention, {{9-}} is not the same as {{9+}}. This is cryptic and undocumented,
I also had to find out by experimenting. The documentation shows examples, but
never explains their meanings, maybe assuming they would speak for themselves,
which obviously they don't, if even a Maven guru like you does not know. Same
goes for tests: no explanation.
Of course {{java.home}} is not the same as {{JAVA_HOME}} and can be overridden,
but defaults to it. I recommend to simply give it a try, simply running the
test, trying to reproduce what I described? I should not have to convince
anyone, the facts speak for themselves.
was (Author: kriegaex):
Attention, {{9-}} is not the same as {{9+}}. This is cryptic and undocumented,
I also had to find out by experimenting. The documentation shows examples, but
never explains their meanings, obviously assuming they would speak for
themselves, which obviously they don't, if even a Maven guru like you does not
know. Same goes for tests: no explanation.
Of course {{java.home}} is not the same as {{JAVA_HOME}} and can be overridden,
but defaults to it. I recommend to simply give it a try, simply running the
test, trying to reproduce what I described? I should not have to convince
anyone, the facts speak for themselves.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374099#comment-17374099
]
Alexander Kriegisch edited comment on MSHADE-398 at 7/3/21, 5:26 PM:
-
Attention, {{9-}} is not the same as {{9+}}. This is cryptic and undocumented,
I also had to find out by experimenting. The documentation shows examples, but
never explains their meanings, obviously assuming they would speak for
themselves, which obviously they don't, if even a Maven guru like you does not
know. Same goes for tests: no explanation.
Of course {{java.home}} is not the same as {{JAVA_HOME}} and can be overridden,
but defaults to it. I recommend to simply give it a try, simply running the
test, trying to reproduce what I described? I should not have to convince
anyone, the facts speak for themselves.
was (Author: kriegaex):
Attention, {{9-}} is not the same as {{9+}}. This is cryptic and undocumented,
I also had to find out by experimenting. The documentation shows examples, but
never explains their meanings, obviously assuming they would speak for
themselves, which obviously they don't, if even a Maven guru like you does not
know. Same goes for tests: no explanation.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374099#comment-17374099
]
Alexander Kriegisch commented on MSHADE-398:
Attention, {{9-}} is not the same as {{9+}}. This is cryptic and undocumented,
I also had to find out by experimenting. The documentation shows examples, but
never explains their meanings, obviously assuming they would speak for
themselves, which obviously they don't, if even a Maven guru like you does not
know. Same goes for tests: no explanation.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-7181) Make --version support -q
[
https://issues.apache.org/jira/browse/MNG-7181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7181.
---
Resolution: Fixed
Fixed with
[1fc605dd69f99e91e0685a4f4ba279d2fd2eed21|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=1fc605dd69f99e91e0685a4f4ba279d2fd2eed21]
and
[7a8acdd8e66de81b4f7f918905976191837bf147|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=7b355f72235c0bd26b872601b38a493ed1cc518b]
for {{maven-3.8.x}} branch.
> Make --version support -q
> -
>
> Key: MNG-7181
> URL: https://issues.apache.org/jira/browse/MNG-7181
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.8.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> Maven should support the following: {{mvn -v -q}} which will resturn in
> {{}} only.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-7181) Make --version support -q
Michael Osipov created MNG-7181:
---
Summary: Make --version support -q
Key: MNG-7181
URL: https://issues.apache.org/jira/browse/MNG-7181
Project: Maven
Issue Type: Improvement
Components: Command Line
Affects Versions: 3.8.1
Reporter: Michael Osipov
Assignee: Michael Osipov
Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
Maven should support the following: {{mvn -v -q}} which will resturn in
{{}} only.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-7180) Make --color option behave more like BSD/GNU grep's --color option
[
https://issues.apache.org/jira/browse/MNG-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7180.
---
Fix Version/s: 4.0.0-alpha-1
4.0.0
3.8.2
Resolution: Fixed
Fixed with
[a70828c7376dc8d07a2800e035271004ba9222e8|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=a70828c7376dc8d07a2800e035271004ba9222e8]
and
[7b355f72235c0bd26b872601b38a493ed1cc518b|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=7b355f72235c0bd26b872601b38a493ed1cc518b]
for {{maven-3.8.x}} branch.
> Make --color option behave more like BSD/GNU grep's --color option
> --
>
> Key: MNG-7180
> URL: https://issues.apache.org/jira/browse/MNG-7180
> Project: Maven
> Issue Type: Improvement
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> Since MNG-7080 introduced this option we mimic grep's behavior, but not the
> way grep actually does.
> GNU grep: https://git.savannah.gnu.org/cgit/grep.git/tree/src/grep.c#n2751
> FreeBSD grep:
> https://github.com/freebsd/freebsd-src/blob/781c3b51193e5bd99773439192ca68fdfdd9c330/usr.bin/grep/grep.c#L576-L596
> * Both make the value for {{--color}} optional and default to {{auto}}
> * They also accept {{tty}}, {{if-tty}}, {{yes}}, {{force}}, {{none}}, {{no}}
> We should support that approach too: Optional value and privately accepting
> additional values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374084#comment-17374084
]
Michael Osipov commented on MSHADE-398:
---
I read that but still, {{java.home}} isn't the same as {{JAVA_HOME}}. The
[https://github.com/apache/maven-shade-plugin/blob/master/src/it/projects/MSHADE-185/invoker.properties#L18|{{invoker.properties}}]
say Java 9+. I am confused.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374076#comment-17374076
]
Alexander Kriegisch commented on MSHADE-398:
The test is [Java 8
max.|https://github.com/apache/maven-shade-plugin/blob/master/src/it/projects/MSHADE-185/invoker.properties]
already, that is not the problem. The problem ist what I described.
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-7180) Make --color option behave more like BSD/GNU grep's --color option
[
https://issues.apache.org/jira/browse/MNG-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7180:
---
Assignee: Michael Osipov
> Make --color option behave more like BSD/GNU grep's --color option
> --
>
> Key: MNG-7180
> URL: https://issues.apache.org/jira/browse/MNG-7180
> Project: Maven
> Issue Type: Improvement
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Since MNG-7080 introduced this option we mimic grep's behavior, but not the
> way grep actually does.
> GNU grep: https://git.savannah.gnu.org/cgit/grep.git/tree/src/grep.c#n2751
> FreeBSD grep:
> https://github.com/freebsd/freebsd-src/blob/781c3b51193e5bd99773439192ca68fdfdd9c330/usr.bin/grep/grep.c#L576-L596
> * Both make the value for {{--color}} optional and default to {{auto}}
> * They also accept {{tty}}, {{if-tty}}, {{yes}}, {{force}}, {{none}}, {{no}}
> We should support that approach too: Optional value and privately accepting
> additional values.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7135) maven crashes with jdk 16
[ https://issues.apache.org/jira/browse/MNG-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374072#comment-17374072 ] Sylwester Lachiewicz commented on MNG-7135: --- Debian have its own distribution of Apache Maven with special customisation (patching our sources). In this case to fix issue, they changed Guice dependency back to orginal no-aop version. > maven crashes with jdk 16 > - > > Key: MNG-7135 > URL: https://issues.apache.org/jira/browse/MNG-7135 > Project: Maven > Issue Type: Bug > Environment: Linux Mint 20.1 >Reporter: J. K. Singer >Priority: Major > > Maven does not work with JDK 16, still works with JDK 15, albeit with warning > > export JAVA_HOME=/opt/jdk-15 > mvn archetype:generate -DarchetypeArtifactId=maven-archetype-quickstart > -DarchetypeVersion=1.4 -DgroupId="com.example" -DartifactId="FailDemo" > -Dpackage="com.example.FailDemo" -DinteractiveMode=false > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > com.google.inject.internal.cglib.core.$ReflectUtils$1 > (file:/usr/share/maven/lib/guice.jar) to method > java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) > export JAVA_HOME=/opt/jdk-16 > mvn archetype:generate -DarchetypeArtifactId=maven-archetype-quickstart > -DarchetypeVersion=1.4 -DgroupId="com.example" -DartifactId="FailDemo" > -Dpackage="com.example.FailDemo" -DinteractiveMode=false > [ERROR] Error executing Maven. > [ERROR] java.lang.IllegalStateException: Unable to load cache item > [ERROR] Caused by: Unable to load cache item > [ERROR] Caused by: Could not initialize class > com.google.inject.internal.cglib.core.$MethodWrapper -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7161) Error thrown during uninstalling of JAnsi
[
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7161:
Fix Version/s: 4.0.x-candidate
3.8.x-candidate
> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> Our integration tests stopped working after we started to test with a Maven
> {{4.0.0-alpha-1}} nightly which included this commit:
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are
> being upgraded. When we then run our integration tests we get the following
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
> at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
> at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>
> We debugged this and [these
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
> in JAnsi introduced in the above upgraded version, is the source of the
> exception. The NPE is caused because the {{out}} reference is {{null}} at the
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled
> because we use the Plexus interactivity library which [disposes the
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
> on the tear down of Plexus, in which the {{System.out}} reference will be
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi
> will be [initialized
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
> the Plexus container). This happens
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
> so before JAnsi will be uninstalled in
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
> 1. Report this to JAnsi such that they catch this valid use case and do not
> throw as this worked without any exceptions in older versions.
> 2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and
> swallow them, as if it can't uninstall it, then Maven itself is not capable
> of fixing this state either. This is already done in a similar way
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
> for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use
> cases as there are other extensions/plugin out there which also retrieve a
> reference for the system output streams and therefore they would fail with
> Maven 4.0.0. This would also make this part future proof, as when there are
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that this gets fixed there as
> well.
>
> What are your opinions on that?
--
This
[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi
[
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374037#comment-17374037
]
Michael Osipov commented on MNG-7161:
-
[~Brand], can you meanwhile provide a PR for this?
> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
>
> Our integration tests stopped working after we started to test with a Maven
> {{4.0.0-alpha-1}} nightly which included this commit:
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are
> being upgraded. When we then run our integration tests we get the following
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
> at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
> at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>
> We debugged this and [these
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
> in JAnsi introduced in the above upgraded version, is the source of the
> exception. The NPE is caused because the {{out}} reference is {{null}} at the
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled
> because we use the Plexus interactivity library which [disposes the
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
> on the tear down of Plexus, in which the {{System.out}} reference will be
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi
> will be [initialized
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
> the Plexus container). This happens
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
> so before JAnsi will be uninstalled in
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
> 1. Report this to JAnsi such that they catch this valid use case and do not
> throw as this worked without any exceptions in older versions.
> 2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and
> swallow them, as if it can't uninstall it, then Maven itself is not capable
> of fixing this state either. This is already done in a similar way
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
> for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use
> cases as there are other extensions/plugin out there which also retrieve a
> reference for the system output streams and therefore they would fail with
> Maven 4.0.0. This would also make this part future proof, as when there are
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that this gets fixed there as
> well.
>
> What are your opinions on that?
--
This message was sent by Atlassian Jira
[jira] [Closed] (MNG-7135) maven crashes with jdk 16
[ https://issues.apache.org/jira/browse/MNG-7135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7135. --- Fix Version/s: (was: wontfix-candidate) (was: waiting-for-feedback) Resolution: Cannot Reproduce Tried several variations with 3.8.x and master. I cannot produce with Java 8, 15, and 16. > maven crashes with jdk 16 > - > > Key: MNG-7135 > URL: https://issues.apache.org/jira/browse/MNG-7135 > Project: Maven > Issue Type: Bug > Environment: Linux Mint 20.1 >Reporter: J. K. Singer >Priority: Major > > Maven does not work with JDK 16, still works with JDK 15, albeit with warning > > export JAVA_HOME=/opt/jdk-15 > mvn archetype:generate -DarchetypeArtifactId=maven-archetype-quickstart > -DarchetypeVersion=1.4 -DgroupId="com.example" -DartifactId="FailDemo" > -Dpackage="com.example.FailDemo" -DinteractiveMode=false > WARNING: An illegal reflective access operation has occurred > WARNING: Illegal reflective access by > com.google.inject.internal.cglib.core.$ReflectUtils$1 > (file:/usr/share/maven/lib/guice.jar) to method > java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) > export JAVA_HOME=/opt/jdk-16 > mvn archetype:generate -DarchetypeArtifactId=maven-archetype-quickstart > -DarchetypeVersion=1.4 -DgroupId="com.example" -DartifactId="FailDemo" > -Dpackage="com.example.FailDemo" -DinteractiveMode=false > [ERROR] Error executing Maven. > [ERROR] java.lang.IllegalStateException: Unable to load cache item > [ERROR] Caused by: Unable to load cache item > [ERROR] Caused by: Could not initialize class > com.google.inject.internal.cglib.core.$MethodWrapper -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-7161) Error thrown during uninstalling of JAnsi
[
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362262#comment-17362262
]
Michael Osipov edited comment on MNG-7161 at 7/3/21, 2:12 PM:
--
[~Brand], to be honest. I cannot judge here. [~gnodet] is the expert here. I
will leave the decision up to him.
was (Author: michael-o):
[~Brand], to be honest. I cannot judge here. [~gnodet] is the expert here. I
will the decision up to him.
> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
>
> Our integration tests stopped working after we started to test with a Maven
> {{4.0.0-alpha-1}} nightly which included this commit:
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are
> being upgraded. When we then run our integration tests we get the following
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
> at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
> at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>
> We debugged this and [these
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
> in JAnsi introduced in the above upgraded version, is the source of the
> exception. The NPE is caused because the {{out}} reference is {{null}} at the
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled
> because we use the Plexus interactivity library which [disposes the
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
> on the tear down of Plexus, in which the {{System.out}} reference will be
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi
> will be [initialized
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
> the Plexus container). This happens
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
> so before JAnsi will be uninstalled in
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
> 1. Report this to JAnsi such that they catch this valid use case and do not
> throw as this worked without any exceptions in older versions.
> 2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and
> swallow them, as if it can't uninstall it, then Maven itself is not capable
> of fixing this state either. This is already done in a similar way
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
> for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use
> cases as there are other extensions/plugin out there which also retrieve a
> reference for the system output streams and therefore they would fail with
> Maven 4.0.0. This would also make this part future proof, as when there are
[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi
[
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374035#comment-17374035
]
Michael Osipov commented on MNG-7161:
-
[~gnodet], can you provide some insight? This is a blocker.
> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
>
> Our integration tests stopped working after we started to test with a Maven
> {{4.0.0-alpha-1}} nightly which included this commit:
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are
> being upgraded. When we then run our integration tests we get the following
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
> at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
> at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>
> We debugged this and [these
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
> in JAnsi introduced in the above upgraded version, is the source of the
> exception. The NPE is caused because the {{out}} reference is {{null}} at the
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled
> because we use the Plexus interactivity library which [disposes the
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
> on the tear down of Plexus, in which the {{System.out}} reference will be
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi
> will be [initialized
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
> the Plexus container). This happens
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
> so before JAnsi will be uninstalled in
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
> 1. Report this to JAnsi such that they catch this valid use case and do not
> throw as this worked without any exceptions in older versions.
> 2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and
> swallow them, as if it can't uninstall it, then Maven itself is not capable
> of fixing this state either. This is already done in a similar way
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
> for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use
> cases as there are other extensions/plugin out there which also retrieve a
> reference for the system output streams and therefore they would fail with
> Maven 4.0.0. This would also make this part future proof, as when there are
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that this gets fixed there as
> well.
>
> What are your opinions on that?
--
This message was sent by
[jira] [Updated] (MNG-7161) Error thrown during uninstalling of JAnsi
[
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7161:
Affects Version/s: 3.8.2
> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
>
> Our integration tests stopped working after we started to test with a Maven
> {{4.0.0-alpha-1}} nightly which included this commit:
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are
> being upgraded. When we then run our integration tests we get the following
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
> at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
> at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>
> We debugged this and [these
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
> in JAnsi introduced in the above upgraded version, is the source of the
> exception. The NPE is caused because the {{out}} reference is {{null}} at the
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled
> because we use the Plexus interactivity library which [disposes the
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
> on the tear down of Plexus, in which the {{System.out}} reference will be
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi
> will be [initialized
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
> the Plexus container). This happens
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
> so before JAnsi will be uninstalled in
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
> 1. Report this to JAnsi such that they catch this valid use case and do not
> throw as this worked without any exceptions in older versions.
> 2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and
> swallow them, as if it can't uninstall it, then Maven itself is not capable
> of fixing this state either. This is already done in a similar way
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
> for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use
> cases as there are other extensions/plugin out there which also retrieve a
> reference for the system output streams and therefore they would fail with
> Maven 4.0.0. This would also make this part future proof, as when there are
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that this gets fixed there as
> well.
>
> What are your opinions on that?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7161) Error thrown during uninstalling of JAnsi
[
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7161:
Affects Version/s: (was: 4.0.x-candidate)
3.8.1
> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.1, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
>
> Our integration tests stopped working after we started to test with a Maven
> {{4.0.0-alpha-1}} nightly which included this commit:
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are
> being upgraded. When we then run our integration tests we get the following
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
> at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
> at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>
> We debugged this and [these
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
> in JAnsi introduced in the above upgraded version, is the source of the
> exception. The NPE is caused because the {{out}} reference is {{null}} at the
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled
> because we use the Plexus interactivity library which [disposes the
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
> on the tear down of Plexus, in which the {{System.out}} reference will be
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi
> will be [initialized
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
> the Plexus container). This happens
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
> so before JAnsi will be uninstalled in
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
> 1. Report this to JAnsi such that they catch this valid use case and do not
> throw as this worked without any exceptions in older versions.
> 2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and
> swallow them, as if it can't uninstall it, then Maven itself is not capable
> of fixing this state either. This is already done in a similar way
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
> for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use
> cases as there are other extensions/plugin out there which also retrieve a
> reference for the system output streams and therefore they would fail with
> Maven 4.0.0. This would also make this part future proof, as when there are
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that this gets fixed there as
> well.
>
> What are your opinions on that?
--
This message was sent by Atlassian Jira
[jira] [Updated] (MNG-7161) Error thrown during uninstalling of JAnsi
[
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7161:
Affects Version/s: (was: 3.8.1)
> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
>
> Our integration tests stopped working after we started to test with a Maven
> {{4.0.0-alpha-1}} nightly which included this commit:
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are
> being upgraded. When we then run our integration tests we get the following
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
> at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
> at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
> at
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>
> We debugged this and [these
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
> in JAnsi introduced in the above upgraded version, is the source of the
> exception. The NPE is caused because the {{out}} reference is {{null}} at the
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled
> because we use the Plexus interactivity library which [disposes the
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
> on the tear down of Plexus, in which the {{System.out}} reference will be
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi
> will be [initialized
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
> the Plexus container). This happens
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
> so before JAnsi will be uninstalled in
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
> 1. Report this to JAnsi such that they catch this valid use case and do not
> throw as this worked without any exceptions in older versions.
> 2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and
> swallow them, as if it can't uninstall it, then Maven itself is not capable
> of fixing this state either. This is already done in a similar way
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
> for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use
> cases as there are other extensions/plugin out there which also retrieve a
> reference for the system output streams and therefore they would fail with
> Maven 4.0.0. This would also make this part future proof, as when there are
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that this gets fixed there as
> well.
>
> What are your opinions on that?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MINVOKER-258) Normalize line endings
[ https://issues.apache.org/jira/browse/MINVOKER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374027#comment-17374027 ] Hudson commented on MINVOKER-258: - Build succeeded in Jenkins: Maven » Maven TLP » maven-invoker-plugin » master #49 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-invoker-plugin/job/master/49/ > Normalize line endings > -- > > Key: MINVOKER-258 > URL: https://issues.apache.org/jira/browse/MINVOKER-258 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Slawomir Jaranowski >Assignee: Michael Osipov >Priority: Trivial > Fix For: 3.2.3 > > > In project some files have CRLF and some other LF. > What kind should be? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6984) maven concurrent builds ignore synchronized in mojo execute-method
[ https://issues.apache.org/jira/browse/MNG-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6984. --- Fix Version/s: (was: wontfix-candidate) (was: waiting-for-feedback) Resolution: Incomplete No reaction for nine months. > maven concurrent builds ignore synchronized in mojo execute-method > -- > > Key: MNG-6984 > URL: https://issues.apache.org/jira/browse/MNG-6984 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.0, 3.6.3 >Reporter: Thomas Lörcher >Priority: Critical > > I have written a custom maven-Mojo. > Since libraries used in this mojo are not thread-safe, i followed the guide > [https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3] > to avoid parallel executions of the code. > Doesnt seem to work though. > I tried to use other approaches like semaphors or synchronized functions, > maven does execute the code snippets in parallel. It seems to me that every > mvn module will get build in an own process. > Build started using > mvn clean package -T1C -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MINVOKER-258) Normalize line endings
[ https://issues.apache.org/jira/browse/MINVOKER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MINVOKER-258. --- Resolution: Fixed Fixed with [6f4dc0bdf60682e2322b2dec3bd914eb0584857e|https://gitbox.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=6f4dc0bdf60682e2322b2dec3bd914eb0584857e]. > Normalize line endings > -- > > Key: MINVOKER-258 > URL: https://issues.apache.org/jira/browse/MINVOKER-258 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Slawomir Jaranowski >Assignee: Michael Osipov >Priority: Trivial > Fix For: 3.2.3 > > > In project some files have CRLF and some other LF. > What kind should be? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-invoker-plugin] asfgit closed pull request #36: [MINVOKER-258] normalize the line endings code to LF
asfgit closed pull request #36: URL: https://github.com/apache/maven-invoker-plugin/pull/36 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
[
https://issues.apache.org/jira/browse/MSHADE-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374008#comment-17374008
]
Michael Osipov commented on MSHADE-398:
---
Nice find. I don't know why this test requires {{tools.jar}}, but I would
rather set Java 8 max for this test. Alternatively, this tests needs to use
toolchains. WDYT?
> MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
> --
>
> Key: MSHADE-398
> URL: https://issues.apache.org/jira/browse/MSHADE-398
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.4
>Reporter: Alexander Kriegisch
>Priority: Major
>
> Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on
> JDK <= 8. The CI builds on GitHub are fine, because they run on JDK 8 and
> also set {{JAVA_HOME}} accordingly. But on many systems, e.g. my developer
> workstation, {{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those
> JDKs do not contain {{tools.jar}}, of course. So far, so good.
> Now it is perfectly normal that a developer starts an IDE and from there
> loads her project and runs the Maven Shade build, selecting a different JDK
> to run Maven on, because for example they want to run all ITs. The same can
> happen in a console, if the developer starts Maven on a different Java
> executable than the one pointed to by {{JAVA_HOME}}. In both cases, the test
> fails, because the POM contains a system dependency on {{tools.jar}}.
> First the Maven build started by Invoker fails:
> {code:java}
> [ERROR] Failed to execute goal on project system-dep: Could not resolve
> dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
> find artifact com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project system-dep: Could not resolve dependencies for project
> test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
> com.sun:tools:jar:1.6 at specified path c:\Program
> Files\Java\jdk-16\..\lib\tools.jar
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
> (LifecycleDependencyResolver.java:269)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
> (LifecycleDependencyResolver.java:147)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
> (MojoExecutor.java:248)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:202)
> {code}
> Then later of course also the post-run verify step fails, because no
> dependency-reduced POM was created due to the fact that the build failed
> quickly:
> {code:java}
> Running post-build script:
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
> Assertion failed:
> assert pomFile.isFile()
>| |
>| false
>
> C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
> {code}
> The solution would be to make sure that Invoker sets JAVA_HOME according to
> the JDK actually used for running the test. I have not investigated how to do
> that, but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-archetype] newur commented on a change in pull request #35: [ARCHETYPE-584] fix indentation in root pom.xml
newur commented on a change in pull request #35: URL: https://github.com/apache/maven-archetype/pull/35#discussion_r663360146 ## File path: archetype-common/src/main/java/org/apache/maven/archetype/common/util/PomUtils.java ## @@ -79,6 +83,13 @@ public static boolean addNewModule( String artifactId, Reader fileReader, Writer dbf.setXIncludeAware( false ); dbf.setExpandEntityReferences( false ); +InputStream inputStream = PomUtils.class.getClassLoader().getResourceAsStream( "maven-4.0.0.xsd" ); Review comment: Please check the [example](https://issues.apache.org/jira/browse/ARCHETYPE-584?focusedCommentId=17008264=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008264) I provided. When you run it, you will see that without the schema the output is not as expected. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archetype] newur commented on a change in pull request #35: [ARCHETYPE-584] fix indentation in root pom.xml
newur commented on a change in pull request #35: URL: https://github.com/apache/maven-archetype/pull/35#discussion_r663360146 ## File path: archetype-common/src/main/java/org/apache/maven/archetype/common/util/PomUtils.java ## @@ -79,6 +83,13 @@ public static boolean addNewModule( String artifactId, Reader fileReader, Writer dbf.setXIncludeAware( false ); dbf.setExpandEntityReferences( false ); +InputStream inputStream = PomUtils.class.getClassLoader().getResourceAsStream( "maven-4.0.0.xsd" ); Review comment: Please check the [example](https://issues.apache.org/jira/browse/ARCHETYPE-584?focusedCommentId=17008264=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17008264) I provided. You will see that without the schema the output is not as expected. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archetype] elharo commented on a change in pull request #35: [ARCHETYPE-584] fix indentation in root pom.xml
elharo commented on a change in pull request #35: URL: https://github.com/apache/maven-archetype/pull/35#discussion_r663359466 ## File path: archetype-common/src/main/java/org/apache/maven/archetype/common/util/PomUtils.java ## @@ -79,6 +83,13 @@ public static boolean addNewModule( String artifactId, Reader fileReader, Writer dbf.setXIncludeAware( false ); dbf.setExpandEntityReferences( false ); +InputStream inputStream = PomUtils.class.getClassLoader().getResourceAsStream( "maven-4.0.0.xsd" ); Review comment: My guess is that you don't need the schema to fix this bug. In fact, you probably only need `setIgnoringElementContentWhitespace` though `setNamespaceAware( true )` is always a good idea. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archetype] newur commented on a change in pull request #35: [ARCHETYPE-584] fix indentation in root pom.xml
newur commented on a change in pull request #35: URL: https://github.com/apache/maven-archetype/pull/35#discussion_r663358331 ## File path: archetype-common/src/main/java/org/apache/maven/archetype/common/util/PomUtils.java ## @@ -79,6 +83,13 @@ public static boolean addNewModule( String artifactId, Reader fileReader, Writer dbf.setXIncludeAware( false ); dbf.setExpandEntityReferences( false ); +InputStream inputStream = PomUtils.class.getClassLoader().getResourceAsStream( "maven-4.0.0.xsd" ); Review comment: Please see my minimal, reproducible example here https://issues.apache.org/jira/browse/ARCHETYPE-584?focusedCommentId=17008264=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17008264 I investigated this 1.5 years ago and cannot remember the details why it only worked this way. However, I am pretty sure that I did not dive into the implementation details of `DocumentBuilderFactory`, which is fed with the `schema`, so not sure if I would have been able to explain it very deep back then. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archetype] newur commented on a change in pull request #35: [ARCHETYPE-584] fix indentation in root pom.xml
newur commented on a change in pull request #35: URL: https://github.com/apache/maven-archetype/pull/35#discussion_r663358487 ## File path: archetype-common/src/main/resources/maven-4.0.0.xsd ## @@ -0,0 +1,2246 @@ + Review comment: Feel free to point me to location of the `xsd` in maven core or any other way to load it and I happily update the PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archetype] newur commented on a change in pull request #35: [ARCHETYPE-584] fix indentation in root pom.xml
newur commented on a change in pull request #35: URL: https://github.com/apache/maven-archetype/pull/35#discussion_r663358331 ## File path: archetype-common/src/main/java/org/apache/maven/archetype/common/util/PomUtils.java ## @@ -79,6 +83,13 @@ public static boolean addNewModule( String artifactId, Reader fileReader, Writer dbf.setXIncludeAware( false ); dbf.setExpandEntityReferences( false ); +InputStream inputStream = PomUtils.class.getClassLoader().getResourceAsStream( "maven-4.0.0.xsd" ); Review comment: Please see my minimal, reproducible example here https://issues.apache.org/jira/browse/ARCHETYPE-584?focusedCommentId=17008264=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17008264 I investigated this 1.5 years ago and can not remember the details why it only worked this way. However, I am pretty sure that I did not dive into the implementation details of `DocumentBuilderFactory`, which is fed with the `schema`, so not sure if I would have been able to explain it very deep back then. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1659) Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
[
https://issues.apache.org/jira/browse/SUREFIRE-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374005#comment-17374005
]
Tibor Digana edited comment on SUREFIRE-1659 at 7/3/21, 12:01 PM:
--
[~srdo]
[~kalgon]
[~EPadronU]
[~rkraneis]
I am still having the problem with Log4J Jul. There is no problem with SLF4J.
The source code in Junit5 is still the same.
{code:java}
class LauncherConfigurationParameters implements ConfigurationParameters {
private static final Logger logger =
LoggerFactory.getLogger(LauncherConfigurationParameters.class);
{code}
The integration test reports an error:
{noformat}
Error: Failures:
Error:JUnitPlatformStreamCorruptionIT.warningIsNotEmittedWithJulToLog4j:88
expecting empty, but was:<['[WARNING] Corrupted channel by directly writing to
native stream in forked JVM 1. See FAQ web page and the dump file
D:\a\maven-surefire\maven-surefire\surefire-its\target\JUnitPlatformStreamCorruptionIT_warningIsNotEmittedWithJulToLog4j\target\surefire-reports\2021-07-03T10-47-26_367-jvmRun1.dumpstream']>
{noformat}
The Ifact that the SLF4J has no problem means that JUL implementation has got a
reference to {{System.out}} too fast on class loading and not lazily when the
first log message is fired. I guess SLF4J is implemented with totally lazy
singleton or something.
That's the reason why our CI failed in
https://github.com/apache/maven-surefire/pull/354/commits/1fc1106cea5da44c213fb6d7934c8997b8f3616d
Our assertion statements listened to the old message and the new one. That's
why we did not see this problem but the users did it.
This is the detail from our integration test:
{code:xml}
junit-platform-with-jul-to-log4j
org.apache.maven.plugins
maven-surefire-plugin
${surefire.version}
org.apache.logging.log4j.jul.LogManager
org.apache.logging.log4j
log4j-core
2.13.1
org.apache.logging.log4j
log4j-jul
2.13.1
{code}
was (Author: tibor17):
[~srdo]
[~kalgon]
[~EPadronU]
[~rkraneis]
I am still having the problem with Log4J Jul. There is no problem with SLF4J.
The source code in Junit5 is still the same.
{code:java}
class LauncherConfigurationParameters implements ConfigurationParameters {
private static final Logger logger =
LoggerFactory.getLogger(LauncherConfigurationParameters.class);
{code}
The integration test reports an error:
{noformat}
Error: Failures:
Error:JUnitPlatformStreamCorruptionIT.warningIsNotEmittedWithJulToLog4j:88
expecting empty, but was:<['[WARNING] Corrupted channel by directly writing to
native stream in forked JVM 1. See FAQ web page and the dump file
D:\a\maven-surefire\maven-surefire\surefire-its\target\JUnitPlatformStreamCorruptionIT_warningIsNotEmittedWithJulToLog4j\target\surefire-reports\2021-07-03T10-47-26_367-jvmRun1.dumpstream']>
{noformat}
The Ifact that the SLF4J has no problem means that JUL implementation has got a
reference to {{System.out}} too fast on class loading and not lazily when the
first log message is fired. I guess SLF4J is implemented with totally lazy
singleton or something.
That's the reason why our CI failed in
https://github.com/apache/maven-surefire/pull/354/commits/1fc1106cea5da44c213fb6d7934c8997b8f3616d
Our assertion statements listened to the old message and the new one. That's
why we did not see this problem but the users did it.
> Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
> -
>
> Key: SUREFIRE-1659
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1659
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Stig Rohde Døssing
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Attachments: src.zip, surefire-stdout-corrupt.zip
>
>
> I have a project that registers a JUnit 5 TestExecutionListener. The
> TestExecutionListener contains an SLF4j Logger, using Log4j2 as the
> underlying library. There is a log4j2.xml on the classpath, logging to
> console, and Surefire is set up to redirect output.
> Running the tests gives the following result.
> {quote}
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file ...
>
[jira] [Commented] (SUREFIRE-1659) Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
[
https://issues.apache.org/jira/browse/SUREFIRE-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374005#comment-17374005
]
Tibor Digana commented on SUREFIRE-1659:
[~srdo]
[~kalgon]
[~EPadronU]
[~rkraneis]
I am still having the problem with Log4J Jul. There is no problem with SLF4J.
The source code in Junit5 is still the same.
{code:java}
class LauncherConfigurationParameters implements ConfigurationParameters {
private static final Logger logger =
LoggerFactory.getLogger(LauncherConfigurationParameters.class);
{code}
The integration test reports an error:
{noformat}
Error: Failures:
Error:JUnitPlatformStreamCorruptionIT.warningIsNotEmittedWithJulToLog4j:88
expecting empty, but was:<['[WARNING] Corrupted channel by directly writing to
native stream in forked JVM 1. See FAQ web page and the dump file
D:\a\maven-surefire\maven-surefire\surefire-its\target\JUnitPlatformStreamCorruptionIT_warningIsNotEmittedWithJulToLog4j\target\surefire-reports\2021-07-03T10-47-26_367-jvmRun1.dumpstream']>
{noformat}
The Ifact that the SLF4J has no problem means that JUL implementation has got a
reference to {{System.out}} too fast on class loading and not lazily when the
first log message is fired. I guess SLF4J is implemented with totally lazy
singleton or something.
That's the reason why our CI failed in
https://github.com/apache/maven-surefire/pull/354/commits/1fc1106cea5da44c213fb6d7934c8997b8f3616d
Our assertion statements listened to the old message and the new one. That's
why we did not see this problem but the users did it.
> Log4j logger in TestExecutionListener corrupts Surefire's STDOUT.
> -
>
> Key: SUREFIRE-1659
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1659
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Stig Rohde Døssing
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Attachments: src.zip, surefire-stdout-corrupt.zip
>
>
> I have a project that registers a JUnit 5 TestExecutionListener. The
> TestExecutionListener contains an SLF4j Logger, using Log4j2 as the
> underlying library. There is a log4j2.xml on the classpath, logging to
> console, and Surefire is set up to redirect output.
> Running the tests gives the following result.
> {quote}
> [WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
> 1. See FAQ web page and the dump file ...
> {quote}
> I've attached a minimal reproduction.
> Doing either of the following eliminates the error:
> * Not having the log4j2.xml on the classpath
> * Not having the Logger in the TestExecutionListener
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-archetype] elharo commented on a change in pull request #35: [ARCHETYPE-584] fix indentation in root pom.xml
elharo commented on a change in pull request #35:
URL: https://github.com/apache/maven-archetype/pull/35#discussion_r663355446
##
File path:
archetype-common/src/main/java/org/apache/maven/archetype/common/util/PomUtils.java
##
@@ -79,6 +83,13 @@ public static boolean addNewModule( String artifactId,
Reader fileReader, Writer
dbf.setXIncludeAware( false );
dbf.setExpandEntityReferences( false );
+InputStream inputStream =
PomUtils.class.getClassLoader().getResourceAsStream( "maven-4.0.0.xsd" );
Review comment:
What is the purpose of loading this schema?
##
File path:
archetype-common/src/test/java/org/apache/maven/archetype/old/ArchetypeTest.java
##
@@ -239,92 +242,152 @@ private ClassLoader getContextClassloader( Artifact
archetypeArtifact, ArtifactR
return archetypeJarLoader;
}
-public void testAddModuleToParentPOM()
-throws Exception
+public void testAddModuleToParentBasic()
+throws Exception
{
-String pom = "\n"
-+ " pom\n"
-+ "";
+String pom = ("
Review comment:
strange that this has to be copied into this project. I'd expect it to
be loaded from maven core, if at all.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7115) MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
[
https://issues.apache.org/jira/browse/MNG-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374002#comment-17374002
]
Hudson commented on MNG-7115:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #177
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/177/
> MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
>
>
> Key: MNG-7115
> URL: https://issues.apache.org/jira/browse/MNG-7115
> Project: Maven
> Issue Type: Bug
> Components: core, Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The IT fails reliably because of:
> {noformat}
> [INFO] --- maven-it-plugin-core-extensions-client:0.1:validate-component
> (validate-extensions) @ test ---
> [DEBUG]
> org.apache.maven.its.it-core-extensions:maven-it-plugin-core-extensions-client:jar:0.1
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> [INFO] Downloading from repoman:
> http://localhost:11669/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> 75193 [qtp1198759714-300] WARN org.eclipse.jetty.server.HttpChannel -
> /org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> java.io.FileNotFoundException:
> /var/mosipov/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5771-core-extensions/repo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at
> org.apache.maven.it.HttpServer$HttpServerBuilder$2.stream(HttpServer.java:174)
> at
> org.apache.maven.it.HttpServer$StreamSourceHandler.handle(HttpServer.java:210)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:529)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:267)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
> at java.lang.Thread.run(Thread.java:748)
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.029 s
> [INFO] Finished at: 2021-03-14T14:04:20+01:00
> [INFO]
>
> {noformat}
> The reason is that Maven Core constantly adds Plexus Utils 1.1 dynamically to
> the extension classpath. This annoyance has been fixed for Maven 4 in:
> {noformat}
> commit c61e63032f71c32c4060c8a94ce792bf47824e3c (slawekjaranowski/master)
> Author: Sylwester Lachiewicz
> Date: 2020-07-24T01:59:50+02:00
> [MNG-6965] Extensions suddenly have
> org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
> This closes #367
> {noformat}
> I don't know what the best solution would be here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7115) MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
[
https://issues.apache.org/jira/browse/MNG-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373981#comment-17373981
]
Michael Osipov commented on MNG-7115:
-
The fixed needs to be revisited when MNG-5984 has been resolved.
> MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
>
>
> Key: MNG-7115
> URL: https://issues.apache.org/jira/browse/MNG-7115
> Project: Maven
> Issue Type: Bug
> Components: core, Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The IT fails reliably because of:
> {noformat}
> [INFO] --- maven-it-plugin-core-extensions-client:0.1:validate-component
> (validate-extensions) @ test ---
> [DEBUG]
> org.apache.maven.its.it-core-extensions:maven-it-plugin-core-extensions-client:jar:0.1
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> [INFO] Downloading from repoman:
> http://localhost:11669/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> 75193 [qtp1198759714-300] WARN org.eclipse.jetty.server.HttpChannel -
> /org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> java.io.FileNotFoundException:
> /var/mosipov/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5771-core-extensions/repo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at
> org.apache.maven.it.HttpServer$HttpServerBuilder$2.stream(HttpServer.java:174)
> at
> org.apache.maven.it.HttpServer$StreamSourceHandler.handle(HttpServer.java:210)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:529)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:267)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
> at java.lang.Thread.run(Thread.java:748)
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.029 s
> [INFO] Finished at: 2021-03-14T14:04:20+01:00
> [INFO]
>
> {noformat}
> The reason is that Maven Core constantly adds Plexus Utils 1.1 dynamically to
> the extension classpath. This annoyance has been fixed for Maven 4 in:
> {noformat}
> commit c61e63032f71c32c4060c8a94ce792bf47824e3c (slawekjaranowski/master)
> Author: Sylwester Lachiewicz
> Date: 2020-07-24T01:59:50+02:00
> [MNG-6965] Extensions suddenly have
> org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
> This closes #367
> {noformat}
> I don't know what the best solution would be here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-7115) MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
[
https://issues.apache.org/jira/browse/MNG-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7115.
---
Resolution: Fixed
Fixed with
[bd99d879460627c036dfc175a76b8686fca6505c|https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=bd99d879460627c036dfc175a76b8686fca6505c].
> MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
>
>
> Key: MNG-7115
> URL: https://issues.apache.org/jira/browse/MNG-7115
> Project: Maven
> Issue Type: Bug
> Components: core, Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The IT fails reliably because of:
> {noformat}
> [INFO] --- maven-it-plugin-core-extensions-client:0.1:validate-component
> (validate-extensions) @ test ---
> [DEBUG]
> org.apache.maven.its.it-core-extensions:maven-it-plugin-core-extensions-client:jar:0.1
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> [INFO] Downloading from repoman:
> http://localhost:11669/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> 75193 [qtp1198759714-300] WARN org.eclipse.jetty.server.HttpChannel -
> /org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> java.io.FileNotFoundException:
> /var/mosipov/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5771-core-extensions/repo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at
> org.apache.maven.it.HttpServer$HttpServerBuilder$2.stream(HttpServer.java:174)
> at
> org.apache.maven.it.HttpServer$StreamSourceHandler.handle(HttpServer.java:210)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:529)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:267)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
> at java.lang.Thread.run(Thread.java:748)
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.029 s
> [INFO] Finished at: 2021-03-14T14:04:20+01:00
> [INFO]
>
> {noformat}
> The reason is that Maven Core constantly adds Plexus Utils 1.1 dynamically to
> the extension classpath. This annoyance has been fixed for Maven 4 in:
> {noformat}
> commit c61e63032f71c32c4060c8a94ce792bf47824e3c (slawekjaranowski/master)
> Author: Sylwester Lachiewicz
> Date: 2020-07-24T01:59:50+02:00
> [MNG-6965] Extensions suddenly have
> org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
> This closes #367
> {noformat}
> I don't know what the best solution would be here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MINVOKER-258) Normalize line endings
[ https://issues.apache.org/jira/browse/MINVOKER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MINVOKER-258: Fix Version/s: 3.2.3 > Normalize line endings > -- > > Key: MINVOKER-258 > URL: https://issues.apache.org/jira/browse/MINVOKER-258 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Slawomir Jaranowski >Assignee: Michael Osipov >Priority: Trivial > Fix For: 3.2.3 > > > In project some files have CRLF and some other LF. > What kind should be? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-7115) MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
[
https://issues.apache.org/jira/browse/MNG-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373973#comment-17373973
]
Michael Osipov edited comment on MNG-7115 at 7/3/21, 9:24 AM:
--
It is caused by
https://github.com/apache/maven-integration-testing/commit/b7e4915001ce1687cbcfeb99ad5dadd0e62af0b1
not accounting that MNG-5984 hasn't been addressed and Maven 4.0.0-alpha-1 has
only an intermediate for that problem.
was (Author: michael-o):
Is is caused by
https://github.com/apache/maven-integration-testing/commit/b7e4915001ce1687cbcfeb99ad5dadd0e62af0b1
not accounting that MNG-5984 hasn't been addressed and Maven 4.0.0-alpha-1 has
only an intermediate for that problem.
> MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
>
>
> Key: MNG-7115
> URL: https://issues.apache.org/jira/browse/MNG-7115
> Project: Maven
> Issue Type: Bug
> Components: core, Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The IT fails reliably because of:
> {noformat}
> [INFO] --- maven-it-plugin-core-extensions-client:0.1:validate-component
> (validate-extensions) @ test ---
> [DEBUG]
> org.apache.maven.its.it-core-extensions:maven-it-plugin-core-extensions-client:jar:0.1
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> [INFO] Downloading from repoman:
> http://localhost:11669/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> 75193 [qtp1198759714-300] WARN org.eclipse.jetty.server.HttpChannel -
> /org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> java.io.FileNotFoundException:
> /var/mosipov/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5771-core-extensions/repo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at
> org.apache.maven.it.HttpServer$HttpServerBuilder$2.stream(HttpServer.java:174)
> at
> org.apache.maven.it.HttpServer$StreamSourceHandler.handle(HttpServer.java:210)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:529)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:267)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
> at java.lang.Thread.run(Thread.java:748)
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.029 s
> [INFO] Finished at: 2021-03-14T14:04:20+01:00
> [INFO]
>
> {noformat}
> The reason is that Maven Core constantly adds Plexus Utils 1.1 dynamically to
> the extension classpath. This annoyance has been fixed for Maven 4 in:
> {noformat}
> commit c61e63032f71c32c4060c8a94ce792bf47824e3c (slawekjaranowski/master)
> Author: Sylwester Lachiewicz
> Date: 2020-07-24T01:59:50+02:00
> [MNG-6965] Extensions suddenly have
> org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
> This closes #367
> {noformat}
> I don't know what the best solution would be here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7115) MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
[
https://issues.apache.org/jira/browse/MNG-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373973#comment-17373973
]
Michael Osipov commented on MNG-7115:
-
Is is caused by
https://github.com/apache/maven-integration-testing/commit/b7e4915001ce1687cbcfeb99ad5dadd0e62af0b1
not accounting that MNG-5984 hasn't been addressed and Maven 4.0.0-alpha-1 has
only an intermediate for that problem.
> MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
>
>
> Key: MNG-7115
> URL: https://issues.apache.org/jira/browse/MNG-7115
> Project: Maven
> Issue Type: Bug
> Components: core, Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The IT fails reliably because of:
> {noformat}
> [INFO] --- maven-it-plugin-core-extensions-client:0.1:validate-component
> (validate-extensions) @ test ---
> [DEBUG]
> org.apache.maven.its.it-core-extensions:maven-it-plugin-core-extensions-client:jar:0.1
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> [INFO] Downloading from repoman:
> http://localhost:11669/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> 75193 [qtp1198759714-300] WARN org.eclipse.jetty.server.HttpChannel -
> /org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> java.io.FileNotFoundException:
> /var/mosipov/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5771-core-extensions/repo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at
> org.apache.maven.it.HttpServer$HttpServerBuilder$2.stream(HttpServer.java:174)
> at
> org.apache.maven.it.HttpServer$StreamSourceHandler.handle(HttpServer.java:210)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:529)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:267)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
> at java.lang.Thread.run(Thread.java:748)
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.029 s
> [INFO] Finished at: 2021-03-14T14:04:20+01:00
> [INFO]
>
> {noformat}
> The reason is that Maven Core constantly adds Plexus Utils 1.1 dynamically to
> the extension classpath. This annoyance has been fixed for Maven 4 in:
> {noformat}
> commit c61e63032f71c32c4060c8a94ce792bf47824e3c (slawekjaranowski/master)
> Author: Sylwester Lachiewicz
> Date: 2020-07-24T01:59:50+02:00
> [MNG-6965] Extensions suddenly have
> org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
> This closes #367
> {noformat}
> I don't know what the best solution would be here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-7115) MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
[
https://issues.apache.org/jira/browse/MNG-7115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7115:
---
Assignee: Michael Osipov
> MavenITmng5771CoreExtensionsTest fails on maven-3.8.x branch
>
>
> Key: MNG-7115
> URL: https://issues.apache.org/jira/browse/MNG-7115
> Project: Maven
> Issue Type: Bug
> Components: core, Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The IT fails reliably because of:
> {noformat}
> [INFO] --- maven-it-plugin-core-extensions-client:0.1:validate-component
> (validate-extensions) @ test ---
> [DEBUG]
> org.apache.maven.its.it-core-extensions:maven-it-plugin-core-extensions-client:jar:0.1
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> [INFO] Downloading from repoman:
> http://localhost:11669/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> 75193 [qtp1198759714-300] WARN org.eclipse.jetty.server.HttpChannel -
> /org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> java.io.FileNotFoundException:
> /var/mosipov/Projekte/maven-integration-testing/core-it-suite/target/test-classes/mng-5771-core-extensions/repo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.(FileInputStream.java:138)
> at
> org.apache.maven.it.HttpServer$HttpServerBuilder$2.stream(HttpServer.java:174)
> at
> org.apache.maven.it.HttpServer$StreamSourceHandler.handle(HttpServer.java:210)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:529)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:267)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:224)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
> at java.lang.Thread.run(Thread.java:748)
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 0.029 s
> [INFO] Finished at: 2021-03-14T14:04:20+01:00
> [INFO]
>
> {noformat}
> The reason is that Maven Core constantly adds Plexus Utils 1.1 dynamically to
> the extension classpath. This annoyance has been fixed for Maven 4 in:
> {noformat}
> commit c61e63032f71c32c4060c8a94ce792bf47824e3c (slawekjaranowski/master)
> Author: Sylwester Lachiewicz
> Date: 2020-07-24T01:59:50+02:00
> [MNG-6965] Extensions suddenly have
> org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
> This closes #367
> {noformat}
> I don't know what the best solution would be here.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MINVOKER-258) Normalize line endings
[ https://issues.apache.org/jira/browse/MINVOKER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MINVOKER-258: --- Assignee: Michael Osipov > Normalize line endings > -- > > Key: MINVOKER-258 > URL: https://issues.apache.org/jira/browse/MINVOKER-258 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Slawomir Jaranowski >Assignee: Michael Osipov >Priority: Trivial > > In project some files have CRLF and some other LF. > What kind should be? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MINVOKER-258) Normalize line endings
[ https://issues.apache.org/jira/browse/MINVOKER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MINVOKER-258: Summary: Normalize line endings (was: file line endings encoding) > Normalize line endings > -- > > Key: MINVOKER-258 > URL: https://issues.apache.org/jira/browse/MINVOKER-258 > Project: Maven Invoker Plugin > Issue Type: Task >Reporter: Slawomir Jaranowski >Priority: Trivial > > In project some files have CRLF and some other LF. > What kind should be? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-invoker-plugin] michael-o commented on pull request #36: [MINVOKER-258] normalize the line endings code to LF
michael-o commented on pull request #36: URL: https://github.com/apache/maven-invoker-plugin/pull/36#issuecomment-873375136 Alright, I will try to review this weekend. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-invoker-plugin] slawekjaranowski commented on pull request #36: [MINVOKER-258] normalize the line endings code to LF
slawekjaranowski commented on pull request #36: URL: https://github.com/apache/maven-invoker-plugin/pull/36#issuecomment-873373801 Exactly for this is PR ... in repository we should have every file with the same line encoding and conversion should be done on client site according to `core.autocrlf` settings. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archetype] newur edited a comment on pull request #35: [ARCHETYPE-584] fix indentation in root pom.xml
newur edited a comment on pull request #35: URL: https://github.com/apache/maven-archetype/pull/35#issuecomment-873362462 Wow, this branch/bug is still around. I totally forgot about it. After playing around with the integration tests a bit, one problem was to load the `.xsd` from the packaged `.jar` (which works differently from reading from a single file). Solving the loading from the jar seems to fix the ITs. Let's see what comes up next or if this long journey reaches its happy end. :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-archetype] newur commented on pull request #35: [ARCHETYPE-584] fix indentation in root pom.xml
newur commented on pull request #35: URL: https://github.com/apache/maven-archetype/pull/35#issuecomment-873362462 Wow, this branch/bug is still around. I totally forgot about it. After playing around with the integration tests a bit, one problem was to load the `.xsd` from the packaged `.jar` (which works differently from reading from a single file). This seems to fix the ITs. Let's see what comes up next or if this long journey reaches its happy end. :) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] kriegaex edited a comment on pull request #104: [MSHADE-366] - "Access denied" during 'minimizeJar' (supersedes #83)
kriegaex edited a comment on pull request #104: URL: https://github.com/apache/maven-shade-plugin/pull/104#issuecomment-873361152 > side note: a real fix would be to handle folders no, does not sound crazy? I agree, which is why I raised the question in the original PR and also CC in the Jira issue: >>> The more important question I have is: Is it necessary to do the same analysis and exclusion for used services during minification for files in a `target` directory on the classpath, which currently happens for JAR files, or is it the right thing to just ignore it? Is a classpath directory a valid use case here? It could very well be the case, because the current module's class files are usually part of the uber JAR if not explicitly excluded by a filter. So we would have to mimic the same logic here. I can try doing that, starting a fresh PR superseding this one. But I want a maintainer's qualified answer before I start potentially wasting time with a superfluous feature. Also [in the Jira issue](https://issues.apache.org/jira/browse/MSHADE-366?focusedCommentId=17350890=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17350890), @JanMosigItemis replied: >> I'd say, to make things more straight forward, we should do the "quick fix" for the warning and the (maybe) new logic in different PRs, so that we get fast results but do not mix things up here. I wanted to respect his suggestion and still am. To expand this functionality to class file directories too, would still be a goal for the future. This is e.g. why when factoring out method `scanServiceProviderConfigFile`, I decided for it not to take a `JarEntry` parameter, but simply a `BufferedReader`, so later it can be reused for service loader config files found in file system directories. Probably, further refactoring to unify the two approaches is possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] kriegaex commented on pull request #104: [MSHADE-366] - "Access denied" during 'minimizeJar' (supersedes #83)
kriegaex commented on pull request #104: URL: https://github.com/apache/maven-shade-plugin/pull/104#issuecomment-873361152 > side note: a real fix would be to handle folders no, does not sound crazy? I agree, which is why I raised the question in the original PR and also CC in the Jira issue: >>> The more important question I have is: Is it necessary to do the same analysis and exclusion for used services during minification for files in a `target` directory on the classpath, which currently happens for JAR files, or is it the right thing to just ignore it? Is a classpath directory a valid use case here? It could very well be the case, because the current module's class files are usually part of the uber JAR if not explicitly excluded by a filter. So we would have to mimic the same logic here. I can try doing that, starting a fresh PR superseding this one. But I want a maintainer's qualified answer before I start potentially wasting time with a superfluous feature. Also [in the Jira issue](https://issues.apache.org/jira/browse/MSHADE-366?focusedCommentId=17350890=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17350890), @JanMosigItemis replied: >> I'd say, to make things more straight forward, we should do the "quick fix" for the warning and the (maybe) new logic in different PRs, so that we get fast results but do not mix things up here. I wanted to respect his suggestion and still am. To expand this functionality to class file directories too, would still be a goal for the future. This is e.g. why when factoring out method `scanServiceProviderConfigFile`, I decided for it not to take a `JarEntry` parameter, but simply a `BufferedReader`, so later it can be reused for service loader config files found in file system directories. Probably, further refactoring to unifie the two approaches is possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEPLOY-244) maven deploy plugin 3.0.0-M1 breaks deploys when alt*DeploymentRepository properties are used
[ https://issues.apache.org/jira/browse/MDEPLOY-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17373926#comment-17373926 ] Nick Cross commented on MDEPLOY-244: As we have projects that using both the earlier 2.x and the later 3.x syntax and we use a generic altDeploymentRepository we switched to using [https://github.com/rnc/alt-deploy-maven-extension] (full disclosure - I'm the author) to try and transparently handle it. > maven deploy plugin 3.0.0-M1 breaks deploys when alt*DeploymentRepository > properties are used > - > > Key: MDEPLOY-244 > URL: https://issues.apache.org/jira/browse/MDEPLOY-244 > Project: Maven Deploy Plugin > Issue Type: Bug > Components: deploy:deploy-file >Affects Versions: 3.0.0-M1 >Reporter: William So >Assignee: Karl Heinz Marbaise >Priority: Critical > Fix For: 3.0.0-M2 > > Attachments: project-pom.xml, root-pom.xml, test-maven-deploy.zip > > > After upgrading to maven deploy plugin to 3.0.0-M1, our Maven Builds that > uploads an RPM artifact broke. All other artifacts, like zips, pom, jar, > etc.. was able to upload without problems. But as soon as the build tried > to upload an RPM the upload threw an 401 Error: > > [Continue Pipeline] [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:3.0.0-M1:deploy (default-deploy) > on project company-fancyname-atg-apptype-ibm-qa4: ArtifactDeployerException: > Failed to deploy artifacts: Could not transfer artifact > com.sephops.fancyname:company-fancyname-atg-apptype-ibm-qa4:rpm:ProjectName-20181001.061415-35 > from/to company-snapshot-yum::default > (http://artifactory.com/artifactory/company-snapshot-yum-local): Failed to > transfer file: > http://artifactory.com/artifactory/company-snapshot-yum-local/com/sephops/fancyname/company-fancyname-atg-apptype-ibm-qa4/ProjectName-SNAPSHOT/company-fancyname-atg-apptype-ibm-qa4-ProjectName-20181001.061415-35.rpm. > Return code is: 401, ReasonPhrase: Unauthorized. -> [Help 1] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSHADE-398) MSHADE-185 IT failing if JAVA_HOME != JDK version running the test
Alexander Kriegisch created MSHADE-398:
--
Summary: MSHADE-185 IT failing if JAVA_HOME != JDK version running
the test
Key: MSHADE-398
URL: https://issues.apache.org/jira/browse/MSHADE-398
Project: Maven Shade Plugin
Issue Type: Bug
Affects Versions: 3.2.4
Reporter: Alexander Kriegisch
Maven Invoker regression integration test (IT) {{MSHADE-185}} runs only on JDK
<= 8. The CI builds on GitHub are fine, because they run on JDK 8 and also set
{{JAVA_HOME}} accordingly. But on many systems, e.g. my developer workstation,
{{JAVA_HOME}} points to a more recent JDK like 9, 11, 16. Those JDKs do not
contain {{tools.jar}}, of course. So far, so good.
Now it is perfectly normal that a developer starts an IDE and from there loads
her project and runs the Maven Shade build, selecting a different JDK to run
Maven on, because for example they want to run all ITs. The same can happen in
a console, if the developer starts Maven on a different Java executable than
the one pointed to by {{JAVA_HOME}}. In both cases, the test fails, because the
POM contains a system dependency on {{tools.jar}}.
First the Maven build started by Invoker fails:
{code:java}
[ERROR] Failed to execute goal on project system-dep: Could not resolve
dependencies for project test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not
find artifact com.sun:tools:jar:1.6 at specified path c:\Program
Files\Java\jdk-16\..\lib\tools.jar -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
on project system-dep: Could not resolve dependencies for project
test.shade:system-dep:jar:1.0.0-SNAPSHOT: Could not find artifact
com.sun:tools:jar:1.6 at specified path c:\Program
Files\Java\jdk-16\..\lib\tools.jar
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies
(LifecycleDependencyResolver.java:269)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies
(LifecycleDependencyResolver.java:147)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved
(MojoExecutor.java:248)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:202)
{code}
Then later of course also the post-run verify step fails, because no
dependency-reduced POM was created due to the fact that the build failed
quickly:
{code:java}
Running post-build script:
C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\verify.groovy
Assertion failed:
assert pomFile.isFile()
| |
| false
C:\Users\alexa\Documents\java-src\maven-shade-plugin\target\it\MSHADE-185\dependency-reduced-pom.xml
{code}
The solution would be to make sure that Invoker sets JAVA_HOME according to the
JDK actually used for running the test. I have not investigated how to do that,
but it should be possible somehow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
