[GitHub] [maven-script-interpreter] dependabot[bot] opened a new pull request #32: Bump actions/cache from v2.1.2 to v2.1.3
dependabot[bot] opened a new pull request #32: URL: https://github.com/apache/maven-script-interpreter/pull/32 Bumps [actions/cache](https://github.com/actions/cache) from v2.1.2 to v2.1.3. Release notes Sourced from https://github.com/actions/cache/releases;>actions/cache's releases. v2.1.3 Upgrades @actions/core to v1.2.6 for https://github.com/advisories/GHSA-mfwh-5m23-j46w;>CVE-2020-15228. This action was not using the affected methods. Fix error handling in uploadChunk where 400-level errors were not being detected and handled correctly Commits https://github.com/actions/cache/commit/0781355a23dac32fd3bac414512f4b903437991a;>0781355 Upgrade @actions/cache to 1.0.4 (https://github-redirect.dependabot.com/actions/cache/issues/451;>#451) https://github.com/actions/cache/commit/22c64ac7729165b59327d9275351548a32cbd312;>22c64ac Update @actions/core to 1.2.6 (https://github-redirect.dependabot.com/actions/cache/issues/449;>#449) https://github.com/actions/cache/commit/8819edf4767ca1eef30abb52c04026c00c4988f5;>8819edf Update to @actions/cache 1.0.3 (https://github-redirect.dependabot.com/actions/cache/issues/438;>#438) See full diff in https://github.com/actions/cache/compare/v2.1.2...0781355a23dac32fd3bac414512f4b903437991a;>compare view Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) 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] (SUREFIRE-1584) Rerun Failing Tests with JUnit 5
[ https://issues.apache.org/jira/browse/SUREFIRE-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228329#comment-17228329 ] Christopher Tubbs commented on SUREFIRE-1584: - [~tibordigana], my comment contained a conditional: "*If*..."... because I don't know what wording would be correct. I was just trying to bring something to the attention of somebody who knows what it *should* say (which is not me), so they can update it. > Rerun Failing Tests with JUnit 5 > > > Key: SUREFIRE-1584 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1584 > Project: Maven Surefire > Issue Type: New Feature > Components: JUnit 5.x support, Maven Surefire Report Plugin >Affects Versions: 2.22.0 >Reporter: Tic Tac >Assignee: Tibor Digana >Priority: Major > Labels: junit5 > Fix For: 3.0.0-M4 > > Attachments: FlakyReruns.png > > > The very useful feature for integration tests ¨[Rerun Failing > Tests|https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html]¨ > is currently only supported for the very outdated JUnit 4. > The documentation says: ¨This feature is supported only for JUnit 4.x.¨ > Can you please support this feature for JUnit 5.3 or later? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-integration-testing] michael-o commented on pull request #75: [MNG-6890] MavenITmng5669ReadPomsOnce is unreliable
michael-o commented on pull request #75: URL: https://github.com/apache/maven-integration-testing/pull/75#issuecomment-723700390 I can't wrap my head around it. Regardless of what I do, at least one plugin cannot be resolved eventhough it is present in the local repo. Any ideas? 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-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228294#comment-17228294 ] Michael Osipov commented on MNG-6754: - It is crucially importatant that between deployment at least one second elapses. > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.7.0-candidate > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228292#comment-17228292 ] Michael Osipov commented on MNG-6754: - Thanks for looking into. I would do the following. First of all, have project of yours to print mavenBuildTimestamp and deploy artifacts. All timestamps maven + those from metadata files should match. When they visually match you can build your IT around writing out the maven build timestamp and compare them. As far as I understand the code it is the same value as I use for metadata. Does this suffice? > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.7.0-candidate > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-integration-testing] michael-o commented on pull request #75: [MNG-6890] MavenITmng5669ReadPomsOnce is unreliable
michael-o commented on pull request #75: URL: https://github.com/apache/maven-integration-testing/pull/75#issuecomment-723672542 This is a bit funnier that I thought. Other tests blindly relied on default versions now they aren't there. Will take a bit longer. Where you able to figure out why the list is longer now? 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-integration-testing] michael-o commented on pull request #75: [MNG-6890] MavenITmng5669ReadPomsOnce is unreliable
michael-o commented on pull request #75: URL: https://github.com/apache/maven-integration-testing/pull/75#issuecomment-723667686 Nice catch, let me fix that. 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-integration-testing] rfscholte commented on pull request #75: [MNG-6890] MavenITmng5669ReadPomsOnce is unreliable
rfscholte commented on pull request #75: URL: https://github.com/apache/maven-integration-testing/pull/75#issuecomment-723666432 `org.apache.maven.plugin.PluginResolutionException: Plugin org.apache.maven.plugins:maven-resources-plugin:3.2.0 or one of its dependencies could not be resolved: Could not find artifact org.apache.maven.plugins:maven-resources-plugin:jar:3.2.0 in central (file:target/null)` core-it-suite tries to run with an isolated repository, tests should use dependencies defined in bootstrap, otherwise you'll get this failure. I'd suggest to use the versions as defined in `bootstrap/pom.xml` 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-6754) Set the same timestamp in multi module builds
[ https://issues.apache.org/jira/browse/MNG-6754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228284#comment-17228284 ] Maarten Mulders commented on MNG-6754: -- I'm willing to give this a try. Just not sure what property to look at for verification purposes. Could you give me a hint there, [~michael-o]? > Set the same timestamp in multi module builds > - > > Key: MNG-6754 > URL: https://issues.apache.org/jira/browse/MNG-6754 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.6.3 >Reporter: Michael Angstadt >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.7.0-candidate > > > When multi module snapshots are built using Maven, the version timestamp may > be different for each module. This makes it difficult to quickly reference a > historical snapshot of a multi module project, which is something we might do > when determining when a bug was introduced. > [This Stack Overflow question|https://stackoverflow.com/q/45629816/2048802] > provides a good example of the problem. [The accepted > answer|https://stackoverflow.com/a/45715820/2048802] seems like a reasonable > solution, but does not appear to work. [Looking at the > code|https://github.com/apache/maven/blob/d9a0eee7fe2e2b1d77e59cf5bc772e758d29e47d/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/RemoteSnapshotMetadata.java#L85], > there does not appear to be a way to override the timestamp. > Please add a way to use a consistent timestamp for all modules in a build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOLVER-146) method to get artifact publication date
[
https://issues.apache.org/jira/browse/MRESOLVER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228279#comment-17228279
]
Michael Osipov commented on MRESOLVER-146:
--
This is a very good example for a very bad versioning scheme we cannot help
with. Publication dates cannot be trusted also because you could have the
following release order: 1.1.0, 1.1.1, 1.2.0, 1.1.2, 1.1.3, 1.2.1, 1.3.0.,
1.2.2, etc. The date will fool you.
The the information must be a transport-agnostic metadatum otherwise I see no
chance, it has to be carried through ALL layers. Optional or not, it has to be
implemented somehow. The only option I see is something like a {{.date}} side
file for signatures or checksums.
I rather recommend to inspect {{project.build.outputTimestamp}} from a
project's POM. This will give you the information you need, everything else is
just unrealisting for the time to come.
> method to get artifact publication date
> ---
>
> Key: MRESOLVER-146
> URL: https://issues.apache.org/jira/browse/MRESOLVER-146
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Th Stock
>Priority: Major
>
> I'm looking for a method to get the date of artifact publication in
> org.eclipse.aether.RepositorySystem
> e.g.
> "org.apache.maven.resolver" % "maven-resolver-api" % "1.6.1" => 2020-10-02
> 18:05
> https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-api/1.6.1/
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-146) method to get artifact publication date
[ https://issues.apache.org/jira/browse/MRESOLVER-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228277#comment-17228277 ] Th Stock commented on MRESOLVER-146: I use maven-resolver to find newer versions of used artifacts like maven-versions-plugin ([https://www.mojohaus.org/versions-maven-plugin/examples/display-dependency-updates.html]) org.eclipse.aether.RepositorySystem#resolveVersionRange in some cases it is not enough to use the version number only if i want to order versions like this e.g (3.0-8a09def, 3.0-f471c52, 3.0.0-M2) You could argue that it is up to the projects to choose comparable versions, but there is also a fallback value if version ordering is difficult: publication date. Another benefit could be a metric for outdated artifacts that can be found for languages like dotnet, php, js, python, ruby see: [https://ericbouwers.github.io/papers/icse15.pdf] / [https://libyear.com/] It is required that the information must be transport-argnostic? What about an optional value if date can be found - use it. > method to get artifact publication date > --- > > Key: MRESOLVER-146 > URL: https://issues.apache.org/jira/browse/MRESOLVER-146 > Project: Maven Resolver > Issue Type: Task >Reporter: Th Stock >Priority: Major > > I'm looking for a method to get the date of artifact publication in > org.eclipse.aether.RepositorySystem > e.g. > "org.apache.maven.resolver" % "maven-resolver-api" % "1.6.1" => 2020-10-02 > 18:05 > https://repo1.maven.org/maven2/org/apache/maven/resolver/maven-resolver-api/1.6.1/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-integration-testing] michael-o commented on pull request #75: [MNG-6890] MavenITmng5669ReadPomsOnce is unreliable
michael-o commented on pull request #75: URL: https://github.com/apache/maven-integration-testing/pull/75#issuecomment-723653020 > that's a huge difference in numbers, let me check I was surprised too, please do so. 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-integration-testing] rfscholte commented on pull request #75: [MNG-6890] MavenITmng5669ReadPomsOnce is unreliable
rfscholte commented on pull request #75: URL: https://github.com/apache/maven-integration-testing/pull/75#issuecomment-723652802 that's a huge difference in numbers, let me check 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-integration-testing] michael-o opened a new pull request #75: [MNG-6890] MavenITmng5669ReadPomsOnce is unreliable
michael-o opened a new pull request #75: URL: https://github.com/apache/maven-integration-testing/pull/75 Add explicit plugin versions for solve instability. 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] [Assigned] (MNG-6890) MavenITmng5669ReadPomsOnce is unreliable
[
https://issues.apache.org/jira/browse/MNG-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6890:
---
Assignee: Michael Osipov (was: Robert Scholte)
> MavenITmng5669ReadPomsOnce is unreliable
>
>
> Key: MNG-6890
> URL: https://issues.apache.org/jira/browse/MNG-6890
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Affects Versions: 3.7.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The unreliability comes from the fact that no plugin has been fixed (version)
> in the parent POM of the test project. As soon as you update Maven from
> MNG-6169 the test starts to fail that lengths do not match. So this test
> relies on implicit declaration of plugin versions.
> Reproducer:
> 1. Build Maven from MNG-6169/MNG-6551
> 2. Run ITs from MNG-6551
> 3. See it fail
> One needs to remove {{-q}}, scan for plugins and fix their versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6548) Lifecycle plugin version upgrades
[ https://issues.apache.org/jira/browse/MNG-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228264#comment-17228264 ] Hudson commented on MNG-6548: - Build unstable in Jenkins: Maven » Maven TLP » maven » master #47 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/47/ > Lifecycle plugin version upgrades > - > > Key: MNG-6548 > URL: https://issues.apache.org/jira/browse/MNG-6548 > Project: Maven > Issue Type: Improvement > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.7.0 > > > Regular plugin upgrades to absorb changes if plugin version is not specified > in the client POM. > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/lifecycles.html]||target > version|| > |org.apache.maven.plugins|maven-clean-plugin|2.5|3.1.0| > |org.apache.maven.plugins|maven-site-plugin|3.3|3.9.1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6968) Maven depends on ancient maven-site-plugin - upgrade dependency
[ https://issues.apache.org/jira/browse/MNG-6968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6968. --- Fix Version/s: 3.7.0 Resolution: Fixed Resolved by MNG-6548. > Maven depends on ancient maven-site-plugin - upgrade dependency > --- > > Key: MNG-6968 > URL: https://issues.apache.org/jira/browse/MNG-6968 > Project: Maven > Issue Type: Bug >Reporter: Graham Leggett >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > > The maven release plugin (MRELEASE-1052) currently ignores versions of > plugins specified in the POM, and in a pattern as yet not clearly explained > chooses maven plugins hardcoded into maven itself. > One such plugin is the maven-site-plugin, which is the POM specified version > in a normal build, but hard coded to the ancient v3.3 plugin when triggered > from the maven-release-plugin. > Chaos ensues: > https://mkyong.com/maven/mvn-site-java-lang-classnotfoundexception-org-apache-maven-doxia-siterenderer-documentcontent/ > https://stackoverflow.com/questions/51091539/maven-site-plugins-3-3-java-lang-classnotfoundexception-org-apache-maven-doxia > https://issues.apache.org/jira/browse/CRUNCH-671 > https://stackoverflow.com/questions/51103120/why-does-maven-site-plugin-always-use-version-3-3 > Digging leads us to this commit: > https://github.com/apache/maven/commit/4ec06bf67cc6bdffa026f46c5836e3bc895865ed > Looks like until maven is fixed to respect the POM, we need to upgrade the > hard coded dependencies to be something not ancient. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6717) mvn site build of archtype project throughs error
[
https://issues.apache.org/jira/browse/MNG-6717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6717.
---
Fix Version/s: (was: 3.7.0-candidate)
3.7.0
Resolution: Fixed
Resolved by MNG-6548.
> mvn site build of archtype project throughs error
> -
>
> Key: MNG-6717
> URL: https://issues.apache.org/jira/browse/MNG-6717
> Project: Maven
> Issue Type: Bug
> Components: Documentation: Guides
>Affects Versions: 3.6.1
> Environment: $ mvn -version
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555;
> 2019-04-04T21:00:29+02:00)
> Java version: 1.8.0_111, vendor: Oracle Corporation
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Rudolf Starosta
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.7.0
>
>
> Following the steps in the Maven tutorial,
> [https://maven.apache.org/guides/getting-started/]
>
> I created a project with
> {code:java}
> mvn -B archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DgroupId=com.mycompany.app
> -DartifactId=my-app
> {code}
> Trying to use "one of the highly prized features of Maven" namely
> {code:java}
> mvn site
> {code}
> I got
> {code:java}
> [INFO]
>
>
> [INFO] BUILD FAILURE
>
> [INFO]
>
>
> [INFO] Total time: 2.363 s
>
> [INFO] Finished at: 2019-07-23T07:52:37+02:00
>
> [INFO]
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project
> my-app: Executio
> n default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site
> failed: A required class was missing while executi
> ng org.apache.maven.plugins:maven-site-plugin:3.3:site:
> org/apache/maven/doxia/siterenderer/DocumentContent
> [ERROR] -
>
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-site-plugin:3.3
>
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
>
> [ERROR] urls[0] =
> file:/C:/Users/rudolfstarosta/.m2/repository/org/apache/maven/plugins/maven-site-plugin/3.3/maven-site-plug
> in-3.3.jar
> [...]
>
> {code}
>
> Expected result: mvn builds a web site with the project information.
>
--
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=17228246#comment-17228246
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> 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-6981) Add --recursive option
[
https://issues.apache.org/jira/browse/MNG-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228251#comment-17228251
]
Hudson commented on MNG-6981:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Add --recursive option
> --
>
> Key: MNG-6981
> URL: https://issues.apache.org/jira/browse/MNG-6981
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.6.3
>Reporter: Knut Wannheden
>Assignee: Martin Kanters
>Priority: Minor
> Fix For: 3.7.0
>
>
> Since there is already a {{\--non-recursive}} option a new {{\--recursive}}
> option might be confusing, but let me explain my use case. I often use the
> {{-pl}} option and in a multi-module Maven project with more than just two
> "levels", I would like to be able to build a project (or set of projects)
> including all child-modules. This is, AFAIK, currently not possible and what
> I would like to use the new {{\--recursive}} (or similar) option for.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6964) Maven version sorting is internally inconsistent
[
https://issues.apache.org/jira/browse/MNG-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228237#comment-17228237
]
Hudson commented on MNG-6964:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Maven version sorting is internally inconsistent
>
>
> Key: MNG-6964
> URL: https://issues.apache.org/jira/browse/MNG-6964
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: David M. Lloyd
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 3.7.0
>
>
> There's a bug where version sorting is inconsistent. This manifests like this:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.alpha 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.alpha == 1-0.alpha
>1-0.alpha == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta 1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta == 1
> 2. 1 == 1
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.beta
> 1-0.alpha
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.beta == 1-0.beta
>1-0.beta > 1-0.alpha
> 2. 1-0.alpha == 1-0.alpha
> {code}
> Thus there is no correct total order: {{1-0.beta > 1.0.alpha}} even though
> both {{1-0.beta}} and {{1-0.alpha}} are equal to {{1}}.
> I think this is likely due to a logical bug where any dot-separated segments
> following a zero or release ({{ga}} or {{final}}) is simply truncated in
> certain circumstances:
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x 1-0
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x == 1-0.x
>1-0.x == 1-0
> 2. 1-0 == 1
> {code}
> but
> {code:java}
> $ java -jar ~/local/apache-maven/lib/maven-artifact-3.6.3.jar 1-0.x-1 1-0-1
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1-0.x-1 == 1-0.x-1
>1-0.x-1 > 1-0-1
> 2. 1-0-1 == 1-1
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6952) Fail fast if pom cannot be transformed
[
https://issues.apache.org/jira/browse/MNG-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228235#comment-17228235
]
Hudson commented on MNG-6952:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Fail fast if pom cannot be transformed
> --
>
> Key: MNG-6952
> URL: https://issues.apache.org/jira/browse/MNG-6952
> Project: Maven
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.7.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: fixed before release
>
>
> {{maven-antrun-plugin\target\it\attach-artifact-test-with-prefix}} fails with
> the build/consumer.
> The pom contains this:
> {code:xml}
>
> mvn
>
>
>
>
> {code}
> And fails during {{install:install}} with
> {noformat}
> org.xml.sax.SAXParseException; lineNumber: 44; columnNumber: 71; The prefix
> "mvn" for element "mvn:attachartifact" is not bound.
> {noformat}
> It is fine that Maven complains about invalid XML, but during install is too
> late.
> It should happen not at all, or already while making the buildplan.
> If inheritence of such configuration still works, I'd prefer to break the
> build early.
> The proper fix is to make it valid XML, by specifying the namespace like this:
> {code:xml}
>
> mvn
>
>
>
>
> {code}
> This already works (even with Maven 3.0), and ideally maven-antrun-plugin
> also provides an XSD, so it can be validated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6993) Upgrade SLF4J to 1.7.30
[ https://issues.apache.org/jira/browse/MNG-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228245#comment-17228245 ] Hudson commented on MNG-6993: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Upgrade SLF4J to 1.7.30 > --- > > Key: MNG-6993 > URL: https://issues.apache.org/jira/browse/MNG-6993 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.6.3 >Reporter: Slawomir Jaranowski >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > > Resolved issue: > https://jira.qos.ch/browse/SLF4J-469 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6944) 881274914a80946f8af6e435eff064d3c89974fa introduces regression
[
https://issues.apache.org/jira/browse/MNG-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228231#comment-17228231
]
Hudson commented on MNG-6944:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> 881274914a80946f8af6e435eff064d3c89974fa introduces regression
> --
>
> Key: MNG-6944
> URL: https://issues.apache.org/jira/browse/MNG-6944
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.7.0
>Reporter: Michael Osipov
>Assignee: Robert Scholte
>Priority: Blocker
>
> When tests are run on OpenJDK 11+:
> {noformat}
> $ mvn -v
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: /usr/local/apache-maven-3.5.4
> Java version: 11.0.7, vendor: Oracle Corporation, runtime:
> /usr/local/openjdk11
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "12.1-stable", arch: "amd64", family: "unix"
> {noformat}
> I see the following failure:
> {noformat}
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] DefaultLifecyclesTest.testCustomLifecycle:116
> Expected: is "clean"
> but: was "site"
> [INFO]
> [ERROR] Tests run: 359, Failures: 1, Errors: 0, Skipped: 1
> {noformat}
> {{git bisect}} points to:
> {noformat}
> $ git bisect bad
> 881274914a80946f8af6e435eff064d3c89974fa is the first bad commit
> commit 881274914a80946f8af6e435eff064d3c89974fa
> Author: rfscholte
> Date: Mon Jun 22 20:26:56 2020 +0200
> [MNG-6917] Introduce wrapper lifecycle
> .../apache/maven/lifecycle/DefaultLifecycles.java | 83 ++--
> .../main/resources/META-INF/plexus/components.xml | 20 +
> .../maven/lifecycle/DefaultLifecyclesTest.java | 90
> ++
> .../maven/lifecycle/LifecycleExecutorTest.java | 14 ++--
> .../internal/stub/DefaultLifecyclesStub.java | 4 +-
> .../stub/LifecycleExecutionPlanCalculatorStub.java | 4 +
> 6 files changed, 153 insertions(+), 62 deletions(-)
> {noformat}
> It does not fail with:
> {noformat}
> $ mvn -v
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
> 2018-06-17T20:33:14+02:00)
> Maven home: /usr/local/apache-maven-3.5.4
> Java version: 1.8.0_252, vendor: The FreeBSD Project, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "12.1-stable", arch: "amd64", family: "unix"
> {noformat}
> and fails also with:
> {noformat}
> $ ~/apache-maven-3.6.3/bin/mvn -v clean verify -Drat.skip
> Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> Maven home: /net/home/osipovmi/apache-maven-3.6.3
> Java version: 11.0.7, vendor: Oracle Corporation, runtime:
> /usr/local/openjdk11
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "12.1-stable", arch: "amd64", family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6948) Repository files should not pass build-filters
[
https://issues.apache.org/jira/browse/MNG-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228233#comment-17228233
]
Hudson commented on MNG-6948:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Repository files should not pass build-filters
> --
>
> Key: MNG-6948
> URL: https://issues.apache.org/jira/browse/MNG-6948
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.7.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
>
> When building Models, only reactor poms should go through the build xml
> filters.
> If all poms go through it, there will be an unnecesary resource lost, and it
> might introduce security issues, because not all pomsin the local repository
> seem to be valid.
> One symptom is that once the poms are collected, you might see the following
> line:
> {noformat}ERROR: 'The entity "oslash" was referenced, but not
> declared.'{noformat}
> One of the poms with this issue is the {{org.codehaus.plexus:1.0.5:pom}},
> which contains:
> {code:xml}
>
> Trygve Laugstl
> trygvis
> tryg...@codehaus.org
>
> Developer
>
>
> {code}
> However, the is not registered in the file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6656) Introduce base for build/consumer process
[
https://issues.apache.org/jira/browse/MNG-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228230#comment-17228230
]
Hudson commented on MNG-6656:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Introduce base for build/consumer process
> -
>
> Key: MNG-6656
> URL: https://issues.apache.org/jira/browse/MNG-6656
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: MNG-6656.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pom.xml as we know it has reached it limits, but it is quite hard to do
> improvements as long as the local pom (as part of the sources) is exactly the
> same as the file being published.
> For the Maven eco system it is important that the published file will still
> be a model 4.0.0 to ensure other projects can still depend on these artifacts.
> This will be a first step to separate the local pom from the remote pom. The
> process to come to the effective pom will change a little bit
> pre-build
> pom.xml (raw model) -> BuildPomXMLFilter -> inheritence -> effective pom/model
> This means that we can enrich the pom to make it a valid effective pom again.
> In this case we can do the following:
> - resolve the [cifriendly
> placeholders|https://maven.apache.org/maven-ci-friendly.html], so it will
> work in multimodules too.
> - resolve parent-version. By removing the version from the parent, the filter
> will get the version based on the relativePath. If the groupId and artifactId
> don't match, the version can't be solved and Maven will fail with a missing
> version for the parent.
> - resolve reactor versions. By removing the versions from reactor
> dependencies, the filter will look up the matching version. If there's no
> version for the groupId+artifactId, the version can't be solved and Maven
> will fail with a missing version for the dependency.
> pre-distribution (install/deploy)
> pom.xml -> BuildPomXMLFilter -> ConsumerPomXMLFilter -> consumer pom
> This means that the XML used to build build the effective pom is used, and
> can be adjusted during copy/upload.
> In this case we can do the following:
> - Remove the modules -elements, since this is local path information and not
> useful after building
> - Remove the relativePath-element, since this is local path information and
> not useful after building
> This PoC has the following goals:
> - It will give us experience with manipuating files before build AND during
> install/deploy.
> - We can see IDEs and CI servers can handle this and how we can move forward.
> This feature will at first be disabled by default and can be activated with
> the System property {{maven.experimental.buildconsumer=true}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6118) Add option to execute goals on a specific module while building a multimodule project
[
https://issues.apache.org/jira/browse/MNG-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228249#comment-17228249
]
Hudson commented on MNG-6118:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Add option to execute goals on a specific module while building a multimodule
> project
> -
>
> Key: MNG-6118
> URL: https://issues.apache.org/jira/browse/MNG-6118
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 3.7.0
>
>
> Suppose we have a multimodule which results in a war. In the end we want to
> run this war in a container like jetty. Up until now the {{jetty:run}} is
> executed on every module, which doesn't make sense for the other modules.
> This is just one of several examples where you want to control on which
> module to execute a specific goal. In case of wars, the plugin could check
> for the packaging type, but in case of jars this won't work.
> There should be a generic solution to mark goals for a specific module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6996) Upgrade Maven Resolver to 1.6.1
[ https://issues.apache.org/jira/browse/MNG-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228247#comment-17228247 ] Hudson commented on MNG-6996: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Upgrade Maven Resolver to 1.6.1 > --- > > Key: MNG-6996 > URL: https://issues.apache.org/jira/browse/MNG-6996 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > > Release Notes - Maven Resolver - Version 1.6.1 > ** Sub-task > * [MRESOLVER-139] - Make SimpleDigest use SHA-1 or MD5 only > * [MRESOLVER-140] - Default to SHA-1 and MD5 hashing algorithms > ** Bug > * [MRESOLVER-25] - Resume support is broken under high concurrency > * [MRESOLVER-114] - ArtifactNotFoundExceptions when building in parallel > * [MRESOLVER-129] - Exclusion has no setters > * [MRESOLVER-137] - Make OSGi bundles reproducible > * [MRESOLVER-138] - MRESOLVER-56 introduces severe performance regression > ** New Feature > * [MRESOLVER-109] - AndDependencySelector should override toString > * [MRESOLVER-115] - Make checksum algorithms configurable > * [MRESOLVER-123] - Provide a global locking sync context by default > * [MRESOLVER-131] - Introduce a Redisson-based SyncContextFactory > ** Improvement > * [MRESOLVER-56] - Support SHA-256 and SHA-512 as checksums > * [MRESOLVER-116] - Add page with all supported configuration options > * [MRESOLVER-125] - Use type conversions returning primitives > * [MRESOLVER-127] - Don't use boolean for property > 'aether.updateCheckManager.sessionState' > * [MRESOLVER-136] - Migrate from maven-bundle-plugin to bnd-maven-plugin > ** Task > * [MRESOLVER-119] - Turn log messages to SLF4J placeholders > * [MRESOLVER-130] - Move GlobalSyncContextFactory to a separate module > * [MRESOLVER-132] - Remove synchronization in TrackingFileManager > ** Dependency upgrade > * [MRESOLVER-105] - Update Plexus Components > * [MRESOLVER-106] - Update HttpComponents > * [MRESOLVER-107] - Update Wagon Provider API to 3.4.0 > * [MRESOLVER-108] - Update mockito-core to 2.28.2 > * [MRESOLVER-117] - Upgrade SLF4J to 1.7.30 > * [MRESOLVER-118] - Upgrade Sisu Components to 0.3.4 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6967) Improve the command line output from maven-artifact
[
https://issues.apache.org/jira/browse/MNG-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228236#comment-17228236
]
Hudson commented on MNG-6967:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Improve the command line output from maven-artifact
> ---
>
> Key: MNG-6967
> URL: https://issues.apache.org/jira/browse/MNG-6967
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.6.3
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
>Priority: Major
> Fix For: 3.7.0
>
>
> As is documented here
> https://maven.apache.org/pom.html#version-order-testing
> you can use the maven-artifact JAR file to test version numbers and their
> relative order.
> Unfortunately the output does not match what is used in
> https://maven.apache.org/pom.html#version-order-specification
> when describing the "Trimming Examples". It's matter of {{==}} versus {{->}}.
> I prefer the one used in the documentation, so I'd like to change
> maven-artifact to use {{->}}. It respresents a transformation (trimming in
> this case) -- not a an equality test.
> Another problem is that it does not show you the list of tokens that are the
> result of parsing the version numbers. This can be quite useful when trying
> to figure out why you are getting the results you are.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6992) Allow access to org.eclipse.aether.transform
[
https://issues.apache.org/jira/browse/MNG-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228244#comment-17228244
]
Hudson commented on MNG-6992:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Allow access to org.eclipse.aether.transform
>
>
> Key: MNG-6992
> URL: https://issues.apache.org/jira/browse/MNG-6992
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Affects Versions: 3.6.3
>Reporter: Slawomir Jaranowski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> Maven core doesn't export org.eclipse.aether.transform package in
> {{maven-core/src/main/resources/META-INF/maven/extension.xml}}
> So when we want, in plugin code, call:
> {code:java}
> org.eclipse.aether.RepositorySystemSession repositorySystemSession;
> ...
> repositorySystemSession.getFileTransformerManager()
> {code}
> we have:
> {code:java}
> [ERROR] Failed to execute goal ... failed: A required class was missing
> while executing ... org/eclipse/aether/transform/FileTransformerManager
> Caused by: java.lang.NoClassDefFoundError:
> org/eclipse/aether/transform/FileTransformerManager
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7000) metadata.mdo contains invalid link to schema
[
https://issues.apache.org/jira/browse/MNG-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228248#comment-17228248
]
Hudson commented on MNG-7000:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> metadata.mdo contains invalid link to schema
>
>
> Key: MNG-7000
> URL: https://issues.apache.org/jira/browse/MNG-7000
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> The location reads {{http://maven.apache.org/xsd/metadata-${version}.xsd}},
> but should read
> {{https://maven.apache.org/xsd/repository-metadata-${version}.xsd}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6999) Chained (consumer) XMLFilters can result in "floating" comments
[
https://issues.apache.org/jira/browse/MNG-6999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228254#comment-17228254
]
Hudson commented on MNG-6999:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Chained (consumer) XMLFilters can result in "floating" comments
> ---
>
> Key: MNG-6999
> URL: https://issues.apache.org/jira/browse/MNG-6999
> Project: Maven
> Issue Type: Bug
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
>
> Discovered while working on MNG-6957: I wanted to do the following:
> {code:xml}
>
> Z
> A
>
> {code}
> The ModulesXMLFilterTest contains tests related to comments, but when filters
> are changed, the lexicalHandlers are not chained correctly.
> The result: cleaned up modules, but leaving a comment behind.
> {code:xml}
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6972) Allow access to org.apache.maven.graph
[
https://issues.apache.org/jira/browse/MNG-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228238#comment-17228238
]
Hudson commented on MNG-6972:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Allow access to org.apache.maven.graph
> --
>
> Key: MNG-6972
> URL: https://issues.apache.org/jira/browse/MNG-6972
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading, Plugin API
>Affects Versions: 3.6.3
>Reporter: Michael Kroll
>Assignee: Michael Osipov
>Priority: Major
> Labels: easyfix, pull-request-available
> Fix For: 3.7.0
>
>
> Hi
> maven doesn't export org.apache.maven.graph package in
> maven-core/src/main/resources/META-INF/maven/extension.xml so the
> GraphBuilder is not usable in extensions.
> {code:java}
> // leads to java.lang.NoClassDefFoundError:
> Lorg/apache/maven/graph/GraphBuilder;
> @Requirement( hint = GraphBuilder.HINT )
> private GraphBuilder graphBuilder;
> {code}
> Background: if one build extension adds dependencies and another build
> extension uses {{session.getProjectDependencyGraph()}}, then the dependency
> graph is out of date. This is because the graph is only rebuilt after
> executing _all_ extensions. One solution to this would be to update the
> {{MavenSession}} and setting the new dependency graph in the first extension,
> but for this we need access to the {{GraphBuilder}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6931) Deprecate custom logging approach
[ https://issues.apache.org/jira/browse/MNG-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228250#comment-17228250 ] Hudson commented on MNG-6931: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Deprecate custom logging approach > - > > Key: MNG-6931 > URL: https://issues.apache.org/jira/browse/MNG-6931 > Project: Maven > Issue Type: Task >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.7.0 > > > It's an unnecessary layer of indirection from 2009 that's getting in the way > of more modern logging. > https://github.com/apache/maven/tree/master/maven-plugin-api/src/main/java/org/apache/maven/monitor/logging/DefaultLog.java > and all other related spots. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7002) Extend DefaultGraphBuilder unit tests to cover that child projects get included with the --pl switch
[ https://issues.apache.org/jira/browse/MNG-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228252#comment-17228252 ] Hudson commented on MNG-7002: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Extend DefaultGraphBuilder unit tests to cover that child projects get > included with the --pl switch > > > Key: MNG-7002 > URL: https://issues.apache.org/jira/browse/MNG-7002 > Project: Maven > Issue Type: Improvement > Components: Reactor and workspace >Reporter: Martin Kanters >Assignee: Martin Kanters >Priority: Minor > Labels: up-for-grabs > Fix For: 3.7.0 > > > MNG-6981 was recently merged in master and is only covered in integration > tests. > Since > [DefaultGraphBuilderTest|https://github.com/apache/maven/blob/master/maven-core/src/test/java/org/apache/maven/graph/DefaultGraphBuilderTest.java] > now contains a multi module structure this flow can be tested in unit tests, > offering developers quicker feedback during development. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6946) Build/consumer incorrectly transforms name of artifactId
[
https://issues.apache.org/jira/browse/MNG-6946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228232#comment-17228232
]
Hudson commented on MNG-6946:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Build/consumer incorrectly transforms name of artifactId
>
>
> Key: MNG-6946
> URL: https://issues.apache.org/jira/browse/MNG-6946
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.7.0
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Critical
>
> While trying to build maven-clean-plugin with Maven 3.7.0-SNAPSHOT, most
> tests called by the maven-invoker-plugins fail.
> It looks like the copy of maven-plugins-34.pom is one of the root causes.
> Comparing the original and this file (assuming transformation) the following
> are expected differences:
> - removed whitespace around the license
> - removed relativePath
> - removed whitespaces after closing root-tag
> The only invalid difference is
> {{maven-plugin-annotations}}
> which became
> {{tions}}
> There are 2 issues:
> - the artifactId is incorrect
> - as this file is not part of the reactor, there's no need to transform the
> file.
> One thing I noticed as well (only happens with build/consumer active):
> {noformat}
> [INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-bytecode-version) @
> maven-clean-plugin ---
> ERROR: 'The entity "oslash" was referenced, but not declared.'
> {noformat}
> Workaround: add -Dmaven.experimental.buildconsumer=false
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6886) Upgrade plexus-cipher 1.8
[ https://issues.apache.org/jira/browse/MNG-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228228#comment-17228228 ] Hudson commented on MNG-6886: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Upgrade plexus-cipher 1.8 > - > > Key: MNG-6886 > URL: https://issues.apache.org/jira/browse/MNG-6886 > Project: Maven > Issue Type: Bug > Components: Dependencies >Reporter: Olivier Lamy >Assignee: Olivier Lamy >Priority: Major > Fix For: 3.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- 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=17228240#comment-17228240
]
Hudson commented on MNG-6772:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> 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-6983) Plugin key can get out of sync with artifactId and groupId
[
https://issues.apache.org/jira/browse/MNG-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228243#comment-17228243
]
Hudson commented on MNG-6983:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Plugin key can get out of sync with artifactId and groupId
> --
>
> Key: MNG-6983
> URL: https://issues.apache.org/jira/browse/MNG-6983
> Project: Maven
> Issue Type: Bug
> Components: core, Plugins and Lifecycle
>Affects Versions: 3.6.3
>Reporter: Paul Pazderski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: pluginNotExecuted.zip
>
>
> I have a project build with maven where some maven plugins are not executed
> without any warning or error shown in output. I was able to reproduce the
> issue with a minimal example. (see attachment)
> The expected result of this example is to get the one source file compiled if
> you invoke {{mvn compile}}.
> If I run this example using Maven 3.6.3 the following output appears:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:child
> >--
> [INFO] Building child 0.0.1-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ child
> ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> [...]\pluginNotExecuted\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child ---
> [INFO] No sources to compile
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.644 s
> [INFO] Finished at: [...]
> [INFO]
>
> {noformat}
> Notice that there is no execution of the build-helper-maven-plugin (and as
> consequence no source compiled) and no indication why it is missing.
> From what I've found the problem seem to be the usage of variable in the
> plugins groupId. If you replace either the variable in parent- or child-pom
> with the actual value the build shows a warning
> {noformat}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.example:child:jar:0.0.1-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 16, column 21
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {noformat}
> If you replace both variables with the actual value everything works as
> expected.
>
> I investigated the problem further and will provide more details with a pull
> request for a possible fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6977) Use hyphen when creating builder threads (names)
[
https://issues.apache.org/jira/browse/MNG-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228239#comment-17228239
]
Hudson commented on MNG-6977:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Use hyphen when creating builder threads (names)
>
>
> Key: MNG-6977
> URL: https://issues.apache.org/jira/browse/MNG-6977
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> We currently create bulder threads as {{BuilderThread %d}}. This is bit
> problematic because you cannot properly {{grep}} or {{cut}} through this due
> to the while space. Most other use a hyphen and is then a snap to analyze
> debug output.
>
> Proposal is to use {{BuilderThread-%d}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6867) extract methods, apply SLA DefaultMavenPluginManager
[ https://issues.apache.org/jira/browse/MNG-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228226#comment-17228226 ] Hudson commented on MNG-6867: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > extract methods, apply SLA DefaultMavenPluginManager > > > Key: MNG-6867 > URL: https://issues.apache.org/jira/browse/MNG-6867 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Arne Lewinski >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Apply "extract method" refactoring to make methods smaller. Considering > principle "single level of abstraction". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7004) Refactor GitHub Actions environment variables since 'set-env' is deprecated
[
https://issues.apache.org/jira/browse/MNG-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228253#comment-17228253
]
Hudson commented on MNG-7004:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Refactor GitHub Actions environment variables since 'set-env' is deprecated
> ---
>
> Key: MNG-7004
> URL: https://issues.apache.org/jira/browse/MNG-7004
> Project: Maven
> Issue Type: Improvement
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.7.0
>
>
> See the warnings generated on a typical master build:
> [https://github.com/apache/maven/actions/runs/316060775]
> {{The `set-env` command is deprecated and will be disabled soon. Please
> upgrade to using Environment Files. For more information see:
> [https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/]}}
> The fix provided in the blog seems simple, but let's make sure it keeps on
> working afterwards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6949) As a developer on Maven Core I would like to verify my build before merge
[ https://issues.apache.org/jira/browse/MNG-6949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228234#comment-17228234 ] Hudson commented on MNG-6949: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > As a developer on Maven Core I would like to verify my build before merge > - > > Key: MNG-6949 > URL: https://issues.apache.org/jira/browse/MNG-6949 > Project: Maven > Issue Type: Improvement >Reporter: Martin Kanters >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.7.0 > > > One of the requirements before providing a pull request to Maven is that you > have to run `mvn verify` and the integration tests. This is to ensure that > the PR that is delivered is of good quality. I do not disagree with this > approach, but it can be easy to forget to run this, especially in the case of > processing (small) review comments. > For me it already happened a couple of times that a failing test was found at > the time when the pull request was getting merged in master. By utilizing > GitHub Actions we can ensure that the PR's requirements are fulfilled. This > is meant as an addition on top of local tests and the CI job on Jenkins tests > that commiters execute during merger, not a replacement. > > I have implemented this last weekend and would like to propose this. It is > based on another Maven project's GitHub Action workflow, but has been > extended. It features the following: > # mvn verify on Ubuntu, Windows and MacOS machines, with Java 8, 11, 14. > # integration tests against the new Maven build (from step 1). > By default it will run against the latest master version of > apache/maven-integration-testing. > However, if the developer has a branch with the same name as the maven PR on > a forked maven-integration-testing project, it will check that out instead. > Link to the pull request: [https://github.com/apache/maven/pull/365]. > Currently the action is not running on the PR itself, I guess that is due to > settings in the apache/maven project. > It is running on the branch of our fork, though: > [https://github.com/infosupport/maven/actions/runs/150771674]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6987) Reorder groupId before artifactId when writing an exclusion using maven-model
[
https://issues.apache.org/jira/browse/MNG-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228241#comment-17228241
]
Hudson commented on MNG-6987:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Reorder groupId before artifactId when writing an exclusion using maven-model
> -
>
> Key: MNG-6987
> URL: https://issues.apache.org/jira/browse/MNG-6987
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.3
>Reporter: Marc Bruggmann
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.7.0
>
>
> We are using {{maven-model}} to parse, modify, and write back a POM file
> roughly like so:
>
> {code:java}
> MavenXpp3Reader reader = new MavenXpp3Reader();
> Model model = reader.read(new FileReader(input));
> // make modifications to the model
> MavenXpp3Writer writer = new MavenXpp3Writer();
> writer.write(new FileWriter(output), model);{code}
>
> The exclusion shows up in the output file like this:
> {code:java}
>
>
> plexus-cipher
> org.sonatype.plexus
>
>
> {code}
> In most other places in the POM, we order the groupId before the artifactId.
> It would be nice to do it the same way for exclusion, like so:
> {code:java}
>
>
> org.sonatype.plexus
> plexus-cipher
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228242#comment-17228242
]
Hudson commented on MNG-6991:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {code}
> String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> {code}
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
> {code}
> request.setLocalRepositoryPath( determineLocalRepositoryPath( request
> ) );
> ...
> private String determineLocalRepositoryPath( final
> MavenExecutionRequest request )
> {
> return request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY,
> request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
> );
> }
> {code}
> effectively _always_ replacing the local repository definition, potentially
> nulling it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6917) Introduce wrapper lifecycle
[
https://issues.apache.org/jira/browse/MNG-6917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228229#comment-17228229
]
Hudson commented on MNG-6917:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Introduce wrapper lifecycle
> ---
>
> Key: MNG-6917
> URL: https://issues.apache.org/jira/browse/MNG-6917
> Project: Maven
> Issue Type: New Feature
> Components: maven wrapper
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
>
> By introducing the wrapper lifecycle, it will be possible to call
> {{mvn wrapper}}, which is bound the wrapper goal of the maven-wrapper-plugin.
> It will download and unpack apache-maven-wrapper-VERSION-script.zip into the
> basedir.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6866) PluginDescriptorBuilder build method very long
[ https://issues.apache.org/jira/browse/MNG-6866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228223#comment-17228223 ] Hudson commented on MNG-6866: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > PluginDescriptorBuilder build method very long > -- > > Key: MNG-6866 > URL: https://issues.apache.org/jira/browse/MNG-6866 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Arne Lewinski >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > The build method of the class ""PluginDescriptorBuilder" is very long. > I suggest to extract several methods and harmonize the methodolgy to set all > values. It can follows the strict concept: extracting the necessary element > from the PlexusConfiguration and setting it on the PluginDescriptor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6942) Arbitrary file write during archive extraction ("Zip Slip") in wrapper
[
https://issues.apache.org/jira/browse/MNG-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228222#comment-17228222
]
Hudson commented on MNG-6942:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Arbitrary file write during archive extraction ("Zip Slip") in wrapper
> --
>
> Key: MNG-6942
> URL: https://issues.apache.org/jira/browse/MNG-6942
> Project: Maven
> Issue Type: Bug
> Components: maven wrapper
>Affects Versions: 3.7.0
>Reporter: Sylwester Lachiewicz
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
>
> In Maven Wrapper Installer
> [https://github.com/apache/maven/blob/ef8c95eb397651e10f677763dfcd9c8cea7c27b0/maven-wrapper/src/main/java/org/apache/maven/wrapper/Installer.java]
>
> {code:java}
> ZipEntry entry = entries.nextElement();
> if ( entry.isDirectory() )
> {
> continue;
> }
> Path targetFile = dest.resolve( entry.getName() );
> // Unsanitized archive entry, which may contain '..', is used in a file
> system operation.
> // prevent Zip Slip
> if ( targetFile.startsWith( dest ) )
> {
>Files.createDirectories( targetFile.getParent() );
>Files.copy( zipFile.getInputStream( entry ), targetFile );
> }
> {code}
>
> Found via LGTM.com scan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228216#comment-17228216 ] Hudson commented on MNG-6919: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228221#comment-17228221
]
Hudson commented on MNG-5760:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be
> very useful if you could type {{mvn -rf}} and have the project name
> inferred from the last failure rather than needing to copy/paste from the
> terminal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6856) Remove dependency to Powermock
[ https://issues.apache.org/jira/browse/MNG-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228209#comment-17228209 ] Hudson commented on MNG-6856: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Remove dependency to Powermock > -- > > Key: MNG-6856 > URL: https://issues.apache.org/jira/browse/MNG-6856 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We use Powermock only in one set of tests, in a class > `StringSearchModelInterpolator` that is no longer used in Maven Core -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6882) Change the URL's in tests etc. from http to https
[ https://issues.apache.org/jira/browse/MNG-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228224#comment-17228224 ] Hudson commented on MNG-6882: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Change the URL's in tests etc. from http to https > - > > Key: MNG-6882 > URL: https://issues.apache.org/jira/browse/MNG-6882 > Project: Maven > Issue Type: Improvement > Components: core >Affects Versions: 3.7.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.7.0 > > > Based on the given PR https://github.com/apache/maven/pull/323 it's not > enough to change the URL's in the pom files it is also necessary to change > the URL's in the tests cause they are using in assertions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6900) Upgrade Jansi to 1.18
[ https://issues.apache.org/jira/browse/MNG-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228215#comment-17228215 ] Hudson commented on MNG-6900: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Upgrade Jansi to 1.18 > - > > Key: MNG-6900 > URL: https://issues.apache.org/jira/browse/MNG-6900 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228217#comment-17228217
]
Hudson commented on MNG-5868:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6914) Align mvn and mvnw scripts
[ https://issues.apache.org/jira/browse/MNG-6914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228213#comment-17228213 ] Hudson commented on MNG-6914: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Align mvn and mvnw scripts > -- > > Key: MNG-6914 > URL: https://issues.apache.org/jira/browse/MNG-6914 > Project: Maven > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > With MNG-5937 the wrapper code becomes part of core. > The scripts are like 80% the same, 10% is wrapper specific and 10% are > differences due to improvements on one or the other side. > By aligning the scripts they both benefit from the improvements. > Some important changes that might but should not effect the build: > - CLASSWORLDS_LAUNCHER / WRAPPER_LAUNCHER will be renamed to MAVEN_LAUNCHER > - CLASSWORLDS_JAR / WRAPPER_JAR will be renamed to LAUNCHER_JAR > - Introduce MAVENHOME_CONFIG. For the wrapper it will be empty (as the > wrapper must download the Maven first), maven will use it to set > classworlds.conf, maven.home and library.jansi.path -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6672) Upgrade Maven Resolver to 1.4.2
[ https://issues.apache.org/jira/browse/MNG-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228206#comment-17228206 ] Hudson commented on MNG-6672: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Upgrade Maven Resolver to 1.4.2 > --- > > Key: MNG-6672 > URL: https://issues.apache.org/jira/browse/MNG-6672 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Affects Versions: 3.6.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > > Release Notes - Maven Resolver - Version 1.4.0 > * Bug > [MRESOLVER-86] - ResolveArtifactMojo from resolver example uses plugin > repositories to resolve dependencies > * New Feature > [MRESOLVER-10] - New 'TransitiveDependencyManager' supporting transitive > dependency management > [MRESOLVER-33] - New 'DefaultDependencyManager' managing dependencies on all > levels supporting transitive dependency management > * Improvement > [MRESOLVER-7] - Download dependency POMs in parallel > [MRESOLVER-84] - Add support for "release" qualifier > [MRESOLVER-87] - Refresh examples to use maven-resolver artifacts for demo > [MRESOLVER-88] - Code style cleanup to use Java 7 features > Release Notes - Maven Resolver - Version 1.4.1 > * Task > [MRESOLVER-92] - Revert MRESOLVER-7 > Release Notes - Maven Resolver - Version 1.4.2 > * Improvement > [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles > [MRESOLVER-102] - make build Reproducible -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6884) Cleanup POM File after version upgrade
[ https://issues.apache.org/jira/browse/MNG-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228227#comment-17228227 ] Hudson commented on MNG-6884: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Cleanup POM File after version upgrade > -- > > Key: MNG-6884 > URL: https://issues.apache.org/jira/browse/MNG-6884 > Project: Maven > Issue Type: Task >Affects Versions: 3.7.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.7.0 > > > Remove the entries in pom file which are mentioned by the TODO: > * maven-source-plugin > * maven-jar-plugin > * maven-assembly-plugin > they are handled by the parent. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6562) WARN if plugins injected by default lifecycle bindings don't have their version locked in pom.xml or parent
[
https://issues.apache.org/jira/browse/MNG-6562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228220#comment-17228220
]
Hudson commented on MNG-6562:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> WARN if plugins injected by default lifecycle bindings don't have their
> version locked in pom.xml or parent
> ---
>
> Key: MNG-6562
> URL: https://issues.apache.org/jira/browse/MNG-6562
> Project: Maven
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0
>Reporter: Herve Boutemy
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, when building from a basic pom.xml:
> {code:xml}
> 4.0.0
> com.mycompany.app
> my-app
> 1.0-SNAPSHOT
> {code}
> many plugins are used, but their version is not locked by the user: the
> default plugins versions depend on Maven version used, which is not stable
> over different Maven versions.
> Adding a warning for this stability issue will help users know that they need
> to lock down plugins versions in their pom (or parent), something like:
> {noformat}[WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> [WARNING] Version not locked for default bindings plugins
> [maven-install-plugin, maven-resources-plugin, maven-surefire-plugin,
> maven-compiler-plugin, maven-jar-plugin, maven-deploy-plugin,
> maven-site-plugin], you should define versions in pluginManagement section of
> your pom.xml or parent
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5577) Convert the core to use JSR 330 and remove the use of Plexus
[ https://issues.apache.org/jira/browse/MNG-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228225#comment-17228225 ] Hudson commented on MNG-5577: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Convert the core to use JSR 330 and remove the use of Plexus > > > Key: MNG-5577 > URL: https://issues.apache.org/jira/browse/MNG-5577 > Project: Maven > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Jason van Zyl >Priority: Major > Fix For: 3.7.x-candidate > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Remove the use of Plexus annotations and use JSR330 annotations throughout > the core. > *NOTE:* The descriptor must still be generated, since Maven doesn't do > annotation scanning for performance reason. It simply reads the descriptor > file(s). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6897) Upgrade Maven Wagon to 3.4.0
[ https://issues.apache.org/jira/browse/MNG-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228205#comment-17228205 ] Hudson commented on MNG-6897: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Upgrade Maven Wagon to 3.4.0 > > > Key: MNG-6897 > URL: https://issues.apache.org/jira/browse/MNG-6897 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6873) Inconsistent library versions notice
[ https://issues.apache.org/jira/browse/MNG-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228211#comment-17228211 ] Hudson commented on MNG-6873: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Inconsistent library versions notice > > > Key: MNG-6873 > URL: https://issues.apache.org/jira/browse/MNG-6873 > Project: Maven > Issue Type: Improvement >Reporter: Kaifeng Huang >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.7.0 > > Attachments: apache maven.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > > Hi. I have implemented a tool to detect library version inconsistencies. Your > project have 1 inconsistent library and 12 false consistent libraries. > > Take junit:junit for example, this library is declared as version 3.8.1 in > maven-core/src/test/resources-project-builder/dependency-inheritance, 4.4 in > maven-core/src/test/resources-project-builder/dependency-inheritance/sub and > etc... Such version inconsistencies may cause unnecessary maintenance effort > in the long run. For example, if two modules become inter-dependent, library > version conflict may happen. It has already become a common issue and hinders > development progress. Thus a version harmonization is necessary. > > Provided we applied a version harmonization, I calculated the cost it may > have to harmonize to all upper versions including an up-to-date one. The cost > refers to POM config changes and API invocation changes. Take junit:junit for > example, if we harmonize all the library versions into 4.4. The concern is, > how much should the project code adapt to the newer library version. We list > an effort table to quantify the harmonization cost. > > The effort table shows the overall harmonization cost on APIs. It seems your > project have no API invokes on this library, which could be safely upgrade to > 4.4 > ||Index||Module||NA(NAC)||NDA(NDAC)||NMA(NMAC)|| > |1|maven-core/src/test/resources-project-builder/dependency-inheritance|0(0)|0(0)|0(0)| > |2|maven-core/src/test/resources-project-builder/dependency-inheritance/sub|0(0)|0(0)|0(0)| > > Also we provided another table to show the potential files that may be > affected due to library API change, which could help to spot the concerned > API usage and rerun the test cases. > As for false consistency, take junit junit jar for example. The library is > declared in version 4.13 in all modules. However they are declared > differently. As components are developed in parallel, if one single library > version is updated, which could become inconsistent as mentioned above, may > cause above-mentioned inconsistency issues > If you are interested, you can have a more complete and detailed report in > the attached PDF file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6878) Upgrade Guice to 4.2.3
[
https://issues.apache.org/jira/browse/MNG-6878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228202#comment-17228202
]
Hudson commented on MNG-6878:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Upgrade Guice to 4.2.3
> --
>
> Key: MNG-6878
> URL: https://issues.apache.org/jira/browse/MNG-6878
> Project: Maven
> Issue Type: Dependency upgrade
>Reporter: Sylwester Lachiewicz
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.7.0
>
>
> h4. Changes since Guice 4.2.2 [https://github.com/google/guice/wiki/Guice423]
> [http://google.github.io/guice/api-docs/4.2.3/api-diffs/changes.html]
> * Java14 support (updated asm).
> * Added {{Injector.getElements}} API, to expose all Element SPI types from
> the Injector.
> * Added {{Injector.getAllMembersInjectorInjectionPoints}} API, to expose
> injection points created by arbitrary members injection.
> * Added {{getAlternateKeys}} to Multibinder SPI types
> ({{MultibinderBinding}}, {{MapBinderBinding}}, {{OptionalBinderBinding}}), to
> explicitly list the other keys these bindings are available as.
> * Scan for (and bind) @Provides-like methods in a consistent ordering,
> rather than relying on the non-deterministic Class.getDeclaredMembers
> ordering.
> * Update {{DaggerAdapter}} to work with newer dagger code.
> * Fixed a [subtle
> bug|https://github.com/google/guice/commit/f8cc1718a33a868e9951f7d3d6b4f74d8b1a1548]
> with eager singleton evaluation.
> * Updated {{@RequestScope}}'s scope annotation to the JSR330 {{@Scope}}, so
> it can be reused by non-Guice DI systems.
> * Clarified the error message when an injectable constructor is missing.
> * Add deprecated overloads to various {{Modules}} methods, to make it
> clearer when calling them is unnecessary.
> * Added factory methods to {{Modules}} for common Binder configuration
> methods, to make it easier to configure them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-2478) add "resources-filtered" filtered resource directories to super POM
[
https://issues.apache.org/jira/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228207#comment-17228207
]
Hudson commented on MNG-2478:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> add "resources-filtered" filtered resource directories to super POM
> ---
>
> Key: MNG-2478
> URL: https://issues.apache.org/jira/browse/MNG-2478
> Project: Maven
> Issue Type: New Feature
> Components: POM
>Affects Versions: 2.0.4
> Environment: any
>Reporter: Jörg Hohwiller
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> The super POM contains default folders for resources that are NOT filtered
> (src/main/resources and src/test/resources). If one (additionally) needs a
> filtered resources folder, it needs to override the default and therefore has
> to add all default folders if he does NOT want to "loose" the defaults.
> To make this easier my suggestion is to add filtered resource folders to the
> super POM. This should also fit to the philosophy of maven that aims to have
> defaults and only declare as little custom configuration as needed.
> My personal favorite for the foldernames would be "templates" but to make
> things more obvious to the user maybe "resources-filtered" would be better.
> Actually I do not care to much about the name...
> So the resources in the super POM should look like this:
> {code:xml}
>
> src/main/resources
>
>
>
> src/main/resources-filtered
> true
>
>
>
>
>
> src/test/resources
>
>
>
> src/test/resources-filtered
> true
>
>
> {code}
> Update: The folder name has been changed to "resources-filtered".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6937) StringSearchModelInterpolatorTest fails on symlinked paths
[
https://issues.apache.org/jira/browse/MNG-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228219#comment-17228219
]
Hudson commented on MNG-6937:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> StringSearchModelInterpolatorTest fails on symlinked paths
> --
>
> Key: MNG-6937
> URL: https://issues.apache.org/jira/browse/MNG-6937
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> This one was found when using the newly modified {{run-its.sh}} with the
> Maven Wrapper.
> When Maven source base resides on a symlinked path
> {{StringSearchModelInterpolatorTest}} fails. A reduced test setup is:
> {{$HOME/var}} points to {{/var/}}. Call is
> {{~/apache-maven-3.7.0-SNAPSHOT/bin/mvn -f ~/var/Projekte/maven clean
> verify}}. The test fails with:
> {noformat}
> [INFO] Running
> org.apache.maven.model.interpolation.StringSearchModelInterpolatorTest
> [ERROR] Tests run: 34, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.09
> s <<< FAILURE! - in
> org.apache.maven.model.interpolation.StringSearchModelInterpolatorTest
> [ERROR]
> testInterpolateObjectWithPomFile(org.apache.maven.model.interpolation.StringSearchModelInterpolatorTest)
> Time elapsed: 0.01 s <<< FAILURE!
> java.lang.AssertionError:
> Expected: is "/net/home/osipovmi/var/Projekte/maven/maven-model-builder"
> but: was "/var/osipovmi/Projekte/maven/maven-model-builder"
> at
> org.apache.maven.model.interpolation.StringSearchModelInterpolatorTest.testInterpolateObjectWithPomFile(StringSearchModelInterpolatorTest.java:362)
> {noformat}
> The bug is in the test which canonicalizes the {{buildDir}}, but not
> {{user.dir}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6721) Deletes content of soft links on Windows
[ https://issues.apache.org/jira/browse/MNG-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6721. --- Fix Version/s: (was: 3.7.0-candidate) 3.7.0 Resolution: Fixed Resolved by MNG-6548. > Deletes content of soft links on Windows > > > Key: MNG-6721 > URL: https://issues.apache.org/jira/browse/MNG-6721 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.1 > Environment: Windows 10 (1810) >Reporter: Ron Birk >Assignee: Michael Osipov >Priority: Major > Labels: up-for-grabs > Fix For: 3.7.0 > > > I have a soft link in a directory. Maven clean plugin not only deletes the > link (which is fine), it also deletes all the files inside the soft link, > which is a major problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-4660) Use of --resume-from in multi-module project fails with missing inter-module dependencies
[ https://issues.apache.org/jira/browse/MNG-4660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228203#comment-17228203 ] Hudson commented on MNG-4660: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Use of --resume-from in multi-module project fails with missing inter-module > dependencies > - > > Key: MNG-4660 > URL: https://issues.apache.org/jira/browse/MNG-4660 > Project: Maven > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.2.1, 3.0-beta-1 > Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac" >Reporter: Brian Ferris >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > Attachments: modules-parent.tar.gz > > Time Spent: 1h 20m > Remaining Estimate: 0h > > In a simple multi-module project with a parent pom "modules-parent", two sub > modules "module-a" and "module-b", where B depends on A, I've not been able > to get the Maven "--resume-from" feature to work. > Specifically, I expect: > > mvn --resume-from module-b test > would resume execution of the "test" goal in "module-b". Instead it fails > with a missing artifact error: > > [INFO] Failed to resolve artifact. > > > > Missing: > > -- > > 1) org.test:module-a:jar:0.0.1-SNAPSHOT > Why isn't Maven resolving the within-multi-module dependency? I've attached > a simple project that reproduces the problem with Maven 2.2.1 and Maven > 3.0-beta-1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6893) Update plugin versions in super POM (api 3.0)
[ https://issues.apache.org/jira/browse/MNG-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228210#comment-17228210 ] Hudson commented on MNG-6893: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Update plugin versions in super POM (api 3.0) > - > > Key: MNG-6893 > URL: https://issues.apache.org/jira/browse/MNG-6893 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Priority: Major > Fix For: 3.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Update plugins in maven-model-builder pom-4.0.0.xml > * maven-ant-run from 1.3 to 3.0.0 (/) > * maven-assembly-plugin from 2.2-beta-5 to XXX > * maven-dependency-plugin from 2.8 to XXX > * maven-dependency-plugin from 2.5.3 to XXX -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6819) NullPointerException for DefaultArtifactDescriptorReader.loadPom
[
https://issues.apache.org/jira/browse/MNG-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228214#comment-17228214
]
Hudson commented on MNG-6819:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> NullPointerException for DefaultArtifactDescriptorReader.loadPom
>
>
> Key: MNG-6819
> URL: https://issues.apache.org/jira/browse/MNG-6819
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.6.2, 3.6.3
>Reporter: Darcy Shen
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.7.0
>
>
> Here is a clue to reproduce the NPE.
> {code:xml}
>
> maven-antrun-plugin
>
>
> package
>
>
>
> src="${project.build.directory}/${project.build.finalName}.${project.packaging}"
> dest="${project.build.directory}/xxx" />
>
>
>
> run
>
>
>
>
> {code}
> project.build.finalName is the previous value, and the interpolated value is
> null.
> {noformat}
> $ mvn clean compile -e # on a private project
> [ERROR] NullPointerException
> java.lang.NullPointerException
> at java.util.Hashtable$Entry.setValue (Hashtable.java:1286)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1429)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1027)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:170)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator.interpolateModel
> (StringVisitorModelInterpolator.java:107)
> at org.apache.maven.model.building.DefaultModelBuilder.interpolateModel
> (DefaultModelBuilder.java:789)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:393)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
> (DefaultArtifactDescriptorReader.java:292)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
> (DefaultArtifactDescriptorReader.java:171)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor
> (DefaultDependencyCollector.java:541)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult
> (DefaultDependencyCollector.java:524)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:412)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:365)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:352)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:509)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:461)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:365)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:352)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:509)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:461)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:365)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:352)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:509)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
>
[jira] [Commented] (MNG-6891) Improve support --fail-on-severity
[
https://issues.apache.org/jira/browse/MNG-6891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228208#comment-17228208
]
Hudson commented on MNG-6891:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> Improve support --fail-on-severity
> --
>
> Key: MNG-6891
> URL: https://issues.apache.org/jira/browse/MNG-6891
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> MNG-6065 was a first implementation, but it is not user friendly enough.
> 1. When saying {{-fos}} the message is: No enum constant
> org.slf4j.event.Level.warn
> We should show at least all available values here
> 2. The prefix for warnings in Maven is [WARNING], due to
> {{org.slf4j.simpleLogger.warnLevelString}} in
> {{apache-maven/conf/logging/simplelogger.properties}}. It makes sense support
> this custom value as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228212#comment-17228212 ] Hudson commented on MNG-5937: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6863) --also-make is being ignored when calling --resume-from
[
https://issues.apache.org/jira/browse/MNG-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228204#comment-17228204
]
Hudson commented on MNG-6863:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/
> --also-make is being ignored when calling --resume-from
> ---
>
> Key: MNG-6863
> URL: https://issues.apache.org/jira/browse/MNG-6863
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.7.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The --resume-from is a bit broken since Maven 3. For Maven 2 it worked fine,
> because dependencies needed to exist in the local repository, hence you could
> only do this by calling {{mvn install}}.
> With Maven 3 the need for {{install}} is gone, however if you call
> --resume-from, its dependencies might be part of the multimodule project, but
> not from the reactor (these are the maven modules that are being built).
> With -am/--also-make it should include all required modules as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6828) DependencyResolutionException breaks serialization
[ https://issues.apache.org/jira/browse/MNG-6828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228218#comment-17228218 ] Hudson commented on MNG-6828: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6551 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6551/14/ > DependencyResolutionException breaks serialization > -- > > Key: MNG-6828 > URL: https://issues.apache.org/jira/browse/MNG-6828 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.6.3 >Reporter: James R. Ratzlaff >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.7.0 > > > In class > [DependencyResolutionException|https://github.com/apache/maven/blob/a2b800de32cdb9adc1e64a43a0fc32e3ba878103/maven-core/src/main/java/org/apache/maven/project/DependencyResolutionException.java] > , the field > "[result|https://github.com/apache/maven/blob/a2b800de32cdb9adc1e64a43a0fc32e3ba878103/maven-core/src/main/java/org/apache/maven/project/DependencyResolutionException.java#L29]; > is the non-serializable type DependencyResolution. This causes serialization > to fail (since its super class, Exception, is inherently Serializable). This > field should have [transient access similar to the > DependencyResolutionException in the > maven-resolver-api.|https://github.com/apache/maven-resolver/blob/2a1f4a134f7d7784f2a64bf58bddd2732bb599a4/maven-resolver-api/src/main/java/org/eclipse/aether/resolution/DependencyResolutionException.java#L31] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-6548) Lifecycle plugin version upgrades
[ https://issues.apache.org/jira/browse/MNG-6548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-6548. --- Fix Version/s: (was: 3.7.0-candidate) 3.7.0 Resolution: Fixed Fixed with [7a4b77b582913aad0ee941df8e86a5b83bc3eec8|https://gitbox.apache.org/repos/asf?p=maven.git=commit=7a4b77b582913aad0ee941df8e86a5b83bc3eec8]. > Lifecycle plugin version upgrades > - > > Key: MNG-6548 > URL: https://issues.apache.org/jira/browse/MNG-6548 > Project: Maven > Issue Type: Improvement > Components: core, Dependencies >Affects Versions: 3.5.0, 3.6.0 >Reporter: Christian Schulte >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.7.0 > > > Regular plugin upgrades to absorb changes if plugin version is not specified > in the client POM. > ||groupId||artifactId||[previous > version|https://maven.apache.org/ref/3.5.0/maven-core/lifecycles.html]||target > version|| > |org.apache.maven.plugins|maven-clean-plugin|2.5|3.1.0| > |org.apache.maven.plugins|maven-site-plugin|3.3|3.9.1| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6987) Reorder groupId before artifactId when writing an exclusion using maven-model
[
https://issues.apache.org/jira/browse/MNG-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228173#comment-17228173
]
Hudson commented on MNG-6987:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Reorder groupId before artifactId when writing an exclusion using maven-model
> -
>
> Key: MNG-6987
> URL: https://issues.apache.org/jira/browse/MNG-6987
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.3
>Reporter: Marc Bruggmann
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.7.0
>
>
> We are using {{maven-model}} to parse, modify, and write back a POM file
> roughly like so:
>
> {code:java}
> MavenXpp3Reader reader = new MavenXpp3Reader();
> Model model = reader.read(new FileReader(input));
> // make modifications to the model
> MavenXpp3Writer writer = new MavenXpp3Writer();
> writer.write(new FileWriter(output), model);{code}
>
> The exclusion shows up in the output file like this:
> {code:java}
>
>
> plexus-cipher
> org.sonatype.plexus
>
>
> {code}
> In most other places in the POM, we order the groupId before the artifactId.
> It would be nice to do it the same way for exclusion, like so:
> {code:java}
>
>
> org.sonatype.plexus
> plexus-cipher
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6118) Add option to execute goals on a specific module while building a multimodule project
[
https://issues.apache.org/jira/browse/MNG-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228181#comment-17228181
]
Hudson commented on MNG-6118:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Add option to execute goals on a specific module while building a multimodule
> project
> -
>
> Key: MNG-6118
> URL: https://issues.apache.org/jira/browse/MNG-6118
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Plugins and Lifecycle
>Reporter: Robert Scholte
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 3.7.0
>
>
> Suppose we have a multimodule which results in a war. In the end we want to
> run this war in a container like jetty. Up until now the {{jetty:run}} is
> executed on every module, which doesn't make sense for the other modules.
> This is just one of several examples where you want to control on which
> module to execute a specific goal. In case of wars, the plugin could check
> for the packaging type, but in case of jars this won't work.
> There should be a generic solution to mark goals for a specific module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6900) Upgrade Jansi to 1.18
[ https://issues.apache.org/jira/browse/MNG-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228158#comment-17228158 ] Hudson commented on MNG-6900: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Upgrade Jansi to 1.18 > - > > Key: MNG-6900 > URL: https://issues.apache.org/jira/browse/MNG-6900 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6931) Deprecate custom logging approach
[ https://issues.apache.org/jira/browse/MNG-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228182#comment-17228182 ] Hudson commented on MNG-6931: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Deprecate custom logging approach > - > > Key: MNG-6931 > URL: https://issues.apache.org/jira/browse/MNG-6931 > Project: Maven > Issue Type: Task >Reporter: Elliotte Rusty Harold >Assignee: Michael Osipov >Priority: Minor > Fix For: 3.7.0 > > > It's an unnecessary layer of indirection from 2009 that's getting in the way > of more modern logging. > https://github.com/apache/maven/tree/master/maven-plugin-api/src/main/java/org/apache/maven/monitor/logging/DefaultLog.java > and all other related spots. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6972) Allow access to org.apache.maven.graph
[
https://issues.apache.org/jira/browse/MNG-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228170#comment-17228170
]
Hudson commented on MNG-6972:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Allow access to org.apache.maven.graph
> --
>
> Key: MNG-6972
> URL: https://issues.apache.org/jira/browse/MNG-6972
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading, Plugin API
>Affects Versions: 3.6.3
>Reporter: Michael Kroll
>Assignee: Michael Osipov
>Priority: Major
> Labels: easyfix, pull-request-available
> Fix For: 3.7.0
>
>
> Hi
> maven doesn't export org.apache.maven.graph package in
> maven-core/src/main/resources/META-INF/maven/extension.xml so the
> GraphBuilder is not usable in extensions.
> {code:java}
> // leads to java.lang.NoClassDefFoundError:
> Lorg/apache/maven/graph/GraphBuilder;
> @Requirement( hint = GraphBuilder.HINT )
> private GraphBuilder graphBuilder;
> {code}
> Background: if one build extension adds dependencies and another build
> extension uses {{session.getProjectDependencyGraph()}}, then the dependency
> graph is out of date. This is because the graph is only rebuilt after
> executing _all_ extensions. One solution to this would be to update the
> {{MavenSession}} and setting the new dependency graph in the first extension,
> but for this we need access to the {{GraphBuilder}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-5868) Adding serval times the same artifact via MavenProjectHelper (attachArtifact) keep adding to the List duplicate artifacts
[
https://issues.apache.org/jira/browse/MNG-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228160#comment-17228160
]
Hudson commented on MNG-5868:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Adding serval times the same artifact via MavenProjectHelper (attachArtifact)
> keep adding to the List duplicate artifacts
> -
>
> Key: MNG-5868
> URL: https://issues.apache.org/jira/browse/MNG-5868
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.2.3
>Reporter: Karl Heinz Marbaise
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.7.0
>
>
> During the check of an issue MSHADE-195 i stumbled over several things...
> If you take a look here and the log output excerpt:
> {noformat}
> INFO] Minimized 2341 -> 1293
> [INFO] Minimized 3282 -> 2234
> [INFO] Replacing original artifact with shaded artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded.jar
> [INFO] Replacing original source artifact with shaded source artifact.
> [INFO] Replacing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> with
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-shaded-sources.jar
> [INFO] Dependency-reduced POM written at:
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml
> [INFO]
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @
> MSHADE-195-example ---
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/dependency-reduced-pom.xml to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT.pom
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO] Installing
> /Users/kama/ws-git/apache/mshade/mshade-195/target/MSHADE-195-example-1-SNAPSHOT-sources.jar
> to
> /Users/kama/.m2/repository/com/example/MSHADE-195-example/1-SNAPSHOT/MSHADE-195-example-1-SNAPSHOT-sources.jar
> [INFO]
> {noformat}
> Install plugin tries to install two identical artifacts which will work for
> maven-install-plugin but would fail a deploy to repository manager (for
> releases) etc.
> So after diving into the problem i found the following code in maven-core
> (MavenProject.java):
> {code:java}
> /**
> * Add or replace an artifact. This method is now deprecated. Use the
> @{MavenProjectHelper} to attach artifacts to a
> * project. In spite of the 'throws' declaration on this API, this method
> has never thrown an exception since Maven
> * 3.0.x. Historically, it logged and ignored a second addition of the
> same g/a/v/c/t. Now it replaces the file for
> * the artifact, so that plugins (e.g. shade) can change the pathname of
> the file for a particular set of
> * coordinates.
> *
> * @param artifact the artifact to add or replace.
> * @throws DuplicateArtifactAttachmentException
> */
> public void addAttachedArtifact( Artifact artifact )
> throws DuplicateArtifactAttachmentException
> {
> getAttachedArtifacts().add( artifact );
> }
> public List getAttachedArtifacts()
> {
> if ( attachedArtifacts == null )
> {
> attachedArtifacts = new ArrayList<>();
> }
> return attachedArtifacts;
> }
> {code}
> So taking a look into MavenProjectHelper.java and the implementation
> (DefaultMavenProjectHelper.java).
> {code:java}
> /**
> * Add an attached artifact or replace the file for an existing artifact.
> *
> * @see
> MavenProject#addAttachedArtifact(org.apache.maven.artifact.Artifact)
> * @param project project reference.
> * @param artifact artifact to add or replace.
> */
> public void attachArtifact( MavenProject project, Artifact artifact )
> {
> project.addAttachedArtifact( artifact );
> }
> {code}
> which means that there is not check if an artifacts is already attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6992) Allow access to org.eclipse.aether.transform
[
https://issues.apache.org/jira/browse/MNG-6992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228176#comment-17228176
]
Hudson commented on MNG-6992:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Allow access to org.eclipse.aether.transform
>
>
> Key: MNG-6992
> URL: https://issues.apache.org/jira/browse/MNG-6992
> Project: Maven
> Issue Type: Improvement
> Components: Class Loading
>Affects Versions: 3.6.3
>Reporter: Slawomir Jaranowski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> Maven core doesn't export org.eclipse.aether.transform package in
> {{maven-core/src/main/resources/META-INF/maven/extension.xml}}
> So when we want, in plugin code, call:
> {code:java}
> org.eclipse.aether.RepositorySystemSession repositorySystemSession;
> ...
> repositorySystemSession.getFileTransformerManager()
> {code}
> we have:
> {code:java}
> [ERROR] Failed to execute goal ... failed: A required class was missing
> while executing ... org/eclipse/aether/transform/FileTransformerManager
> Caused by: java.lang.NoClassDefFoundError:
> org/eclipse/aether/transform/FileTransformerManager
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7002) Extend DefaultGraphBuilder unit tests to cover that child projects get included with the --pl switch
[ https://issues.apache.org/jira/browse/MNG-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228184#comment-17228184 ] Hudson commented on MNG-7002: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Extend DefaultGraphBuilder unit tests to cover that child projects get > included with the --pl switch > > > Key: MNG-7002 > URL: https://issues.apache.org/jira/browse/MNG-7002 > Project: Maven > Issue Type: Improvement > Components: Reactor and workspace >Reporter: Martin Kanters >Assignee: Martin Kanters >Priority: Minor > Labels: up-for-grabs > Fix For: 3.7.0 > > > MNG-6981 was recently merged in master and is only covered in integration > tests. > Since > [DefaultGraphBuilderTest|https://github.com/apache/maven/blob/master/maven-core/src/test/java/org/apache/maven/graph/DefaultGraphBuilderTest.java] > now contains a multi module structure this flow can be tested in unit tests, > offering developers quicker feedback during development. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7000) metadata.mdo contains invalid link to schema
[
https://issues.apache.org/jira/browse/MNG-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228180#comment-17228180
]
Hudson commented on MNG-7000:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> metadata.mdo contains invalid link to schema
>
>
> Key: MNG-7000
> URL: https://issues.apache.org/jira/browse/MNG-7000
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> The location reads {{http://maven.apache.org/xsd/metadata-${version}.xsd}},
> but should read
> {{https://maven.apache.org/xsd/repository-metadata-${version}.xsd}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6999) Chained (consumer) XMLFilters can result in "floating" comments
[
https://issues.apache.org/jira/browse/MNG-6999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228186#comment-17228186
]
Hudson commented on MNG-6999:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Chained (consumer) XMLFilters can result in "floating" comments
> ---
>
> Key: MNG-6999
> URL: https://issues.apache.org/jira/browse/MNG-6999
> Project: Maven
> Issue Type: Bug
>Reporter: Robert Scholte
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.7.0
>
>
> Discovered while working on MNG-6957: I wanted to do the following:
> {code:xml}
>
> Z
> A
>
> {code}
> The ModulesXMLFilterTest contains tests related to comments, but when filters
> are changed, the lexicalHandlers are not chained correctly.
> The result: cleaned up modules, but leaving a comment behind.
> {code:xml}
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228174#comment-17228174
]
Hudson commented on MNG-6991:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {code}
> String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> {code}
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
> {code}
> request.setLocalRepositoryPath( determineLocalRepositoryPath( request
> ) );
> ...
> private String determineLocalRepositoryPath( final
> MavenExecutionRequest request )
> {
> return request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY,
> request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
> );
> }
> {code}
> effectively _always_ replacing the local repository definition, potentially
> nulling it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6993) Upgrade SLF4J to 1.7.30
[ https://issues.apache.org/jira/browse/MNG-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228177#comment-17228177 ] Hudson commented on MNG-6993: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Upgrade SLF4J to 1.7.30 > --- > > Key: MNG-6993 > URL: https://issues.apache.org/jira/browse/MNG-6993 > Project: Maven > Issue Type: Dependency upgrade >Affects Versions: 3.6.3 >Reporter: Slawomir Jaranowski >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > > Resolved issue: > https://jira.qos.ch/browse/SLF4J-469 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6672) Upgrade Maven Resolver to 1.4.2
[ https://issues.apache.org/jira/browse/MNG-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228150#comment-17228150 ] Hudson commented on MNG-6672: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Upgrade Maven Resolver to 1.4.2 > --- > > Key: MNG-6672 > URL: https://issues.apache.org/jira/browse/MNG-6672 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Affects Versions: 3.6.1 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > > Release Notes - Maven Resolver - Version 1.4.0 > * Bug > [MRESOLVER-86] - ResolveArtifactMojo from resolver example uses plugin > repositories to resolve dependencies > * New Feature > [MRESOLVER-10] - New 'TransitiveDependencyManager' supporting transitive > dependency management > [MRESOLVER-33] - New 'DefaultDependencyManager' managing dependencies on all > levels supporting transitive dependency management > * Improvement > [MRESOLVER-7] - Download dependency POMs in parallel > [MRESOLVER-84] - Add support for "release" qualifier > [MRESOLVER-87] - Refresh examples to use maven-resolver artifacts for demo > [MRESOLVER-88] - Code style cleanup to use Java 7 features > Release Notes - Maven Resolver - Version 1.4.1 > * Task > [MRESOLVER-92] - Revert MRESOLVER-7 > Release Notes - Maven Resolver - Version 1.4.2 > * Improvement > [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles > [MRESOLVER-102] - make build Reproducible -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6977) Use hyphen when creating builder threads (names)
[
https://issues.apache.org/jira/browse/MNG-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228171#comment-17228171
]
Hudson commented on MNG-6977:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Use hyphen when creating builder threads (names)
>
>
> Key: MNG-6977
> URL: https://issues.apache.org/jira/browse/MNG-6977
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.6.3
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
>
> We currently create bulder threads as {{BuilderThread %d}}. This is bit
> problematic because you cannot properly {{grep}} or {{cut}} through this due
> to the while space. Most other use a hyphen and is then a snap to analyze
> debug output.
>
> Proposal is to use {{BuilderThread-%d}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6983) Plugin key can get out of sync with artifactId and groupId
[
https://issues.apache.org/jira/browse/MNG-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228175#comment-17228175
]
Hudson commented on MNG-6983:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Plugin key can get out of sync with artifactId and groupId
> --
>
> Key: MNG-6983
> URL: https://issues.apache.org/jira/browse/MNG-6983
> Project: Maven
> Issue Type: Bug
> Components: core, Plugins and Lifecycle
>Affects Versions: 3.6.3
>Reporter: Paul Pazderski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: pluginNotExecuted.zip
>
>
> I have a project build with maven where some maven plugins are not executed
> without any warning or error shown in output. I was able to reproduce the
> issue with a minimal example. (see attachment)
> The expected result of this example is to get the one source file compiled if
> you invoke {{mvn compile}}.
> If I run this example using Maven 3.6.3 the following output appears:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:child
> >--
> [INFO] Building child 0.0.1-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ child
> ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> [...]\pluginNotExecuted\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child ---
> [INFO] No sources to compile
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.644 s
> [INFO] Finished at: [...]
> [INFO]
>
> {noformat}
> Notice that there is no execution of the build-helper-maven-plugin (and as
> consequence no source compiled) and no indication why it is missing.
> From what I've found the problem seem to be the usage of variable in the
> plugins groupId. If you replace either the variable in parent- or child-pom
> with the actual value the build shows a warning
> {noformat}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.example:child:jar:0.0.1-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 16, column 21
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {noformat}
> If you replace both variables with the actual value everything works as
> expected.
>
> I investigated the problem further and will provide more details with a pull
> request for a possible fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6981) Add --recursive option
[
https://issues.apache.org/jira/browse/MNG-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228183#comment-17228183
]
Hudson commented on MNG-6981:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Add --recursive option
> --
>
> Key: MNG-6981
> URL: https://issues.apache.org/jira/browse/MNG-6981
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.6.3
>Reporter: Knut Wannheden
>Assignee: Martin Kanters
>Priority: Minor
> Fix For: 3.7.0
>
>
> Since there is already a {{\--non-recursive}} option a new {{\--recursive}}
> option might be confusing, but let me explain my use case. I often use the
> {{-pl}} option and in a multi-module Maven project with more than just two
> "levels", I would like to be able to build a project (or set of projects)
> including all child-modules. This is, AFAIK, currently not possible and what
> I would like to use the new {{\--recursive}} (or similar) option for.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6919) maven-wrapper on windows
[ https://issues.apache.org/jira/browse/MNG-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228159#comment-17228159 ] Hudson commented on MNG-6919: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > maven-wrapper on windows > > > Key: MNG-6919 > URL: https://issues.apache.org/jira/browse/MNG-6919 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.7.0-candidate >Reporter: James Z.M. Gao >Assignee: Robert Scholte >Priority: Minor > Fix For: 3.7.0 > > > new maven-wrapper inherit 2 bugs for windows batch scripts: > # cannot read the config ".mvn\wrapper\maven-wrapper.properties" correctly > when the full path has space. > # -eof style of cmd scripts are not CRLF- (This is fixed by assembly-plugin > `lineEnding` settings) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7004) Refactor GitHub Actions environment variables since 'set-env' is deprecated
[
https://issues.apache.org/jira/browse/MNG-7004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228185#comment-17228185
]
Hudson commented on MNG-7004:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> Refactor GitHub Actions environment variables since 'set-env' is deprecated
> ---
>
> Key: MNG-7004
> URL: https://issues.apache.org/jira/browse/MNG-7004
> Project: Maven
> Issue Type: Improvement
>Reporter: Martin Kanters
>Assignee: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.7.0
>
>
> See the warnings generated on a typical master build:
> [https://github.com/apache/maven/actions/runs/316060775]
> {{The `set-env` command is deprecated and will be disabled soon. Please
> upgrade to using Environment Files. For more information see:
> [https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/]}}
> The fix provided in the blog seems simple, but let's make sure it keeps on
> working afterwards.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6949) As a developer on Maven Core I would like to verify my build before merge
[ https://issues.apache.org/jira/browse/MNG-6949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228166#comment-17228166 ] Hudson commented on MNG-6949: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > As a developer on Maven Core I would like to verify my build before merge > - > > Key: MNG-6949 > URL: https://issues.apache.org/jira/browse/MNG-6949 > Project: Maven > Issue Type: Improvement >Reporter: Martin Kanters >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.7.0 > > > One of the requirements before providing a pull request to Maven is that you > have to run `mvn verify` and the integration tests. This is to ensure that > the PR that is delivered is of good quality. I do not disagree with this > approach, but it can be easy to forget to run this, especially in the case of > processing (small) review comments. > For me it already happened a couple of times that a failing test was found at > the time when the pull request was getting merged in master. By utilizing > GitHub Actions we can ensure that the PR's requirements are fulfilled. This > is meant as an addition on top of local tests and the CI job on Jenkins tests > that commiters execute during merger, not a replacement. > > I have implemented this last weekend and would like to propose this. It is > based on another Maven project's GitHub Action workflow, but has been > extended. It features the following: > # mvn verify on Ubuntu, Windows and MacOS machines, with Java 8, 11, 14. > # integration tests against the new Maven build (from step 1). > By default it will run against the latest master version of > apache/maven-integration-testing. > However, if the developer has a branch with the same name as the maven PR on > a forked maven-integration-testing project, it will check that out instead. > Link to the pull request: [https://github.com/apache/maven/pull/365]. > Currently the action is not running on the PR itself, I guess that is due to > settings in the apache/maven project. > It is running on the branch of our fork, though: > [https://github.com/infosupport/maven/actions/runs/150771674]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6856) Remove dependency to Powermock
[ https://issues.apache.org/jira/browse/MNG-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228152#comment-17228152 ] Hudson commented on MNG-6856: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Remove dependency to Powermock > -- > > Key: MNG-6856 > URL: https://issues.apache.org/jira/browse/MNG-6856 > Project: Maven > Issue Type: Dependency upgrade >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Trivial > Fix For: 3.7.0 > > Time Spent: 10m > Remaining Estimate: 0h > > We use Powermock only in one set of tests, in a class > `StringSearchModelInterpolator` that is no longer used in Maven Core -- 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=17228178#comment-17228178
]
Hudson commented on MNG-6965:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> 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-6996) Upgrade Maven Resolver to 1.6.1
[ https://issues.apache.org/jira/browse/MNG-6996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228179#comment-17228179 ] Hudson commented on MNG-6996: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Upgrade Maven Resolver to 1.6.1 > --- > > Key: MNG-6996 > URL: https://issues.apache.org/jira/browse/MNG-6996 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > > Release Notes - Maven Resolver - Version 1.6.1 > ** Sub-task > * [MRESOLVER-139] - Make SimpleDigest use SHA-1 or MD5 only > * [MRESOLVER-140] - Default to SHA-1 and MD5 hashing algorithms > ** Bug > * [MRESOLVER-25] - Resume support is broken under high concurrency > * [MRESOLVER-114] - ArtifactNotFoundExceptions when building in parallel > * [MRESOLVER-129] - Exclusion has no setters > * [MRESOLVER-137] - Make OSGi bundles reproducible > * [MRESOLVER-138] - MRESOLVER-56 introduces severe performance regression > ** New Feature > * [MRESOLVER-109] - AndDependencySelector should override toString > * [MRESOLVER-115] - Make checksum algorithms configurable > * [MRESOLVER-123] - Provide a global locking sync context by default > * [MRESOLVER-131] - Introduce a Redisson-based SyncContextFactory > ** Improvement > * [MRESOLVER-56] - Support SHA-256 and SHA-512 as checksums > * [MRESOLVER-116] - Add page with all supported configuration options > * [MRESOLVER-125] - Use type conversions returning primitives > * [MRESOLVER-127] - Don't use boolean for property > 'aether.updateCheckManager.sessionState' > * [MRESOLVER-136] - Migrate from maven-bundle-plugin to bnd-maven-plugin > ** Task > * [MRESOLVER-119] - Turn log messages to SLF4J placeholders > * [MRESOLVER-130] - Move GlobalSyncContextFactory to a separate module > * [MRESOLVER-132] - Remove synchronization in TrackingFileManager > ** Dependency upgrade > * [MRESOLVER-105] - Update Plexus Components > * [MRESOLVER-106] - Update HttpComponents > * [MRESOLVER-107] - Update Wagon Provider API to 3.4.0 > * [MRESOLVER-108] - Update mockito-core to 2.28.2 > * [MRESOLVER-117] - Upgrade SLF4J to 1.7.30 > * [MRESOLVER-118] - Upgrade Sisu Components to 0.3.4 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-5937) Maven-Wrapper for unified project environments (analog the Gradle wrapper)
[ https://issues.apache.org/jira/browse/MNG-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228155#comment-17228155 ] Hudson commented on MNG-5937: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Maven-Wrapper for unified project environments (analog the Gradle wrapper) > -- > > Key: MNG-5937 > URL: https://issues.apache.org/jira/browse/MNG-5937 > Project: Maven > Issue Type: Improvement > Components: Command Line >Reporter: Robert Weiser >Assignee: Robert Scholte >Priority: Major > Fix For: 3.7.0 > > > It would be nice to provide a wrapper for maven which behaves similarily to > the wrapper Gradle has. This would allow projects to share Maven in a certain > version along with some project-specific Maven options like for example the > location of the user or the global settings files or the maximum java heap > size to use. > There already are projects on github (e.g.: > https://github.com/takari/maven-wrapper) providing said feature, however it > would be nice to have it developed and maintained by the very people > providing us with the offical Maven release. > Cheers, Robert -- 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=17228172#comment-17228172
]
Hudson commented on MNG-6772:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> 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-6873) Inconsistent library versions notice
[ https://issues.apache.org/jira/browse/MNG-6873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228154#comment-17228154 ] Hudson commented on MNG-6873: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Inconsistent library versions notice > > > Key: MNG-6873 > URL: https://issues.apache.org/jira/browse/MNG-6873 > Project: Maven > Issue Type: Improvement >Reporter: Kaifeng Huang >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.7.0 > > Attachments: apache maven.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > > Hi. I have implemented a tool to detect library version inconsistencies. Your > project have 1 inconsistent library and 12 false consistent libraries. > > Take junit:junit for example, this library is declared as version 3.8.1 in > maven-core/src/test/resources-project-builder/dependency-inheritance, 4.4 in > maven-core/src/test/resources-project-builder/dependency-inheritance/sub and > etc... Such version inconsistencies may cause unnecessary maintenance effort > in the long run. For example, if two modules become inter-dependent, library > version conflict may happen. It has already become a common issue and hinders > development progress. Thus a version harmonization is necessary. > > Provided we applied a version harmonization, I calculated the cost it may > have to harmonize to all upper versions including an up-to-date one. The cost > refers to POM config changes and API invocation changes. Take junit:junit for > example, if we harmonize all the library versions into 4.4. The concern is, > how much should the project code adapt to the newer library version. We list > an effort table to quantify the harmonization cost. > > The effort table shows the overall harmonization cost on APIs. It seems your > project have no API invokes on this library, which could be safely upgrade to > 4.4 > ||Index||Module||NA(NAC)||NDA(NDAC)||NMA(NMAC)|| > |1|maven-core/src/test/resources-project-builder/dependency-inheritance|0(0)|0(0)|0(0)| > |2|maven-core/src/test/resources-project-builder/dependency-inheritance/sub|0(0)|0(0)|0(0)| > > Also we provided another table to show the potential files that may be > affected due to library API change, which could help to spot the concerned > API usage and rerun the test cases. > As for false consistency, take junit junit jar for example. The library is > declared in version 4.13 in all modules. However they are declared > differently. As components are developed in parallel, if one single library > version is updated, which could become inconsistent as mentioned above, may > cause above-mentioned inconsistency issues > If you are interested, you can have a more complete and detailed report in > the attached PDF file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6819) NullPointerException for DefaultArtifactDescriptorReader.loadPom
[
https://issues.apache.org/jira/browse/MNG-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228157#comment-17228157
]
Hudson commented on MNG-6819:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/
> NullPointerException for DefaultArtifactDescriptorReader.loadPom
>
>
> Key: MNG-6819
> URL: https://issues.apache.org/jira/browse/MNG-6819
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.6.2, 3.6.3
>Reporter: Darcy Shen
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.7.0
>
>
> Here is a clue to reproduce the NPE.
> {code:xml}
>
> maven-antrun-plugin
>
>
> package
>
>
>
> src="${project.build.directory}/${project.build.finalName}.${project.packaging}"
> dest="${project.build.directory}/xxx" />
>
>
>
> run
>
>
>
>
> {code}
> project.build.finalName is the previous value, and the interpolated value is
> null.
> {noformat}
> $ mvn clean compile -e # on a private project
> [ERROR] NullPointerException
> java.lang.NullPointerException
> at java.util.Hashtable$Entry.setValue (Hashtable.java:1286)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1429)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:1027)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator$ModelVisitor.visit
> (StringVisitorModelInterpolator.java:170)
> at
> org.apache.maven.model.interpolation.StringVisitorModelInterpolator.interpolateModel
> (StringVisitorModelInterpolator.java:107)
> at org.apache.maven.model.building.DefaultModelBuilder.interpolateModel
> (DefaultModelBuilder.java:789)
> at org.apache.maven.model.building.DefaultModelBuilder.build
> (DefaultModelBuilder.java:393)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom
> (DefaultArtifactDescriptorReader.java:292)
> at
> org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor
> (DefaultArtifactDescriptorReader.java:171)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.resolveCachedArtifactDescriptor
> (DefaultDependencyCollector.java:541)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.getArtifactDescriptorResult
> (DefaultDependencyCollector.java:524)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:412)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:365)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:352)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:509)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:461)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:365)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:352)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:509)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:461)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
> (DefaultDependencyCollector.java:365)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.process
> (DefaultDependencyCollector.java:352)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.doRecurse
> (DefaultDependencyCollector.java:509)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.processDependency
>
[jira] [Commented] (MNG-6897) Upgrade Maven Wagon to 3.4.0
[ https://issues.apache.org/jira/browse/MNG-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228149#comment-17228149 ] Hudson commented on MNG-6897: - Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-6169/MNG-6556 #14 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6169%252FMNG-6556/14/ > Upgrade Maven Wagon to 3.4.0 > > > Key: MNG-6897 > URL: https://issues.apache.org/jira/browse/MNG-6897 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Affects Versions: 3.6.3 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 3.7.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
