[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789357#comment-17789357 ] Robert Seidel commented on SUREFIRE-2211: - here is a short example of manifests which I tested under Windows this doesn't work (surefire > 3.0.0M1): Manifest-Version: 1.0 Class-Path: file://server/path/ Main-Class: com.main.Start but this does (surefire < 3.0.0M2): Manifest-Version: 1.0 Class-Path: file:server/path/ Main-Class: com.main.Start for windows files located in drives, both will work: (surefire > 3.0.0M1) Manifest-Version: 1.0 Class-Path: file:///c:/path/ Main-Class: com.main.Start (surefire < 3.0.0M2) Manifest-Version: 1.0 Class-Path: file:/c:/path/ Main-Class: com.main.Start > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (MNGSITE-528) Execution default of goal org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2 out of bounds for length 2
[
https://issues.apache.org/jira/browse/MNGSITE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov deleted MNGSITE-528:
---
> Execution default of goal
> org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2
> out of bounds for length 2
>
>
> Key: MNGSITE-528
> URL: https://issues.apache.org/jira/browse/MNGSITE-528
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Filipe Roque
>Priority: Major
>
> It only affects apache-maven-4.0.0-alpha-8
> pom.xml
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.example
> mvn4-assembly-index
> 1.0-SNAPSHOT
>
> 17
> 17
> UTF-8
>
>
>
> org.ehcache
> ehcache
> 3.10.8
>
>
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 3.6.0
>
>
>
> src/main/assembly/descriptor.xml
>
> false
>
>
>
> package
>
> single
>
>
>
>
>
>
> {code}
> descriptor.xml
> {code:java}
> http://maven.apache.org/ASSEMBLY/2.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.0
> http://maven.apache.org/xsd/assembly-2.1.0.xsd";>
> assembly
>
> dir
>
> false
> .
>
>
> /
> false
> runtime
>
>
>
> {code}
> {code:java}
> ❯ /opt/maven/apache-maven-4.0.0-alpha-8/bin/mvn -q package
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single (default) on
> project mvn4-assembly-index: Execution default of goal
> org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2
> out of bounds for length 2 -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
> switch
> [ERROR] Re-run Maven using the '-X' switch to enable verbose output
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789340#comment-17789340 ] Robert Seidel commented on SUREFIRE-2211: - I'll guess that the issue is related, but its not the same. The problem comes when creating and using the fork jar. Inside of the jar is a manifest with the Class-Path: attribute. While all the related paths works fine like this one ../../../../.m2/repository/org/apache/maven/surefire/surefire-booter/3.0.0-M2-SNAPSHOT/surefire-booter-3.0.0-M2-SNAPSHOT.jar, the unc path works only with this sick looking format: file:server/somePath/. The correct URL path would look like file://server/somePath/ that is what .toUri() & .toRealPath().toUri() provides (guess it was a fix when introducing nio), but that won't work there. Funny thing is, for drive letters the syntax also changed from file:/c:/temp/ to file:///c:/temp, but there work both ways. It did not find any more specification regarding absolute files, as it seems an edge case. https://download.java.net/java/early_access/loom/docs/specs/jar/jar.html#class-path-attribute > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MCOMPILER-542) clean JDK patch version in module-info.class
[
https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789331#comment-17789331
]
Herve Boutemy edited comment on MCOMPILER-542 at 11/24/23 6:04 AM:
---
you're right, I was hard with "hack", workaround is better :)
{quote}I could add the info message on every modification (even if I would
prefer as debug).
{quote}
too chatty: that's why I proposed just a single summary at the end of the
patch, to know that the patch was activated and how much it had to patch. More
detail, even in debug, is too much noise IMHO
and the objective to know that the patch was activated is to also see in the
future that it's not activated any more, and eventually that it's activated but
did not find anything to patch...
notice that even if JDK 22 has the fix, I expect Reproducible Builds releases
to be done with the next LTS, in near 2 years, because building releases to
Maven Central with a non LTS compiler is not a best practice
was (Author: hboutemy):
you're right, I was hard with "hack", workaround is better :)
{quote}I could add the info message on every modification (even if I would
prefer as debug).
{quote}
too chatty: that's why I proposed just a single summary at the end of the
patch, to know that the patch was activated and how much it had to patch. More
detail, even in debug, is too much noise IMHO
and the objective to know that the patch was activated is to also see in the
future that it's not activated any more, and eventually that it's activated but
did not find anything to patch...
> clean JDK patch version in module-info.class
>
>
> Key: MCOMPILER-542
> URL: https://issues.apache.org/jira/browse/MCOMPILER-542
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.11.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.12.0
>
>
> as seen in MJAR-275, JDK patch version in module-info.class is NOT included
> only when building with a newer JDK release using "--release" flag, see
> [https://github.com/jvm-repo-rebuild/module-info]
> issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a
> proper fix at javac level (probably for Java 22)
> and waiting for that, we need a workaround to drop the JDK patch version in
> other cases: we'll need to define where is the best place –
> m-jar-p?m-compiler-p? other?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MCOMPILER-542) clean JDK patch version in module-info.class
[
https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789331#comment-17789331
]
Herve Boutemy commented on MCOMPILER-542:
-
you're right, I was hard with "hack", workaround is better :)
{quote}I could add the info message on every modification (even if I would
prefer as debug).
{quote}
too chatty: that's why I proposed just a single summary at the end of the
patch, to know that the patch was activated and how much it had to patch. More
detail, even in debug, is too much noise IMHO
and the objective to know that the patch was activated is to also see in the
future that it's not activated any more, and eventually that it's activated but
did not find anything to patch...
> clean JDK patch version in module-info.class
>
>
> Key: MCOMPILER-542
> URL: https://issues.apache.org/jira/browse/MCOMPILER-542
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Affects Versions: 3.11.0
>Reporter: Herve Boutemy
>Assignee: Herve Boutemy
>Priority: Major
> Fix For: 3.12.0
>
>
> as seen in MJAR-275, JDK patch version in module-info.class is NOT included
> only when building with a newer JDK release using "--release" flag, see
> [https://github.com/jvm-repo-rebuild/module-info]
> issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a
> proper fix at javac level (probably for Java 22)
> and waiting for that, we need a workaround to drop the JDK patch version in
> other cases: we'll need to define where is the best place –
> m-jar-p?m-compiler-p? other?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNGSITE-528) Execution default of goal org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2 out of bounds for length 2
[
https://issues.apache.org/jira/browse/MNGSITE-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789275#comment-17789275
]
Filipe Roque commented on MNGSITE-528:
--
this was created on the wrong project. can be deleted or closed.
this is the proper issue: https://issues.apache.org/jira/browse/MNG-7944
> Execution default of goal
> org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2
> out of bounds for length 2
>
>
> Key: MNGSITE-528
> URL: https://issues.apache.org/jira/browse/MNGSITE-528
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Filipe Roque
>Priority: Major
>
> It only affects apache-maven-4.0.0-alpha-8
> pom.xml
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.example
> mvn4-assembly-index
> 1.0-SNAPSHOT
>
> 17
> 17
> UTF-8
>
>
>
> org.ehcache
> ehcache
> 3.10.8
>
>
>
>
>
> org.apache.maven.plugins
> maven-assembly-plugin
> 3.6.0
>
>
>
> src/main/assembly/descriptor.xml
>
> false
>
>
>
> package
>
> single
>
>
>
>
>
>
> {code}
> descriptor.xml
> {code:java}
> http://maven.apache.org/ASSEMBLY/2.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.0
> http://maven.apache.org/xsd/assembly-2.1.0.xsd";>
> assembly
>
> dir
>
> false
> .
>
>
> /
> false
> runtime
>
>
>
> {code}
> {code:java}
> ❯ /opt/maven/apache-maven-4.0.0-alpha-8/bin/mvn -q package
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single (default) on
> project mvn4-assembly-index: Execution default of goal
> org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2
> out of bounds for length 2 -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
> switch
> [ERROR] Re-run Maven using the '-X' switch to enable verbose output
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7944) Execution default of goal org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2 out of bounds for length 2
Filipe Roque created MNG-7944:
-
Summary: Execution default of goal
org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2 out
of bounds for length 2
Key: MNG-7944
URL: https://issues.apache.org/jira/browse/MNG-7944
Project: Maven
Issue Type: Bug
Affects Versions: 4.0.0-alpha-8
Reporter: Filipe Roque
It only affects apache-maven-4.0.0-alpha-8
pom.xml
{code:java}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
org.example
mvn4-assembly-index
1.0-SNAPSHOT
17
17
UTF-8
org.ehcache
ehcache
3.10.8
org.apache.maven.plugins
maven-assembly-plugin
3.6.0
src/main/assembly/descriptor.xml
false
package
single
{code}
descriptor.xml
{code:java}
http://maven.apache.org/ASSEMBLY/2.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.0
http://maven.apache.org/xsd/assembly-2.1.0.xsd";>
assembly
dir
false
.
/
false
runtime
{code}
{code:java}
❯ /opt/maven/apache-maven-4.0.0-alpha-8/bin/mvn -q package
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single (default) on
project mvn4-assembly-index: Execution default of goal
org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2 out
of bounds for length 2 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
switch
[ERROR] Re-run Maven using the '-X' switch to enable verbose output
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNGSITE-528) Execution default of goal org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2 out of bounds for length 2
Filipe Roque created MNGSITE-528:
Summary: Execution default of goal
org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2 out
of bounds for length 2
Key: MNGSITE-528
URL: https://issues.apache.org/jira/browse/MNGSITE-528
Project: Maven Project Web Site
Issue Type: Bug
Reporter: Filipe Roque
It only affects apache-maven-4.0.0-alpha-8
pom.xml
{code:java}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
org.example
mvn4-assembly-index
1.0-SNAPSHOT
17
17
UTF-8
org.ehcache
ehcache
3.10.8
org.apache.maven.plugins
maven-assembly-plugin
3.6.0
src/main/assembly/descriptor.xml
false
package
single
{code}
descriptor.xml
{code:java}
http://maven.apache.org/ASSEMBLY/2.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.0
http://maven.apache.org/xsd/assembly-2.1.0.xsd";>
assembly
dir
false
.
/
false
runtime
{code}
{code:java}
❯ /opt/maven/apache-maven-4.0.0-alpha-8/bin/mvn -q package
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single (default) on
project mvn4-assembly-index: Execution default of goal
org.apache.maven.plugins:maven-assembly-plugin:3.6.0:single failed: Index 2 out
of bounds for length 2 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the '-e'
switch
[ERROR] Re-run Maven using the '-X' switch to enable verbose output
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789266#comment-17789266 ] Michael Osipov commented on SUREFIRE-2211: -- https://hg.openjdk.org/jdk9/jdk9/jdk/rev/8cba9cc074b8 > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1014) Optionally inherit system environment variables by Commandline
[
https://issues.apache.org/jira/browse/MSHARED-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789264#comment-17789264
]
Michael Osipov commented on MSHARED-1014:
-
This breaks
{noformat}
surefire-its/target/failsafe-reports/org.apache.maven.surefire.its.EnvironmentVariablesIT.txt:Tests
run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 15.10 s <<< FAILURE!
-- in org.apache.maven.surefire.its.EnvironmentVariablesIT
{noformat}
> Optionally inherit system environment variables by Commandline
> --
>
> Key: MSHARED-1014
> URL: https://issues.apache.org/jira/browse/MSHARED-1014
> Project: Maven Shared Components
> Issue Type: New Feature
> Components: maven-shared-utils
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: maven-shared-utils-3.4.0, maven-shared-utils-3.4.1
>
>
> In class {{Commandline}} we have public method {{addSystemEnvironment}}
> This method is always called from {{getEnvironmentVariables}}
> Should be possibility to add system environment variables from parent process
> conditionally.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789261#comment-17789261 ] Michael Osipov commented on SUREFIRE-2211: -- Seems to be very related: https://bugs.openjdk.org/browse/JDK-8178726 > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789255#comment-17789255 ] Michael Osipov commented on SUREFIRE-2211: -- Before I proceed with your PR, can you profile a simple Java example w/o Surefire and a sample CP is provided by Surefire which fails for you. I wonder whether we need to report with OpenJDK because I apply your PR. > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[ https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789253#comment-17789253 ] Michael Osipov commented on SUREFIRE-2211: -- Both representations seems to be valid: https://www.rfc-editor.org/rfc/rfc8089.html#appendix-E.3.2 > additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1 > - > > Key: SUREFIRE-2211 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2211 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 3.0.0-M2, 3.2.2 > Environment: Windows JDK17.0.5+8 >Reporter: Robert Seidel >Priority: Major > > We are using the configuration parameter additionalClasspathElements > (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements) > to provide a log4j2 xml configuration during tests. There is configured an > UNC path like this //our-server/build/failsafe containing the file. > Until version 3.0.0-M2 everything was fine, the ressource could be found > within the class loader and log4j was configured correctly (so 3.0.0-M1 was > ok). > However since the Milestone 2 of version 3 and with all later versions, the > ressource could not be found within the classpath, leaving log4j unconfigured. > From the reporting xml the classpath is configured the same, but the class > loader behaves differently. > When using a normal path like c:/build/failsafe the ressource can be found > without issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2211) additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
[
https://issues.apache.org/jira/browse/SUREFIRE-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789251#comment-17789251
]
ASF GitHub Bot commented on SUREFIRE-2211:
--
michael-o commented on code in PR #689:
URL: https://github.com/apache/maven-surefire/pull/689#discussion_r1403697890
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java:
##
@@ -179,6 +179,10 @@ static String relativize(@Nonnull Path parent, @Nonnull
Path child) throws Illeg
}
static String toAbsoluteUri(@Nonnull Path absolutePath) {
+// unc paths needs to be written as file:
+if (absolutePath.toString().startsWith("")) {
+return absolutePath.toFile().toURI().toASCIIString();
+}
Review Comment:
That looks so sick...it should be identical. It thos really so broken in
Java?
> additionalClasspathElement with UNC path not working with failsafe > 3.0.0-M1
> -
>
> Key: SUREFIRE-2211
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2211
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M2, 3.2.2
> Environment: Windows JDK17.0.5+8
>Reporter: Robert Seidel
>Priority: Major
>
> We are using the configuration parameter additionalClasspathElements
> (https://maven.apache.org/surefire/maven-failsafe-plugin/integration-test-mojo.html#additionalClasspathElements)
> to provide a log4j2 xml configuration during tests. There is configured an
> UNC path like this //our-server/build/failsafe containing the file.
> Until version 3.0.0-M2 everything was fine, the ressource could be found
> within the class loader and log4j was configured correctly (so 3.0.0-M1 was
> ok).
> However since the Milestone 2 of version 3 and with all later versions, the
> ressource could not be found within the classpath, leaving log4j unconfigured.
> From the reporting xml the classpath is configured the same, but the class
> loader behaves differently.
> When using a normal path like c:/build/failsafe the ressource can be found
> without issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [SUREFIRE-2211] Fix UNC classpath elements [maven-surefire]
michael-o commented on code in PR #689:
URL: https://github.com/apache/maven-surefire/pull/689#discussion_r1403697890
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java:
##
@@ -179,6 +179,10 @@ static String relativize(@Nonnull Path parent, @Nonnull
Path child) throws Illeg
}
static String toAbsoluteUri(@Nonnull Path absolutePath) {
+// unc paths needs to be written as file:
+if (absolutePath.toString().startsWith("")) {
+return absolutePath.toFile().toURI().toASCIIString();
+}
Review Comment:
That looks so sick...it should be identical. It thos really so broken in
Java?
--
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] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789226#comment-17789226 ] Jorge Solórzano commented on MCOMPILER-542: --- I would call it a workaround more than a hack, but anyway, if the fix ships in 22 (I doubt it will in 21), we can add the conditional, but we are not there yet, so even if the workaround applies to every version right now, it should not make any difference between the fix in the JDK and here. Actually, the only advantage of the JDK fix is that it would not require ASM upgrades on every major version (that it's actually required now anyway), other than that it should be a perfectly valid workaround. In any case, I could add the info message on every modification (even if I would prefer as debug). > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > as seen in MJAR-275, JDK patch version in module-info.class is NOT included > only when building with a newer JDK release using "--release" flag, see > [https://github.com/jvm-repo-rebuild/module-info] > issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a > proper fix at javac level (probably for Java 22) > and waiting for that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define where is the best place – > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789225#comment-17789225 ] Herve Boutemy edited comment on MCOMPILER-542 at 11/23/23 5:44 PM: --- it's part of the review and improvement I want to make if possible: activate the rewrite when necessary, given JDK release and release configuration, to not activate it when > 21 (if the fix ships in 21) and also display an info message with a count of fixes done, just to avoid having a silent (hack) feature was (Author: hboutemy): it's part of the review and improvement I want to make if possible: activate the rewrite when necessary, given JDK release and release configuration, to not activate it when > 21 (if the fix ships in 21) and also display an info message with a count of fixes done, just not avoid having a silent (hack) feature > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > as seen in MJAR-275, JDK patch version in module-info.class is NOT included > only when building with a newer JDK release using "--release" flag, see > [https://github.com/jvm-repo-rebuild/module-info] > issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a > proper fix at javac level (probably for Java 22) > and waiting for that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define where is the best place – > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789225#comment-17789225 ] Herve Boutemy commented on MCOMPILER-542: - it's part of the review and improvement I want to make if possible: activate the rewrite when necessary, given JDK release and release configuration, to not activate it when > 21 (if the fix ships in 21) and also display an info message with a count of fixes done, just not avoid having a silent (hack) feature > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > as seen in MJAR-275, JDK patch version in module-info.class is NOT included > only when building with a newer JDK release using "--release" flag, see > [https://github.com/jvm-repo-rebuild/module-info] > issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a > proper fix at javac level (probably for Java 22) > and waiting for that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define where is the best place – > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7942) Upgrade to parent POM 41
[ https://issues.apache.org/jira/browse/MNG-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789211#comment-17789211 ] ASF GitHub Bot commented on MNG-7942: - slawekjaranowski merged PR #1324: URL: https://github.com/apache/maven/pull/1324 > Upgrade to parent POM 41 > > > Key: MNG-7942 > URL: https://issues.apache.org/jira/browse/MNG-7942 > Project: Maven > Issue Type: Dependency upgrade > Components: Bootstrap & Build >Reporter: Tamas Cservenak >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.9.6 > > > Upgrade to parent POM 41 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7942) Upgrade to parent POM 41
[ https://issues.apache.org/jira/browse/MNG-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MNG-7942. Resolution: Fixed > Upgrade to parent POM 41 > > > Key: MNG-7942 > URL: https://issues.apache.org/jira/browse/MNG-7942 > Project: Maven > Issue Type: Dependency upgrade > Components: Bootstrap & Build >Reporter: Tamas Cservenak >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.9.6 > > > Upgrade to parent POM 41 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7942] Upgrade maven-parent to 41 [maven]
slawekjaranowski merged PR #1324: URL: https://github.com/apache/maven/pull/1324 -- 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] [Updated] (SUREFIRE-2214) Upgrade to HtmlUnit 3.8.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-2214: - Summary: Upgrade to HtmlUnit 3.8.0 (was: Uprade to HtmlUnit 3.8.0) > Upgrade to HtmlUnit 3.8.0 > - > > Key: SUREFIRE-2214 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2214 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin >Reporter: Ronald Brill >Assignee: Michael Osipov >Priority: Minor > Fix For: next-release > > > The uses HtmlUnit version is really outdated. The update seems to be simple. > If you like i can provide a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2214) Uprade to HtmlUnit 3.8.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SUREFIRE-2214. Resolution: Fixed Fixed with [f5b73ab3d18baa4baf244b2526d854574e51f87e|https://gitbox.apache.org/repos/asf?p=maven-surefire.git&a=commit&h=f5b73ab3d18baa4baf244b2526d854574e51f87e]. > Uprade to HtmlUnit 3.8.0 > > > Key: SUREFIRE-2214 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2214 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin >Reporter: Ronald Brill >Assignee: Michael Osipov >Priority: Minor > Fix For: next-release > > > The uses HtmlUnit version is really outdated. The update seems to be simple. > If you like i can provide a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SUREFIRE-2215) Upgrade to Parent 41
[ https://issues.apache.org/jira/browse/SUREFIRE-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed SUREFIRE-2215. Resolution: Fixed Fixed with [6662e07f5957d0fa4d12dc3e331be8f93cf355f8|https://gitbox.apache.org/repos/asf?p=maven-surefire.git&a=commit&h=6662e07f5957d0fa4d12dc3e331be8f93cf355f8]. > Upgrade to Parent 41 > > > Key: SUREFIRE-2215 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2215 > Project: Maven Surefire > Issue Type: Dependency upgrade >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2214) Uprade to HtmlUnit 3.8.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789117#comment-17789117 ] ASF GitHub Bot commented on SUREFIRE-2214: -- michael-o closed pull request #688: [SUREFIRE-2214] update HtmlUnit to version 3.8.0 URL: https://github.com/apache/maven-surefire/pull/688 > Uprade to HtmlUnit 3.8.0 > > > Key: SUREFIRE-2214 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2214 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin >Reporter: Ronald Brill >Assignee: Michael Osipov >Priority: Minor > Fix For: next-release > > > The uses HtmlUnit version is really outdated. The update seems to be simple. > If you like i can provide a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [SUREFIRE-2214] update HtmlUnit to version 3.8.0 [maven-surefire]
michael-o closed pull request #688: [SUREFIRE-2214] update HtmlUnit to version 3.8.0 URL: https://github.com/apache/maven-surefire/pull/688 -- 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] [Created] (SUREFIRE-2215) Upgrade to Parent 41
Michael Osipov created SUREFIRE-2215: Summary: Upgrade to Parent 41 Key: SUREFIRE-2215 URL: https://issues.apache.org/jira/browse/SUREFIRE-2215 Project: Maven Surefire Issue Type: Dependency upgrade Reporter: Michael Osipov Assignee: Michael Osipov Fix For: next-release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2214) Uprade to HtmlUnit 3.8.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-2214: - Summary: Uprade to HtmlUnit 3.8.0 (was: Update to HtmlUnit 3.8.0) > Uprade to HtmlUnit 3.8.0 > > > Key: SUREFIRE-2214 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2214 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin >Reporter: Ronald Brill >Assignee: Michael Osipov >Priority: Minor > Fix For: next-release > > > The uses HtmlUnit version is really outdated. The update seems to be simple. > If you like i can provide a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-558) compileSourceRoots in testCompile should be writable
[ https://issues.apache.org/jira/browse/MCOMPILER-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789063#comment-17789063 ] ASF GitHub Bot commented on MCOMPILER-558: -- gnodet merged PR #209: URL: https://github.com/apache/maven-compiler-plugin/pull/209 > compileSourceRoots in testCompile should be writable > > > Key: MCOMPILER-558 > URL: https://issues.apache.org/jira/browse/MCOMPILER-558 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Lorenz Simon >Priority: Minor > Fix For: 3.12.0 > > > In projects with Java *and* Kotlin sources, it should be possible to set the > `compileSourceRoots` on the plugin level and not the project level. This way > the Kotlin compiler can be configured to only consider Kotlin sources and the > Java compiler can only consider Java sources. > `compileSourceRoots` was already changed to writable in the `compile` goal. > So I don't see any risks in also changing it for the `testCompile` goal. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MCOMPILER-558) compileSourceRoots in testCompile should be writable
[ https://issues.apache.org/jira/browse/MCOMPILER-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MCOMPILER-558. - Assignee: Guillaume Nodet Resolution: Fixed > compileSourceRoots in testCompile should be writable > > > Key: MCOMPILER-558 > URL: https://issues.apache.org/jira/browse/MCOMPILER-558 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Lorenz Simon >Assignee: Guillaume Nodet >Priority: Minor > Fix For: 3.12.0 > > > In projects with Java *and* Kotlin sources, it should be possible to set the > `compileSourceRoots` on the plugin level and not the project level. This way > the Kotlin compiler can be configured to only consider Kotlin sources and the > Java compiler can only consider Java sources. > `compileSourceRoots` was already changed to writable in the `compile` goal. > So I don't see any risks in also changing it for the `testCompile` goal. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-558] compileSourceRoots in testCompile should be writable [maven-compiler-plugin]
gnodet merged PR #209: URL: https://github.com/apache/maven-compiler-plugin/pull/209 -- 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] [Closed] (MCOMPILER-559) Warn if overriding the project's artifact's file
[
https://issues.apache.org/jira/browse/MCOMPILER-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MCOMPILER-559.
-
Fix Version/s: 3.12.0
Resolution: Fixed
> Warn if overriding the project's artifact's file
>
>
> Key: MCOMPILER-559
> URL: https://issues.apache.org/jira/browse/MCOMPILER-559
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.12.0
>
>
> The use case is the following:
> * a module needs to consume (unpack) another module with resources
> * the consumed module thus specifies the jar goal to be run at compile time
> or before
> * the unpack fails because the artifact's file has been reset to
> {{${basedir}/target/classes}} by the m-compiler-p
> Diagnosing this problem took quite some time and debugging to understand what
> was happening.
> A warning in m-compiler-p to (at least) warn the user that something weird is
> going on would be welcomed. The other option is to not override and warn or
> reject (because compiling after the artifact has been packaged is quite
> unexpected).
> I'm not sure why this would be responsibility of the m-compiler-p to actually
> set the artifact's file to {{${basedir}/target/classes}}, as this could also
> be done by m-resource-p which also writes to that directory, or even earlier,
> when starting a given project build, by maven-core itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCOMPILER-559] Warn if overwriting the project's artifact's file to a different value [maven-compiler-plugin]
gnodet merged PR #211: URL: https://github.com/apache/maven-compiler-plugin/pull/211 -- 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] (MCOMPILER-559) Warn if overriding the project's artifact's file
[
https://issues.apache.org/jira/browse/MCOMPILER-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789062#comment-17789062
]
ASF GitHub Bot commented on MCOMPILER-559:
--
gnodet merged PR #211:
URL: https://github.com/apache/maven-compiler-plugin/pull/211
> Warn if overriding the project's artifact's file
>
>
> Key: MCOMPILER-559
> URL: https://issues.apache.org/jira/browse/MCOMPILER-559
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Guillaume Nodet
>Priority: Major
>
> The use case is the following:
> * a module needs to consume (unpack) another module with resources
> * the consumed module thus specifies the jar goal to be run at compile time
> or before
> * the unpack fails because the artifact's file has been reset to
> {{${basedir}/target/classes}} by the m-compiler-p
> Diagnosing this problem took quite some time and debugging to understand what
> was happening.
> A warning in m-compiler-p to (at least) warn the user that something weird is
> going on would be welcomed. The other option is to not override and warn or
> reject (because compiling after the artifact has been packaged is quite
> unexpected).
> I'm not sure why this would be responsibility of the m-compiler-p to actually
> set the artifact's file to {{${basedir}/target/classes}}, as this could also
> be done by m-resource-p which also writes to that directory, or even earlier,
> when starting a given project build, by maven-core itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SUREFIRE-2214) Update to HtmlUnit 3.8.0
[ https://issues.apache.org/jira/browse/SUREFIRE-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated SUREFIRE-2214: - Fix Version/s: next-release > Update to HtmlUnit 3.8.0 > > > Key: SUREFIRE-2214 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2214 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin >Reporter: Ronald Brill >Assignee: Michael Osipov >Priority: Minor > Fix For: next-release > > > The uses HtmlUnit version is really outdated. The update seems to be simple. > If you like i can provide a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789049#comment-17789049 ] Jorge Solórzano commented on MCOMPILER-542: --- With the linked issue JDK-8318913, the behavior should change, and instead of removing the version, it should use always the specification version, I need to change the current approach to follow what the JDK is trying to do. > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > as seen in MJAR-275, JDK patch version in module-info.class is NOT included > only when building with a newer JDK release using "--release" flag, see > [https://github.com/jvm-repo-rebuild/module-info] > issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a > proper fix at javac level (probably for Java 22) > and waiting for that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define where is the best place – > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MCOMPILER-559) Warn if overriding the project's artifact's file
[
https://issues.apache.org/jira/browse/MCOMPILER-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MCOMPILER-559:
--
Description:
The use case is the following:
* a module needs to consume (unpack) another module with resources
* the consumed module thus specifies the jar goal to be run at compile time or
before
* the unpack fails because the artifact's file has been reset to
{{${basedir}/target/classes}} by the m-compiler-p
Diagnosing this problem took quite some time and debugging to understand what
was happening.
A warning in m-compiler-p to (at least) warn the user that something weird is
going on would be welcomed. The other option is to not override and warn or
reject (because compiling after the artifact has been packaged is quite
unexpected).
I'm not sure why this would be responsibility of the m-compiler-p to actually
set the artifact's file to {{${basedir}/target/classes}}, as this could also be
done by m-resource-p which also writes to that directory, or even earlier, when
starting a given project build, by maven-core itself.
was:
The use case is the following:
* a module needs to consume (unpack) another module with resources
* the consumed module thus specifies the jar goal to be run at compile time or
before
* the unpack fails because the artifact's file has been reset to
{{${basedir}/target/classes}} by the m-compiler-p
Diagnosing this problem took quite some time and debugging to understand what
was happening.
A warning in m-compiler-p to (at least) warn the user that something weird is
going on would be welcomed.
I'm not sure why this would be responsibility of the m-compiler-p to actually
set the artifact's file to {{${basedir}/target/classes}}, as this could also be
done by m-resource-p which also writes to that directory, or even earlier, when
starting a given project build, by maven-core itself.
> Warn if overriding the project's artifact's file
>
>
> Key: MCOMPILER-559
> URL: https://issues.apache.org/jira/browse/MCOMPILER-559
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Guillaume Nodet
>Priority: Major
>
> The use case is the following:
> * a module needs to consume (unpack) another module with resources
> * the consumed module thus specifies the jar goal to be run at compile time
> or before
> * the unpack fails because the artifact's file has been reset to
> {{${basedir}/target/classes}} by the m-compiler-p
> Diagnosing this problem took quite some time and debugging to understand what
> was happening.
> A warning in m-compiler-p to (at least) warn the user that something weird is
> going on would be welcomed. The other option is to not override and warn or
> reject (because compiling after the artifact has been packaged is quite
> unexpected).
> I'm not sure why this would be responsibility of the m-compiler-p to actually
> set the artifact's file to {{${basedir}/target/classes}}, as this could also
> be done by m-resource-p which also writes to that directory, or even earlier,
> when starting a given project build, by maven-core itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCOMPILER-559) Warn if overriding the project's artifact's file
[
https://issues.apache.org/jira/browse/MCOMPILER-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MCOMPILER-559:
--
Description:
The use case is the following:
* a module needs to consume (unpack) another module with resources
* the consumed module thus specifies the jar goal to be run at compile time or
before
* the unpack fails because the artifact's file has been reset to
{{${basedir}/target/classes}} by the m-compiler-p
Diagnosing this problem took quite some time and debugging to understand what
was happening.
A warning in m-compiler-p to (at least) warn the user that something weird is
going on would be welcomed.
I'm not sure why this would be responsibility of the m-compiler-p to actually
set the artifact's file to {{${basedir}/target/classes}}, as this could also be
done by m-resource-p which also writes to that directory, or even earlier, when
starting a given project build, by maven-core itself.
> Warn if overriding the project's artifact's file
>
>
> Key: MCOMPILER-559
> URL: https://issues.apache.org/jira/browse/MCOMPILER-559
> Project: Maven Compiler Plugin
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Assignee: Guillaume Nodet
>Priority: Major
>
> The use case is the following:
> * a module needs to consume (unpack) another module with resources
> * the consumed module thus specifies the jar goal to be run at compile time
> or before
> * the unpack fails because the artifact's file has been reset to
> {{${basedir}/target/classes}} by the m-compiler-p
> Diagnosing this problem took quite some time and debugging to understand what
> was happening.
> A warning in m-compiler-p to (at least) warn the user that something weird is
> going on would be welcomed.
> I'm not sure why this would be responsibility of the m-compiler-p to actually
> set the artifact's file to {{${basedir}/target/classes}}, as this could also
> be done by m-resource-p which also writes to that directory, or even earlier,
> when starting a given project build, by maven-core itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCOMPILER-559) Warn if overriding the project's artifact's file
Guillaume Nodet created MCOMPILER-559: - Summary: Warn if overriding the project's artifact's file Key: MCOMPILER-559 URL: https://issues.apache.org/jira/browse/MCOMPILER-559 Project: Maven Compiler Plugin Issue Type: Improvement Reporter: Benjamin Marwell Assignee: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MCOMPILER-542) clean JDK patch version in module-info.class
[ https://issues.apache.org/jira/browse/MCOMPILER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MCOMPILER-542: Description: as seen in MJAR-275, JDK patch version in module-info.class is NOT included only when building with a newer JDK release using "--release" flag, see [https://github.com/jvm-repo-rebuild/module-info] issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a proper fix at javac level (probably for Java 22) and waiting for that, we need a workaround to drop the JDK patch version in other cases: we'll need to define where is the best place – m-jar-p?m-compiler-p? other? was: as seen in MJAR-275, JDK patch version in module-info.class is NOT included only when building with a newer JDK release using "--release" flag, see [https://github.com/jvm-repo-rebuild/module-info] we need an issue in JDK to get a proper fix at javac level and waiting for that, we need a workaround to drop the JDK patch version in other cases: we'll need to define where is the best place – m-jar-p?m-compiler-p? other? > clean JDK patch version in module-info.class > > > Key: MCOMPILER-542 > URL: https://issues.apache.org/jira/browse/MCOMPILER-542 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.12.0 > > > as seen in MJAR-275, JDK patch version in module-info.class is NOT included > only when building with a newer JDK release using "--release" flag, see > [https://github.com/jvm-repo-rebuild/module-info] > issue [https://bugs.openjdk.org/browse/JDK-8318913] created in JDK to get a > proper fix at javac level (probably for Java 22) > and waiting for that, we need a workaround to drop the JDK patch version in > other cases: we'll need to define where is the best place – > m-jar-p?m-compiler-p? other? -- This message was sent by Atlassian Jira (v8.20.10#820010)
