[jira] [Created] (MSHADE-380) Improve FAQ for multiple runs of plugin
Gili created MSHADE-380:
---
Summary: Improve FAQ for multiple runs of plugin
Key: MSHADE-380
URL: https://issues.apache.org/jira/browse/MSHADE-380
Project: Maven Shade Plugin
Issue Type: Improvement
Reporter: Gili
https://issues.apache.org/jira/browse/MSHADE-85 provides a vague recommendation
to alter the output name to avoid a second run of the plugin from using the
output of the first run as input. In practice this is a bad workaround because
if you do this then maven-install-plugin ends up installing the non-shaded JAR
file.
A much easier and cleaner solution is to set the property of
the jar plugin as follows:
{code:java}
org.apache.maven.plugins
maven-jar-plugin
default-jar
true
{code}
Please update the recommendations in the FAQ with the above suggestion. Please
include the full code snippet to avoid any misunderstanding.
Bigger picture, the default behavior is bad. All maven plugins work properly by
default across multiple runs. This plugin does not. What prevents you from
leaving the output as foobar-shaded.jar and somehow hinting to the
maven-install-plugin to use that as input instead? I don't know the exact
implementation details, but certainly the happy path should work out of the box
without users needing to jump through any hoops.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJLINK-49) Add support for single maven projects
[ https://issues.apache.org/jira/browse/MJLINK-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215111#comment-17215111 ] Leif Gruenwoldt commented on MJLINK-49: --- I found this example just now that if I'm reading it right shows support for single maven projects works. I haven't tried it yet. https://github.com/khmarbaise/jdk9-jlink-jmod-example/tree/master/maven-single-mod > Add support for single maven projects > - > > Key: MJLINK-49 > URL: https://issues.apache.org/jira/browse/MJLINK-49 > Project: Maven JLink Plugin > Issue Type: Improvement >Affects Versions: 3.0.0-alpha-1 >Reporter: Leif Gruenwoldt >Priority: Major > > This initially took me a while to figure out, but the documentation says the > plugin currently won't work for a single maven project and requires a > multi-module project. To me this is a huge assumption for Java projects. For > example not a single one of my projects is multi-module and I rarely see > other multi-module projects, so this seems like a large limitation right now. > My work around for this limitation is to run the jlink command outside of > mvn, without the jlink plugin. But I'd love to perform the jlink step within > my pom.xml if single maven project support were added, > "Usually you will use the Maven JLink Plugin to create a Run Time Image from > one or more modules within a multi module build. In other words it is not > possible to create a Run Time Image from a single Maven Project within the > same single Maven Project. Let us assume you have a multi module structure > which contains two modules" > https://maven.apache.org/plugins/maven-jlink-plugin/usage.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4173) Remove automatic version resolution for POM plugins
[ https://issues.apache.org/jira/browse/MNG-4173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215099#comment-17215099 ] Alan Czajkowski commented on MNG-4173: -- [~bironran] based on what you've said here and in StackOverflow, your "problem" is begging for the "solution" to be: pull out the "annoying" module into its own repo/build/project, independent of the main multi-module project > Remove automatic version resolution for POM plugins > --- > > Key: MNG-4173 > URL: https://issues.apache.org/jira/browse/MNG-4173 > Project: Maven > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 3.0-alpha-3 >Reporter: Benjamin Bentmann >Priority: Major > Fix For: Issues to be reviewed for 4.x > > > Maven 3.x will no longer try to automatically find the version for plugins > specified in the POM, i.e. the effective POM must declare a version for each > plugin used for the sake of reproducible builds. Omitting the plugin version > will raise in error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MJLINK-49) Add support for single maven projects
Leif Gruenwoldt created MJLINK-49: - Summary: Add support for single maven projects Key: MJLINK-49 URL: https://issues.apache.org/jira/browse/MJLINK-49 Project: Maven JLink Plugin Issue Type: Improvement Affects Versions: 3.0.0-alpha-1 Reporter: Leif Gruenwoldt This initially took me a while to figure out, but the documentation says the plugin currently won't work for a single maven project and requires a multi-module project. To me this is a huge assumption for Java projects. For example not a single one of my projects is multi-module and I rarely see other multi-module projects, so this seems like a large limitation right now. My work around for this limitation is to run the jlink command outside of mvn, without the jlink plugin. But I'd love to perform the jlink step within my pom.xml if single maven project support were added, "Usually you will use the Maven JLink Plugin to create a Run Time Image from one or more modules within a multi module build. In other words it is not possible to create a Run Time Image from a single Maven Project within the same single Maven Project. Let us assume you have a multi module structure which contains two modules" https://maven.apache.org/plugins/maven-jlink-plugin/usage.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215061#comment-17215061
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215062#comment-17215062
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » mng-5668-poc #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/mng-5668-poc/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215048#comment-17215048
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215047#comment-17215047
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven »
MNG-6012-Missing-Profile-At-End #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6012-Missing-Profile-At-End/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215046#comment-17215046
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6554 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215045#comment-17215045
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6554 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6554/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215041#comment-17215041
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215042#comment-17215042
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-5567 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-5567/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215019#comment-17215019
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6888 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6888/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215018#comment-17215018
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6888 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6888/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215013#comment-17215013
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6550 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215012#comment-17215012
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6550 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6550/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215009#comment-17215009
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215007#comment-17215007
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6998) POM parser returns jar packaging when pom contains war packaging entry
[
https://issues.apache.org/jira/browse/MNG-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17215008#comment-17215008
]
Piotr Zygielo commented on MNG-6998:
Packaging {{war}} is set for artifactId {{cs-agent-hix-portal}} in the first
picture.
But the packaging {{jar}} marked with red line is for artifactId
{{AuditInfoBatchJob}} on the second picture.
I find it confusing.
Is it also unexpectedly {{jar}} for {{cs-agent-hix-portal}}?
> POM parser returns jar packaging when pom contains war packaging entry
> --
>
> Key: MNG-6998
> URL: https://issues.apache.org/jira/browse/MNG-6998
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.6.3
> Environment: Windows 10 64 bit, Eclipse Juno Service Release 2,
> maven-model-3.6.3.jar
>Reporter: Paul C Brown
>Priority: Minor
> Attachments: image-2020-10-15-16-36-42-820.png,
> image-2020-10-15-16-38-09-442.png
>
>
> The read() method on the MavenXpp3Reader returns a model whose packaging
> entry has the value of "jar" when the source document has the value of "war".
> Source view:
> !image-2020-10-15-16-38-09-442.png!
>
> Parsed model (output of read() method):
> !image-2020-10-15-16-36-42-820.png!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-6998) POM parser returns jar packaging when pom contains war packaging entry
Paul C Brown created MNG-6998: - Summary: POM parser returns jar packaging when pom contains war packaging entry Key: MNG-6998 URL: https://issues.apache.org/jira/browse/MNG-6998 Project: Maven Issue Type: Bug Components: POM Affects Versions: 3.6.3 Environment: Windows 10 64 bit, Eclipse Juno Service Release 2, maven-model-3.6.3.jar Reporter: Paul C Brown Attachments: image-2020-10-15-16-36-42-820.png, image-2020-10-15-16-38-09-442.png The read() method on the MavenXpp3Reader returns a model whose packaging entry has the value of "jar" when the source document has the value of "war". Source view: !image-2020-10-15-16-38-09-442.png! Parsed model (output of read() method): !image-2020-10-15-16-36-42-820.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214984#comment-17214984
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6555 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214983#comment-17214983
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6555 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6555/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[
https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214981#comment-17214981
]
Robert Scholte commented on MCOMPILER-436:
--
Well, that is the message you get, but being more explicit that is was caused
when trying to get the module name: \{{Can't extract module name from
sshd-core-2.5.1.jar: Provider class
org.apache.sshd.common.file.root.RootedFileSystemProvider not in module. }}
> Cannot compile code that depends on on Apache Mina SSH due to JPMS error
>
>
> Key: MCOMPILER-436
> URL: https://issues.apache.org/jira/browse/MCOMPILER-436
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: extract-module-name.zip
>
>
> 1. Extract Testcase
> 2. Run "mvn clean install"
> 3. Build fails with:
> [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class
> org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
> [ERROR] module not found: sshd.core
> Expected behavior: The plugin should be able to extract the module name given
> that sshd-core depends on sshd-commons which contains the aforementioned
> provider and automatic modules can access classes outside their module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] rfscholte opened a new pull request #384: [MNG-6957] Build/consumer should work with reverse module order in aggregator
rfscholte opened a new pull request #384: URL: https://github.com/apache/maven/pull/384 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214978#comment-17214978
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6553 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214977#comment-17214977
]
Hudson commented on MNG-6772:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6553 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/12/
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214979#comment-17214979
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6553 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6553/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214960#comment-17214960
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6552 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214961#comment-17214961
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6552 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6552/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[
https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214948#comment-17214948
]
Gili edited comment on MCOMPILER-436 at 10/15/20, 7:35 PM:
---
[~rfscholte] I get:
{quote}InvalidModuleDescriptorException: Provider class
org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
{quote}
which says nothing about not being able to extract a module name. Are you using
{{ModuleFinder}} to derive a module name? If so, consider changing the error
message to something along the lines of "Failed to load :
"
was (Author: cowwoc):
[~rfscholte] I get:
bq. InvalidModuleDescriptorException: Provider class
org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
which says nothing about not being able to extract a module name. Are you using
{{ModuleFinder}} to derive a module name? If so, consider changing the error
message to something along the lines of "Failed to load {filename}:
{exception.getMessage()}"
> Cannot compile code that depends on on Apache Mina SSH due to JPMS error
>
>
> Key: MCOMPILER-436
> URL: https://issues.apache.org/jira/browse/MCOMPILER-436
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: extract-module-name.zip
>
>
> 1. Extract Testcase
> 2. Run "mvn clean install"
> 3. Build fails with:
> [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class
> org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
> [ERROR] module not found: sshd.core
> Expected behavior: The plugin should be able to extract the module name given
> that sshd-core depends on sshd-commons which contains the aforementioned
> provider and automatic modules can access classes outside their module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[
https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214948#comment-17214948
]
Gili commented on MCOMPILER-436:
[~rfscholte] I get:
bq. InvalidModuleDescriptorException: Provider class
org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
which says nothing about not being able to extract a module name. Are you using
{{ModuleFinder}} to derive a module name? If so, consider changing the error
message to something along the lines of "Failed to load {filename}:
{exception.getMessage()}"
> Cannot compile code that depends on on Apache Mina SSH due to JPMS error
>
>
> Key: MCOMPILER-436
> URL: https://issues.apache.org/jira/browse/MCOMPILER-436
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: extract-module-name.zip
>
>
> 1. Extract Testcase
> 2. Run "mvn clean install"
> 3. Build fails with:
> [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class
> org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
> [ERROR] module not found: sshd.core
> Expected behavior: The plugin should be able to extract the module name given
> that sshd-core depends on sshd-commons which contains the aforementioned
> provider and automatic modules can access classes outside their module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their classpath
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214931#comment-17214931
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6909 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6909/12/
> Extensions suddenly have org.codehaus.plexus:plexus-utils:jar:1.1 on their
> classpath
>
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214930#comment-17214930
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6909 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6909/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov commented on a change in pull request #24: [MEAR-153] skinnyModules option
mabrarov commented on a change in pull request #24: URL: https://github.com/apache/maven-ear-plugin/pull/24#discussion_r505737237 ## File path: src/test/resources/projects/project-094/ear/pom.xml ## @@ -0,0 +1,100 @@ + + + +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/maven-v4_0_0.xsd;> + 4.0.0 + +ear +maven-ear-plugin-test-project-094-parent +99.0 + + maven-ear-plugin-test-project-094 + ear + + + eartest + jar-sample-three-with-deps + + + eartest + war-sample-three + war + + + eartest + sar-sample-two + sar +
[GitHub] [maven-enforcer] michael-o commented on pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
michael-o commented on pull request #79: URL: https://github.com/apache/maven-enforcer/pull/79#issuecomment-709492631 I will have a look tomorrow at it. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin edited a comment on pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
kwin edited a comment on pull request #79: URL: https://github.com/apache/maven-enforcer/pull/79#issuecomment-709488544 The test failure in Windows, Java11 with GitHub Actions at https://github.com/apache/maven-enforcer/pull/79/checks?check_run_id=1260193340 doesn't seem related to my change (`org.apache.maven.plugins.enforcer.TestEvaluateBeanshell.testRuleCanExecuteMultipleThreads()`). Also the one in Windows, Java 15ea (https://github.com/apache/maven-enforcer/pull/79/checks?check_run_id=1260193385) seems unrelated. @michael-o Let me know if I should squash the commits. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
kwin commented on pull request #79: URL: https://github.com/apache/maven-enforcer/pull/79#issuecomment-709488544 The test failure in Windows, Java11 with GitHub Actions at https://github.com/apache/maven-enforcer/pull/79/checks?check_run_id=1260193340 doesn't seem related to my change (`org.apache.maven.plugins.enforcer.TestEvaluateBeanshell.testRuleCanExecuteMultipleThreads()`). @michael-o Let me know if I should squash the commits. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[
https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214871#comment-17214871
]
Robert Scholte commented on MCOMPILER-436:
--
1. The plugin uses JDK code, the split package is not the issue, but the
service.
2. Yes, now that is illegal
3. It is a JDK message, can't be changed.
To simply check, just run the following line in JShell
{code}
java.lang.module.ModuleFinder.of(java.nio.file.Paths.get("sshd-core-2.5.1.jar")).findAll()
{code}
> Cannot compile code that depends on on Apache Mina SSH due to JPMS error
>
>
> Key: MCOMPILER-436
> URL: https://issues.apache.org/jira/browse/MCOMPILER-436
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Gili
>Priority: Major
> Attachments: extract-module-name.zip
>
>
> 1. Extract Testcase
> 2. Run "mvn clean install"
> 3. Build fails with:
> [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class
> org.apache.sshd.common.file.root.RootedFileSystemProvider not in module
> [ERROR] module not found: sshd.core
> Expected behavior: The plugin should be able to extract the module name given
> that sshd-core depends on sshd-commons which contains the aforementioned
> provider and automatic modules can access classes outside their module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214854#comment-17214854 ] Gili commented on MCOMPILER-436: Hi Robert, 1. It sounds to me like the plugin should be able to extract a module name from the JAR file even if later on that module cannot be used due to the split package issue. Therefore the first message is misleading and should be corrected. 2. Is it really illegal for a Java Module to reference a service contained in an external module? Assuming both are legal modules (no split package) this should work, right? 3. Can we improve the error message to mention that "although can be used on the classpath, it cannot be loaded on the module path due to split package found in both and "? > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214828#comment-17214828 ] Robert Scholte commented on MCOMPILER-436: -- sshd-core-2.5.1.jar contains META-INF/services/java.nio.file.spi.FileSystemProvider, saying this jar contains an implementation called org.apache.sshd.common.file.root.RootedFileSystemProvider. However, it is not sshd-core that contains this class, but sshd-common. When compiling with the module path, this is verified as well, and it just means that these jars are invalid and must be fixed by sshd. Worst solution is to turn it into a Maven multimodule project, shade both sshd jars into a new jar, and let you other module depend on that on. But as said: let sshd fix this, they created invalid jars (that might work on the classpath, but not on the modulepath anymore) > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-enforcer] michael-o commented on pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
michael-o commented on pull request #79: URL: https://github.com/apache/maven-enforcer/pull/79#issuecomment-709441621 Thanks, I will test tomorrow and merge. Ping me at 16:00 UTC if I forget this. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] michael-o commented on a change in pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
michael-o commented on a change in pull request #79:
URL: https://github.com/apache/maven-enforcer/pull/79#discussion_r505659067
##
File path:
enforcer-rules/src/test/java/org/apache/maven/plugins/enforcer/TestRequireTextFileChecksum.java
##
@@ -0,0 +1,126 @@
+package org.apache.maven.plugins.enforcer;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.io.IOException;
+import java.nio.charset.StandardCharsets;
+
+import org.apache.maven.enforcer.rule.api.EnforcerRuleException;
+import
org.apache.maven.plugins.enforcer.utils.NormalizeLineSeparatorReader.LineSeparator;
+import org.codehaus.plexus.util.FileUtils;
+import org.junit.Assert;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.rules.TemporaryFolder;
+
+/**
+ * Test the "RequireTextFileChecksum" rule
+ *
+ */
+public class TestRequireTextFileChecksum
+{
+
+private RequireTextFileChecksum rule = new RequireTextFileChecksum();
+
+@Rule
+public TemporaryFolder temporaryFolder = new TemporaryFolder();
+
+@Test
+public void testFileChecksumMd5NormalizedFromUnixToWindows()
+throws IOException, EnforcerRuleException
+{
+File f = temporaryFolder.newFile();
+FileUtils.fileWrite( f, "line1\nline2\n" );
+
+rule.setFile( f );
+rule.setChecksum( "c624cf6ccdb15a43e0e5b1a08810" );
+rule.setType( "md5" );
+rule.setNormalizeLineSeparatorTo( LineSeparator.WINDOWS );
+rule.setEncoding( StandardCharsets.US_ASCII.name() );
+
+rule.execute( EnforcerTestUtils.getHelper() );
+}
+
+@Test
+public void testFileChecksumMd5NormalizedFromWindowsToWindows()
+throws IOException, EnforcerRuleException
+{
+File f = temporaryFolder.newFile();
+FileUtils.fileWrite( f, "line1\r\nline2\r\n" );
+
+rule.setFile( f );
+rule.setChecksum( "c624cf6ccdb15a43e0e5b1a08810" );
+rule.setType( "md5" );
+rule.setNormalizeLineSeparatorTo( LineSeparator.WINDOWS );
+rule.setEncoding( StandardCharsets.US_ASCII.name() );
+
+rule.execute( EnforcerTestUtils.getHelper() );
+}
+
+@Test
+public void testFileChecksumMd5NormalizedFromWindowsToUnix()
+throws IOException, EnforcerRuleException
+{
+File f = temporaryFolder.newFile();
+FileUtils.fileWrite( f, "line1\r\nline2\r\n" );
+
+rule.setFile( f );
+rule.setChecksum( "4fcc82a88ee38e0aa16c17f512c685c9" );
+rule.setType( "md5" );
+rule.setNormalizeLineSeparatorTo( LineSeparator.UNIX );
+rule.setEncoding( StandardCharsets.US_ASCII.name() );
+
+rule.execute( EnforcerTestUtils.getHelper() );
+}
+
+@Test
+public void testFileChecksumMd5NormalizedFromUnixToUnix()
+throws IOException, EnforcerRuleException
+{
+File f = temporaryFolder.newFile();
+FileUtils.fileWrite( f, "line1\nline2\n" );
+
+rule.setFile( f );
+rule.setChecksum( "4fcc82a88ee38e0aa16c17f512c685c9" );
+rule.setType( "md5" );
+rule.setNormalizeLineSeparatorTo( LineSeparator.UNIX );
+rule.setEncoding( StandardCharsets.US_ASCII.name() );
+
+rule.execute( EnforcerTestUtils.getHelper() );
+}
+
+@Test
+public void testFileChecksumMd5NormalizedWithMissingFileCharsetPaameter()
Review comment:
Typo
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214792#comment-17214792 ] Michael Osipov commented on MCOMPILER-436: -- We should ask our expert [~rfscholte]. > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214787#comment-17214787 ] Gili edited comment on MCOMPILER-436 at 10/15/20, 3:42 PM: --- [~michael-o] You are right. The last comment was posted on the wrong JIRA issue. It was meant for the MINA developers. The corresponding bug report is https://issues.apache.org/jira/projects/SSHD/issues/SSHD-1091 That said, the following error message seems like an issue with the compiler plugin: [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class org.apache.sshd.common.file.root.RootedFileSystemProvider not in module [ERROR] module not found: sshd.core What are your thoughts on this? was (Author: cowwoc): [~michael-o] You are right. The last comment was posted on the wrong JIRA issue. It was meant for the MINA developers. That said, the following error message seems like an issue in the compiler plugin: [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class org.apache.sshd.common.file.root.RootedFileSystemProvider not in module [ERROR] module not found: sshd.core What are your thoughts on this? > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-enforcer] kwin commented on a change in pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
kwin commented on a change in pull request #79:
URL: https://github.com/apache/maven-enforcer/pull/79#discussion_r505646061
##
File path:
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireTextFileChecksum.java
##
@@ -0,0 +1,103 @@
+package org.apache.maven.plugins.enforcer;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.InputStreamReader;
+import java.io.Reader;
+import java.nio.charset.Charset;
+
+import org.apache.commons.io.input.ReaderInputStream;
+import org.apache.commons.lang3.StringUtils;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleException;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleHelper;
+import org.apache.maven.plugins.enforcer.utils.NormalizeLineSeparatorReader;
+import
org.apache.maven.plugins.enforcer.utils.NormalizeLineSeparatorReader.LineSeparator;
+import
org.codehaus.plexus.component.configurator.expression.ExpressionEvaluationException;
+
+/**
+ * Rule to validate a text file to match the specified checksum.
+ *
+ * @author Konrad Windszus
+ * @see RequireFileChecksum
+ */
+public class RequireTextFileChecksum
+extends RequireFileChecksum
+{
+private NormalizeLineSeparatorReader.LineSeparator
normalizeLineSeparatorTo = LineSeparator.UNIX;
+
+private Charset charsetEncoding;
Review comment:
Fixed in
https://github.com/apache/maven-enforcer/pull/79/commits/731853114214d25decf8c6a1eab726cd82783348.
##
File path:
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireTextFileChecksum.java
##
@@ -0,0 +1,103 @@
+package org.apache.maven.plugins.enforcer;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.InputStreamReader;
+import java.io.Reader;
+import java.nio.charset.Charset;
+
+import org.apache.commons.io.input.ReaderInputStream;
+import org.apache.commons.lang3.StringUtils;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleException;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleHelper;
+import org.apache.maven.plugins.enforcer.utils.NormalizeLineSeparatorReader;
+import
org.apache.maven.plugins.enforcer.utils.NormalizeLineSeparatorReader.LineSeparator;
+import
org.codehaus.plexus.component.configurator.expression.ExpressionEvaluationException;
+
+/**
+ * Rule to validate a text file to match the specified checksum.
+ *
+ * @author Konrad Windszus
+ * @see RequireFileChecksum
+ */
+public class RequireTextFileChecksum
+extends RequireFileChecksum
+{
+private NormalizeLineSeparatorReader.LineSeparator
normalizeLineSeparatorTo = LineSeparator.UNIX;
+
+private Charset charsetEncoding;
+
+public void setNormalizeLineSeparatorTo(
NormalizeLineSeparatorReader.LineSeparator normalizeLineSeparatorTo )
+{
+this.normalizeLineSeparatorTo = normalizeLineSeparatorTo;
+}
+
+public void setEncoding( String fileCharset )
Review comment:
https://github.com/apache/maven-enforcer/pull/79/commits/731853114214d25decf8c6a1eab726cd82783348
##
File path:
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireTextFileChecksum.java
##
@@ -0,0 +1,103 @@
+package org.apache.maven.plugins.enforcer;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF)
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214787#comment-17214787 ] Gili commented on MCOMPILER-436: [~michael-o] You are right. The last comment was posted on the wrong JIRA issue. It was meant for the MINA developers. That said, the following error message seems like an issue in the compiler plugin: [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class org.apache.sshd.common.file.root.RootedFileSystemProvider not in module [ERROR] module not found: sshd.core What are your thoughts on this? > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-enforcer] kwin commented on a change in pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
kwin commented on a change in pull request #79:
URL: https://github.com/apache/maven-enforcer/pull/79#discussion_r505635956
##
File path:
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/NormalizeLineSeparatorReader.java
##
@@ -0,0 +1,177 @@
+package org.apache.maven.plugins.enforcer.utils;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.FilterReader;
+import java.io.IOException;
+import java.io.Reader;
+
+/**
+ * Converts Unix line separators to Windows ones and vice-versa.
+ */
+public class NormalizeLineSeparatorReader
+extends FilterReader
+{
+
+private static final int EOL = -1;
+
+/**
+ * Type representing either Unix or Windows line separators
+ */
+public enum LineSeparator
+{
+WINDOWS( "\r\n", null ), UNIX( "\n", '\r' );
Review comment:
This is the second argument of the constructur which is called
`notPrecededByChar`. This is important as the check is character by character
so a `\n` might either be a unix line separator or the second half of a windows
line separator.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a change in pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
kwin commented on a change in pull request #79:
URL: https://github.com/apache/maven-enforcer/pull/79#discussion_r505639725
##
File path:
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireTextFileChecksum.java
##
@@ -0,0 +1,103 @@
+package org.apache.maven.plugins.enforcer;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.FileInputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.InputStreamReader;
+import java.io.Reader;
+import java.nio.charset.Charset;
+
+import org.apache.commons.io.input.ReaderInputStream;
+import org.apache.commons.lang3.StringUtils;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleException;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleHelper;
+import org.apache.maven.plugins.enforcer.utils.NormalizeLineSeparatorReader;
+import
org.apache.maven.plugins.enforcer.utils.NormalizeLineSeparatorReader.LineSeparator;
+import
org.codehaus.plexus.component.configurator.expression.ExpressionEvaluationException;
+
+/**
+ * Rule to validate a text file to match the specified checksum.
+ *
+ * @author Konrad Windszus
+ * @see RequireFileChecksum
+ */
+public class RequireTextFileChecksum
+extends RequireFileChecksum
+{
+private NormalizeLineSeparatorReader.LineSeparator
normalizeLineSeparatorTo = LineSeparator.UNIX;
+
+private Charset charsetEncoding;
+
+public void setNormalizeLineSeparatorTo(
NormalizeLineSeparatorReader.LineSeparator normalizeLineSeparatorTo )
+{
+this.normalizeLineSeparatorTo = normalizeLineSeparatorTo;
+}
+
+public void setEncoding( String fileCharset )
+{
+this.charsetEncoding = Charset.forName( fileCharset );
+}
+
+@Override
+public void execute( EnforcerRuleHelper helper )
+throws EnforcerRuleException
+{
+// set defaults
+if ( charsetEncoding == null )
+{
+//
https://maven.apache.org/plugins/maven-resources-plugin/examples/encoding.html
+try
+{
+String encoding = (String) helper.evaluate(
"${project.build.sourceEncoding}" );
+if ( StringUtils.isBlank( encoding ) )
+{
+throw new EnforcerRuleException( "No encoding set for
'${project.build.sourceEncoding}'" );
+}
+this.charsetEncoding = Charset.forName( encoding );
+}
+catch ( ExpressionEvaluationException e )
+{
+throw new EnforcerRuleException( "Unable to retrieve the
project's build source encoding "
++ "(${project.build.sourceEncoding}): ", e );
+}
+}
+super.execute( helper );
+}
+
+@Override
+protected String calculateChecksum()
+throws EnforcerRuleException
+{
+try ( FileInputStream fileInputStream = new FileInputStream( this.file
);
Review comment:
Good point, gonna simplify, left-over from refactoring.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] michael-o commented on a change in pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
michael-o commented on a change in pull request #79:
URL: https://github.com/apache/maven-enforcer/pull/79#discussion_r505637537
##
File path:
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/NormalizeLineSeparatorReader.java
##
@@ -0,0 +1,177 @@
+package org.apache.maven.plugins.enforcer.utils;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.FilterReader;
+import java.io.IOException;
+import java.io.Reader;
+
+/**
+ * Converts Unix line separators to Windows ones and vice-versa.
+ */
+public class NormalizeLineSeparatorReader
+extends FilterReader
+{
+
+private static final int EOL = -1;
+
+/**
+ * Type representing either Unix or Windows line separators
+ */
+public enum LineSeparator
+{
+WINDOWS( "\r\n", null ), UNIX( "\n", '\r' );
Review comment:
Ah thanks!
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a change in pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
kwin commented on a change in pull request #79:
URL: https://github.com/apache/maven-enforcer/pull/79#discussion_r505635956
##
File path:
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/utils/NormalizeLineSeparatorReader.java
##
@@ -0,0 +1,177 @@
+package org.apache.maven.plugins.enforcer.utils;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.FilterReader;
+import java.io.IOException;
+import java.io.Reader;
+
+/**
+ * Converts Unix line separators to Windows ones and vice-versa.
+ */
+public class NormalizeLineSeparatorReader
+extends FilterReader
+{
+
+private static final int EOL = -1;
+
+/**
+ * Type representing either Unix or Windows line separators
+ */
+public enum LineSeparator
+{
+WINDOWS( "\r\n", null ), UNIX( "\n", '\r' );
Review comment:
This is the second argument of the constructur which is called
`notPrecededByChar`. This is important as the check is character by character
so a `\n' might either be a unix line separator or the second half of a windows
line separator.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MCOMPILER-436) Cannot compile code that depends on on Apache Mina SSH due to JPMS error
[ https://issues.apache.org/jira/browse/MCOMPILER-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17214779#comment-17214779 ] Michael Osipov commented on MCOMPILER-436: -- I am confused, if you say it contains split packages, shouldn't it be handled by the MINA project rather? > Cannot compile code that depends on on Apache Mina SSH due to JPMS error > > > Key: MCOMPILER-436 > URL: https://issues.apache.org/jira/browse/MCOMPILER-436 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.8.1 >Reporter: Gili >Priority: Major > Attachments: extract-module-name.zip > > > 1. Extract Testcase > 2. Run "mvn clean install" > 3. Build fails with: > [WARNING] Can't extract module name from sshd-core-2.5.1.jar: Provider class > org.apache.sshd.common.file.root.RootedFileSystemProvider not in module > [ERROR] module not found: sshd.core > Expected behavior: The plugin should be able to extract the module name given > that sshd-core depends on sshd-commons which contains the aforementioned > provider and automatic modules can access classes outside their module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov edited a comment on pull request #24: [MEAR-153] skinnyModules option
mabrarov edited a comment on pull request #24: URL: https://github.com/apache/maven-ear-plugin/pull/24#issuecomment-709352543 We may need to update documentation of Maven EAR Plugin with detailed description of skinnyModules option, its connection with skinnyWars option and with examples for skinnyModules option and libDirectory property of EAR module. All these things are visible in the new integration tests added in this 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov edited a comment on pull request #24: [MEAR-153] skinnyModules option
mabrarov edited a comment on pull request #24: URL: https://github.com/apache/maven-ear-plugin/pull/24#issuecomment-709352543 We may need to update documentation of Maven EAR Plugin with detailed description of skinnyModules option, its connection with skinnyWars option and with examples for skinnyModules option and libDirectory property of EAR module. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #24: [MEAR-153] skinnyModules option
mabrarov commented on pull request #24: URL: https://github.com/apache/maven-ear-plugin/pull/24#issuecomment-709352543 We may need to update documentation of Maven EAR Plugin with detail description of skinnyModules option, its connection with skinnyWars option and with examples for skinnyModules option and libDirectory property of EAR module. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #24: [MEAR-153] skinnyModules option
mabrarov commented on pull request #24: URL: https://github.com/apache/maven-ear-plugin/pull/24#issuecomment-709345711 @elharo, I do not plan any further work on or testing of these changes. Could you please trigger Jenkins build and review this pull request? Please note that these changes also fix backward incompatibility introduced by MEAR-267 (by pull request #19 ) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] michael-o commented on pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
michael-o commented on pull request #79: URL: https://github.com/apache/maven-enforcer/pull/79#issuecomment-709264898 Right, even on UTF-16 it will be four bytes for `\r\n`. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on pull request #79: [MENFORCER-361] optionally normalize line separators prior to checksum calculation
kwin commented on pull request #79:
URL: https://github.com/apache/maven-enforcer/pull/79#issuecomment-709208909
Ok, will modify the PR accordingly. Notice though that the character
encoding configuration is mandatory though (but I will use
`${project.build.sourceEncoding}` by default)
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov edited a comment on pull request #24: [MEAR-153] skinnyModules option
mabrarov edited a comment on pull request #24: URL: https://github.com/apache/maven-ear-plugin/pull/24#issuecomment-709182701 We need smbd to test skinny RAR, HAR and SAR - I have no code with this kind of EAR modules to ensure that skinny RAR, HAR and SAR works correctly, i.e. are deployed with the same success level as non-skinny. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #24: [MEAR-153] skinnyModules option
mabrarov commented on pull request #24: URL: https://github.com/apache/maven-ear-plugin/pull/24#issuecomment-709182701 We need smbd to test skinny RAR, HAR and SAR - I have no code with this kind of EAR modules to ensure that skinny RAR, HAR and SAR works correctly, i.e. are deployed with the same success state as non-skinny. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-common-artifact-filters] elharo merged pull request #14: deps: update JUnit
elharo merged pull request #14: URL: https://github.com/apache/maven-common-artifact-filters/pull/14 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] elharo commented on pull request #22: [MEAR-216] Handling test JARs as regular JARs
elharo commented on pull request #22: URL: https://github.com/apache/maven-ear-plugin/pull/22#issuecomment-709123049 https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-ear-plugin/job/mear-216/ 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] krmahadevan commented on pull request #311: doc suiteXmlFiles param incompatible with JUnit
krmahadevan commented on pull request #311: URL: https://github.com/apache/maven-surefire/pull/311#issuecomment-709113444 @juherr - Yep. You are correct. CLI and suite files are supposed to be mutually exclusive to each other and should not interfere with each other. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] juherr commented on pull request #311: doc suiteXmlFiles param incompatible with JUnit
juherr commented on pull request #311: URL: https://github.com/apache/maven-surefire/pull/311#issuecomment-708933324 Hi, In fact, the CLI attributes are used to build a suite when none is passed. Then the `junit` attribute only configure the value for the current CLI suite. When `suiteXMLFiles` is used, you passe suites where the `junit` attribute is already expected (on `` or ``). If I'm right, the CLI attributes are not supposed to override values from the suites. @krmahadevan Do you confirm? 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
