[GitHub] [maven-indexer] dependabot[bot] opened a new pull request #146: Bump commons-cli from 1.2 to 1.5.0
dependabot[bot] opened a new pull request #146: URL: https://github.com/apache/maven-indexer/pull/146 Bumps commons-cli from 1.2 to 1.5.0. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-script-interpreter] dependabot[bot] opened a new pull request #54: Bump actions/cache from 2.1.6 to 2.1.7
dependabot[bot] opened a new pull request #54: URL: https://github.com/apache/maven-script-interpreter/pull/54 Bumps [actions/cache](https://github.com/actions/cache) from 2.1.6 to 2.1.7. Release notes Sourced from https://github.com/actions/cache/releases";>actions/cache's releases. v2.1.7 Support 10GB cache upload using the latest version 1.0.8 of https://www.npmjs.com/package/@actions/cache";>@actions/cache Commits https://github.com/actions/cache/commit/937d24475381cd9c75ae6db12cb4e79714b926ed";>937d244 bumping up action version to 2.1.7 (https://github-redirect.dependabot.com/actions/cache/issues/683";>#683) https://github.com/actions/cache/commit/eb0698d1c508f8573fddfe25566f10a4b1344504";>eb0698d Bumping up @actions/cache version to 1.0.8 (https://github-redirect.dependabot.com/actions/cache/issues/682";>#682) https://github.com/actions/cache/commit/67b6d52d50609f6166e3ea1d8872aca3a4763bd2";>67b6d52 (R renv) Remove unused renv-cache-path variable (https://github-redirect.dependabot.com/actions/cache/issues/663";>#663) https://github.com/actions/cache/commit/92f67a482915a145e9372ed84b9e7f13538ecc69";>92f67a4 (R renv) Fix Renv package cache location in examples (https://github-redirect.dependabot.com/actions/cache/issues/660";>#660) https://github.com/actions/cache/commit/6bbe742add91b3db4abf110e742a967ec789958f";>6bbe742 Use existing check-dist implementation (https://github-redirect.dependabot.com/actions/cache/issues/618";>#618) https://github.com/actions/cache/commit/c9db520cf31dc27e42864cc3687b0d70284cc5fc";>c9db520 Create check-dist.yml (https://github-redirect.dependabot.com/actions/cache/issues/604";>#604) https://github.com/actions/cache/commit/10906ba9cd642bcc07f0f38a95a57e5c1361d156";>10906ba Bump ws from 5.2.2 to 5.2.3 (https://github-redirect.dependabot.com/actions/cache/issues/610";>#610) https://github.com/actions/cache/commit/2ebdcff279bac9704c2b319b25ac54b63d6800c2";>2ebdcff Add "see more" link to GHE-not-supported warning (https://github-redirect.dependabot.com/actions/cache/issues/609";>#609) https://github.com/actions/cache/commit/5807af2642b6ffc80df306359122fd0ff9b571b8";>5807af2 Fix bugs in example of how to use with pipenv (https://github-redirect.dependabot.com/actions/cache/issues/607";>#607) https://github.com/actions/cache/commit/0638051e9af2c23d10bb70fa9beffcad6cff9ce3";>0638051 Golang example tweak - add go-build path - rebuild page TOC (https://github-redirect.dependabot.com/actions/cache/issues/577";>#577) See full diff in https://github.com/actions/cache/compare/v2.1.6...v2.1.7";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-javadoc-plugin] dependabot[bot] opened a new pull request #109: Bump actions/cache from 2.1.6 to 2.1.7
dependabot[bot] opened a new pull request #109: URL: https://github.com/apache/maven-javadoc-plugin/pull/109 Bumps [actions/cache](https://github.com/actions/cache) from 2.1.6 to 2.1.7. Release notes Sourced from https://github.com/actions/cache/releases";>actions/cache's releases. v2.1.7 Support 10GB cache upload using the latest version 1.0.8 of https://www.npmjs.com/package/@actions/cache";>@actions/cache Commits https://github.com/actions/cache/commit/937d24475381cd9c75ae6db12cb4e79714b926ed";>937d244 bumping up action version to 2.1.7 (https://github-redirect.dependabot.com/actions/cache/issues/683";>#683) https://github.com/actions/cache/commit/eb0698d1c508f8573fddfe25566f10a4b1344504";>eb0698d Bumping up @actions/cache version to 1.0.8 (https://github-redirect.dependabot.com/actions/cache/issues/682";>#682) https://github.com/actions/cache/commit/67b6d52d50609f6166e3ea1d8872aca3a4763bd2";>67b6d52 (R renv) Remove unused renv-cache-path variable (https://github-redirect.dependabot.com/actions/cache/issues/663";>#663) https://github.com/actions/cache/commit/92f67a482915a145e9372ed84b9e7f13538ecc69";>92f67a4 (R renv) Fix Renv package cache location in examples (https://github-redirect.dependabot.com/actions/cache/issues/660";>#660) https://github.com/actions/cache/commit/6bbe742add91b3db4abf110e742a967ec789958f";>6bbe742 Use existing check-dist implementation (https://github-redirect.dependabot.com/actions/cache/issues/618";>#618) https://github.com/actions/cache/commit/c9db520cf31dc27e42864cc3687b0d70284cc5fc";>c9db520 Create check-dist.yml (https://github-redirect.dependabot.com/actions/cache/issues/604";>#604) https://github.com/actions/cache/commit/10906ba9cd642bcc07f0f38a95a57e5c1361d156";>10906ba Bump ws from 5.2.2 to 5.2.3 (https://github-redirect.dependabot.com/actions/cache/issues/610";>#610) https://github.com/actions/cache/commit/2ebdcff279bac9704c2b319b25ac54b63d6800c2";>2ebdcff Add "see more" link to GHE-not-supported warning (https://github-redirect.dependabot.com/actions/cache/issues/609";>#609) https://github.com/actions/cache/commit/5807af2642b6ffc80df306359122fd0ff9b571b8";>5807af2 Fix bugs in example of how to use with pipenv (https://github-redirect.dependabot.com/actions/cache/issues/607";>#607) https://github.com/actions/cache/commit/0638051e9af2c23d10bb70fa9beffcad6cff9ce3";>0638051 Golang example tweak - add go-build path - rebuild page TOC (https://github-redirect.dependabot.com/actions/cache/issues/577";>#577) See full diff in https://github.com/actions/cache/compare/v2.1.6...v2.1.7";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) 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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-checkstyle-plugin] lvjp opened a new pull request #53: Fix check
lvjp opened a new pull request #53: URL: https://github.com/apache/maven-checkstyle-plugin/pull/53 Since the website of checkstyle URL changed, I just update links. I also fix a badly formated link... This permit generated report to use HTTPS link :-) --- Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MCHECKSTYLE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MCHECKSTYLE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MCHECKSTYLE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7344) Effective pom should contain more finegrained details regarding its path.
Robert Scholte created MNG-7344: --- Summary: Effective pom should contain more finegrained details regarding its path. Key: MNG-7344 URL: https://issues.apache.org/jira/browse/MNG-7344 Project: Maven Issue Type: Improvement Components: Inheritance and Interpolation, POM Reporter: Robert Scholte To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model it must be possible to get the resolution path to that element. The following are known to add elements to the effective pom without pure inhertence - BOMs - maven-tiles by [~talios] Without this feature is is very hard to detect where elements are coming from. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] rfscholte commented on pull request #603: [MPH-183] BOM hierarchy in InputSource
rfscholte commented on pull request #603: URL: https://github.com/apache/maven/pull/603#issuecomment-977189747 I've created https://issues.apache.org/jira/browse/MNG-7344 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #131: [MRESOLVER-219] File advisory locking based NamedLocks
michael-o commented on a change in pull request #131:
URL: https://github.com/apache/maven-resolver/pull/131#discussion_r755484931
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/named/TakariNameMapper.java
##
@@ -0,0 +1,126 @@
+package org.eclipse.aether.internal.impl.synccontext.named;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.support.FileSystemFriendly;
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.UncheckedIOException;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.TreeSet;
+import java.util.concurrent.ConcurrentHashMap;
+
+/**
+ * A {@link NameMapper} that creates same name mapping as Takari Local
Repository does, with baseDir (local repo).
+ * Part of code blatantly copies parts of the Takari {@code
LockingSyncContext}.
+ *
+ * @see https://github.com/takari/takari-local-repository/blob/master/src/main/java/io/takari/aether/concurrency/LockingSyncContext.java";>Takari
+ * LockingSyncContext.java
+ */
+@Singleton
+@Named( TakariNameMapper.NAME )
+public class TakariNameMapper
+implements NameMapper, FileSystemFriendly
+{
+public static final String NAME = "takari";
+
+private static final char SEPARATOR = '~';
+
+private final ConcurrentHashMap baseDirs;
+
+public TakariNameMapper()
+{
+this.baseDirs = new ConcurrentHashMap<>();
+}
+
+@Override
+public TreeSet nameLocks( final RepositorySystemSession session,
+ final Collection
artifacts,
+ final Collection
metadatas )
+{
+File localRepositoryBasedir =
session.getLocalRepository().getBasedir();
+Path baseDir = baseDirs.computeIfAbsent(
Review comment:
where is basedirs used? can this change within a session?
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/named/TakariNameMapper.java
##
@@ -0,0 +1,126 @@
+package org.eclipse.aether.internal.impl.synccontext.named;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.support.FileSystemFriendly;
+
+import javax.inject.Named;
+import javax.inject.Singleton;
+
+import java.io.File;
+import java.io.IOException;
+import java.io.UncheckedIOException;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.TreeSet;
+import java.util.concurrent.ConcurrentHashMap;
+
+/**
+ * A {@link NameMapper} that creates same name mapping as Takari Local
Repository does, with baseDir (local repo).
+ * Part of code blatantly copies parts of the Takari {@code
LockingSyncContext}.
+ *
+ * @see https://github.com/takari/takari-local-repository/blob/master/src/main/java/io/takari/aether/concurrency/LockingSyncContext.java";>Takari
Review comment:
this should be a permanent link
##
File path:
maven-resolver-named-locks/src/main/java/org/eclipse/aether/named/support/Retry.java
##
@@ -0,0 +1,98 @@
+package org.eclip
[jira] [Commented] (SCM-883) ScmFileSet DEFAULT_EXCLUDES too restrictive
[ https://issues.apache.org/jira/browse/SCM-883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448239#comment-17448239 ] Fabian Köntopp commented on SCM-883: [~michael-o] Not critical for me as I'm not using it right now. Also it's more than three years ago now, so I guess we can wait I little bit longer ;) > ScmFileSet DEFAULT_EXCLUDES too restrictive > --- > > Key: SCM-883 > URL: https://issues.apache.org/jira/browse/SCM-883 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-api >Affects Versions: 1.9.5 >Reporter: Fabian Köntopp >Assignee: Michael Osipov >Priority: Minor > Fix For: 2.0.0-M1, 1.12.1 > > > We are trying to automate a process in which a default *.gitignore* file > *only* (ignoring the current state of the repository) is added to a > repository at the root level. Because of the DEFAULT_EXCLUDES in the > ScmFileSet-Class this is impossible because .gitignore is listed there and > the default excludes are always added to the final exlude list. > In my opinion the .gitignore file should not be listed there because such > files are part of a git repository. At least it should be possible to > override the excludes completely without the DEFAULT_EXCLUDES always being > added. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] AlexanderAshitkin commented on pull request #617: [MNG-7129] http repo refactoring for java8
AlexanderAshitkin commented on pull request #617: URL: https://github.com/apache/maven/pull/617#issuecomment-977027348 > I believe that this entire code needs to be rewritten to use Wagon instead of manually fiddling with `HttpClient`. good point and should not be a big deal. will try to do it in following prs -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] AlexanderAshitkin opened a new pull request #617: [MNG-7129] http repo refactoring for java8
AlexanderAshitkin opened a new pull request #617: URL: https://github.com/apache/maven/pull/617 Repos refactoring for java8 - using optionals instead of nullables Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] ctrueden edited a comment on pull request #121: [MNG-6206] display deprecation build warning in case when dependencies use metaversions (LATEST or RELEASE)
ctrueden edited a comment on pull request #121: URL: https://github.com/apache/maven/pull/121#issuecomment-972108495 @dejan2609 @khmarbaise I use LATEST and RELEASE a lot for various purposes, such as CLI tooling that automatically synthesizes POMs to perform various tasks. I personally feel deprecating these metaversions was a mistake—I find them incredibly useful, with the understanding that I would never use them for production reproducible builds. But I do understand the rationale: we don't want to encourage anyone to use these in a way that harms the stability of dependency resolution, reproducibility-wise. So I'm OK with it, as long as there is a migration path forward for these sorts of use cases. But what is that path? I cannot find a way to replicate either of the metaversion behaviors using version ranges. There are problems with version ranges ([MNG-3092](https://issues.apache.org/jira/browse/MNG-3092), [MNG-6049](https://issues.apache.org/jira/browse/MNG-6049)) preventing them from being used as a replacement for LATEST or RELEASE. Furthermore, in my tests, specifying a version range like `[0,)` causes Maven to download POMs at a bunch of (maybe all?) versions of an artifact, whereas `LATEST` and `RELEASE` do not trigger en masse downloading.l Is there a non-deprecated syntax that has equivalent behavior? As things stand, I am concerned that support for these metaversions is going to disappear in a future version of Maven. If there is no way to achieve the metaversion behavior without them, please let me know, so that I can open an issue on the JIRA. Thanks! Edit: I filed [MNG-7343](https://issues.apache.org/jira/projects/MNG/issues/MNG-7343). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
[
https://issues.apache.org/jira/browse/MNG-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Curtis Rueden updated MNG-7343:
---
Description:
I use LATEST and RELEASE a lot for various purposes, such as CLI tooling that
automatically synthesizes POMs to perform various tasks. I personally feel
deprecating these metaversions was a mistake—I find them incredibly useful,
with the understanding that I would never use them for production reproducible
builds. But I do understand the rationale: we don't want to encourage anyone to
use these in a way that harms the stability of dependency resolution,
reproducibility-wise. So I'm OK with it, as long as there is a migration path
forward for these sorts of use cases.
But what is that path? I cannot find a way to replicate either of the
metaversion behaviors using version ranges. There are problems with version
ranges (MNG-3092, MNG-6049) preventing them from being used as a replacement
for LATEST or RELEASE. Furthermore, in my tests, specifying a version range
like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?) versions
of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en masse
downloading.l
Is there a non-deprecated syntax that has equivalent behavior? As things stand,
I am concerned that support for these metaversions is going to disappear in a
future version of Maven without a feasible migration path forward.
> Document a working migration path away from LATEST and RELEASE metaversions
> ---
>
> Key: MNG-7343
> URL: https://issues.apache.org/jira/browse/MNG-7343
> Project: Maven
> Issue Type: Bug
>Reporter: Curtis Rueden
>Priority: Major
>
> I use LATEST and RELEASE a lot for various purposes, such as CLI tooling that
> automatically synthesizes POMs to perform various tasks. I personally feel
> deprecating these metaversions was a mistake—I find them incredibly useful,
> with the understanding that I would never use them for production
> reproducible builds. But I do understand the rationale: we don't want to
> encourage anyone to use these in a way that harms the stability of dependency
> resolution, reproducibility-wise. So I'm OK with it, as long as there is a
> migration path forward for these sorts of use cases.
> But what is that path? I cannot find a way to replicate either of the
> metaversion behaviors using version ranges. There are problems with version
> ranges (MNG-3092, MNG-6049) preventing them from being used as a replacement
> for LATEST or RELEASE. Furthermore, in my tests, specifying a version range
> like {{[0,)}} causes Maven to download POMs at a bunch of (maybe all?)
> versions of an artifact, whereas {{LATEST}} and {{RELEASE}} do not trigger en
> masse downloading.l
> Is there a non-deprecated syntax that has equivalent behavior? As things
> stand, I am concerned that support for these metaversions is going to
> disappear in a future version of Maven without a feasible migration path
> forward.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MNG-7343) Document a working migration path away from LATEST and RELEASE metaversions
Curtis Rueden created MNG-7343: -- Summary: Document a working migration path away from LATEST and RELEASE metaversions Key: MNG-7343 URL: https://issues.apache.org/jira/browse/MNG-7343 Project: Maven Issue Type: Bug Reporter: Curtis Rueden -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] cstamas commented on pull request #131: [MRESOLVER-219] File advisory locking based NamedLocks
cstamas commented on pull request #131: URL: https://github.com/apache/maven-resolver/pull/131#issuecomment-976834812 @michael-o a bit more :wink: doing it... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on pull request #131: [MRESOLVER-219] File advisory locking based NamedLocks
michael-o commented on pull request #131: URL: https://github.com/apache/maven-resolver/pull/131#issuecomment-976830948 Now we can continue, please rebase and push again. There is only one conflict in `maven-resolver-impl/src/test/java/org/eclipse/aether/internal/impl/synccontext/NamedLockFactoryAdapterTestSupport.java`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MRESOLVER-227) Refactor NamedLockFactorySelector to a managed component
[ https://issues.apache.org/jira/browse/MRESOLVER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MRESOLVER-227. Resolution: Fixed Fixed with [b7a5b411d994d2f7093358299184a87d8328f51d|https://gitbox.apache.org/repos/asf?p=maven-resolver.git&a=commit&h=b7a5b411d994d2f7093358299184a87d8328f51d]. > Refactor NamedLockFactorySelector to a managed component > > > Key: MRESOLVER-227 > URL: https://issues.apache.org/jira/browse/MRESOLVER-227 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Michael Osipov >Assignee: Tamás Cservenák >Priority: Major > Fix For: 1.7.3 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] asfgit closed pull request #135: Refactor NamedLockFactorySelector
asfgit closed pull request #135: URL: https://github.com/apache/maven-resolver/pull/135 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MRESOLVER-227) Refactor NamedLockFactorySelector to a managed component
Michael Osipov created MRESOLVER-227: Summary: Refactor NamedLockFactorySelector to a managed component Key: MRESOLVER-227 URL: https://issues.apache.org/jira/browse/MRESOLVER-227 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Michael Osipov Assignee: Tamás Cservenák Fix For: 1.7.3 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] michael-o commented on a change in pull request #616: [MNG-7160] Fix core extension classloader
michael-o commented on a change in pull request #616: URL: https://github.com/apache/maven/pull/616#discussion_r755280186 ## File path: maven-embedder/src/main/mdo/core-extensions.mdo ## @@ -82,6 +82,14 @@ true String + + classloadingStrategy Review comment: I think this should be `classLoadingStrategy` because the object is called `ClassLoader` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] michael-o commented on a change in pull request #616: [MNG-7160] Fix core extension classloader
michael-o commented on a change in pull request #616: URL: https://github.com/apache/maven/pull/616#discussion_r755279757 ## File path: maven-embedder/src/main/mdo/core-extensions.mdo ## @@ -82,6 +82,14 @@ true String + + classloadingStrategy + The classloading strategy (self-first, parent-first, plugin) Review comment: I thin -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet merged pull request #614: [MNG-7129] Restore artifacts from cache lazily
gnodet merged pull request #614: URL: https://github.com/apache/maven/pull/614 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #616: [MNG-7160] Fix core extension classloader
gnodet commented on pull request #616: URL: https://github.com/apache/maven/pull/616#issuecomment-976683464 > I know you've gone through the effort here to get the caching extension to work from `lib/ext` but is that how you envision it working? If you have a large organization with many developers I think it would be preferable to configure it from the POM no? Or does this extension do some capabilities earlier than an extension in the form of a plugin? > > I realize the way extensions in `lib/ext` versus being defined in a plugin have always worked differently, and I can't off the the top of my head remember why we did that, but maybe they should be aligned so that artifacts are resolved in the same way. Currently, they do not work exactly the same. Some beans are discovered a bit too early in the process. For example `EventSpy` implementations can't be registered inside an extension discovered from the POM afaik. This is also true for a few other beans. The new `plugin` class loading strategy that I propose aims at reconciling the class loaders difference. I also plan to raise a PR so that some beans are discovered later in the process inside the `@SessionScoped`, such as `MojoExecutor` and related beans. This would allow the caching extension from #607 to be registered in the POM, which is not currently possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1000) Shared GitHub Actions
Slawomir Jaranowski created MSHARED-1000: Summary: Shared GitHub Actions Key: MSHARED-1000 URL: https://issues.apache.org/jira/browse/MSHARED-1000 Project: Maven Shared Components Issue Type: Improvement Components: maven-artifact-transfer Reporter: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-resolver] cstamas commented on pull request #134: Refactor source of time
cstamas commented on pull request #134: URL: https://github.com/apache/maven-resolver/pull/134#issuecomment-976663290 Superseded by https://github.com/apache/maven-resolver/pull/135 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas closed pull request #134: Refactor source of time
cstamas closed pull request #134: URL: https://github.com/apache/maven-resolver/pull/134 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-999) Shared GitHub Actions
Slawomir Jaranowski created MSHARED-999: --- Summary: Shared GitHub Actions Key: MSHARED-999 URL: https://issues.apache.org/jira/browse/MSHARED-999 Project: Maven Shared Components Issue Type: Improvement Components: maven-invoker Reporter: Slawomir Jaranowski -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven] jvanzyl commented on pull request #616: [MNG-7160] Fix core extension classloader
jvanzyl commented on pull request #616: URL: https://github.com/apache/maven/pull/616#issuecomment-976624269 I know you've gone through the effort here to get the caching extension to work from `lib/ext` but is that how you envision it working? If you have a large organization with many developers I think it would be preferable to configure it from the POM no? Or does this extension do some capabilities earlier than an extension in the form of a plugin? I realize the way extensions in `lib/ext` versus being defined in a plugin have always worked differently, and I can't off the the top of my head remember why we did that, but maybe they should be aligned so that artifacts are resolved in the same way. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] cstamas opened a new pull request #135: Refactory NamedLockFactorySelector
cstamas opened a new pull request #135: URL: https://github.com/apache/maven-resolver/pull/135 This PR contains NamedLockFactorySelector related changes: * NamedLockFactorySelector made a true component (was a static helper) * avoid initing static final variables from system properties (mvnd) * refactor source of time parameters used by adapter, they have nothing to do with lock factories. * adapter time related parameters are sourced from Session Split for simpler review. - Original changes: * https://github.com/apache/maven-resolver/pull/131 * https://github.com/apache/maven-resolver/pull/134 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet edited a comment on pull request #616: [MNG-7160] Fix core extension classloader
gnodet edited a comment on pull request #616: URL: https://github.com/apache/maven/pull/616#issuecomment-976589952 I've rewritten the PR to allow the user to choose the class loading strategy and added an integration test (https://github.com/apache/maven-integration-testing/pull/125) showing the 4 possibilities and the differences in class loading. I'm not sure if the fact that even when a dependency with an explicit `provided` scope is defined, the same dependency leaks through as a transitive dependency is a problem or not. Thoughts ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #616: [MNG-7160] Fix core extension classloader
gnodet commented on pull request #616: URL: https://github.com/apache/maven/pull/616#issuecomment-976589952 I'm rewritten the PR to allow the user to choose the class loading strategy and added an integration test showing the 4 possibilities and the differences in class loading. I'm not sure if the fact that even when a dependency with an explicit `provided` scope is defined, the same dependency leaks through as a transitive dependency is a problem or not. Thoughts ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #131: [MRESOLVER-219] File advisory locking based NamedLocks
michael-o commented on a change in pull request #131:
URL: https://github.com/apache/maven-resolver/pull/131#discussion_r755153632
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/named/NamedLockFactoryAdapter.java
##
@@ -52,6 +53,13 @@ public NamedLockFactoryAdapter( final NameMapper nameMapper,
final NamedLockFact
{
this.nameMapper = Objects.requireNonNull( nameMapper );
this.namedLockFactory = Objects.requireNonNull( namedLockFactory );
+if ( this.namedLockFactory instanceof FileSystemFriendly
+&& !( this.nameMapper instanceof FileSystemFriendly ) )
+{
+throw new IllegalArgumentException(
Review comment:
Agreed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] cstamas commented on a change in pull request #131: [MRESOLVER-219] File advisory locking based NamedLocks
cstamas commented on a change in pull request #131:
URL: https://github.com/apache/maven-resolver/pull/131#discussion_r755145112
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/named/NamedLockFactoryAdapter.java
##
@@ -52,6 +53,13 @@ public NamedLockFactoryAdapter( final NameMapper nameMapper,
final NamedLockFact
{
this.nameMapper = Objects.requireNonNull( nameMapper );
this.namedLockFactory = Objects.requireNonNull( namedLockFactory );
+if ( this.namedLockFactory instanceof FileSystemFriendly
+&& !( this.nameMapper instanceof FileSystemFriendly ) )
+{
+throw new IllegalArgumentException(
Review comment:
IAE as if this happens, it means a) user selected them (as default ones
are not marked ones, so we do not enter here) and b) user paired wrong ones.
So, a) + b) simply means "wrong combo set by user" -> IAE IMHO.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #131: [MRESOLVER-219] File advisory locking based NamedLocks
michael-o commented on a change in pull request #131:
URL: https://github.com/apache/maven-resolver/pull/131#discussion_r755132279
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/named/NamedLockFactoryAdapter.java
##
@@ -52,6 +53,13 @@ public NamedLockFactoryAdapter( final NameMapper nameMapper,
final NamedLockFact
{
this.nameMapper = Objects.requireNonNull( nameMapper );
this.namedLockFactory = Objects.requireNonNull( namedLockFactory );
+if ( this.namedLockFactory instanceof FileSystemFriendly
+&& !( this.nameMapper instanceof FileSystemFriendly ) )
+{
+throw new IllegalArgumentException(
Review comment:
IAE or ISE?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-javadoc-plugin] slawekjaranowski commented on pull request #104: [MJAVADOC-694] Avoid empty warn message from getResolvePathResult
slawekjaranowski commented on pull request #104: URL: https://github.com/apache/maven-javadoc-plugin/pull/104#issuecomment-976321661 Thanks for approval, so please merge and process jira issue -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MENFORCER-405) Enforcer plugin does not fail for duplicate dependency defined in multi module project
[
https://issues.apache.org/jira/browse/MENFORCER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kaustav Das updated MENFORCER-405:
--
Description:
I have a multi module project and have accidentally defined dependency of one
artifact in multiple child maven module each having different version. Enforcer
plugin not able to detect this duplicate dependency and project gets build
successfully
Plugin definition in pom
{code:java}
org.apache.maven.plugins
maven-enforcer-plugin 3.0.0
no-duplicate-declared-dependencies
enforce
{code}
was:
I have a multi module project and have accidentally defined dependency of one
artifact in multiple child maven module each having different version. Enforcer
plugin not able to detect this duplicate dependency and project gets build
successfully
Plugin definition in pom
{code:java}
org.apache.maven.plugins
maven-enforcer-plugin 3.0.0
no-duplicate-declared-dependencies
enforce
{code}
Environment: apache maven 3.3.9
> Enforcer plugin does not fail for duplicate dependency defined in multi
> module project
> --
>
> Key: MENFORCER-405
> URL: https://issues.apache.org/jira/browse/MENFORCER-405
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
> Environment: apache maven 3.3.9
>Reporter: Kaustav Das
>Priority: Major
>
> I have a multi module project and have accidentally defined dependency of one
> artifact in multiple child maven module each having different version.
> Enforcer plugin not able to detect this duplicate dependency and project gets
> build successfully
>
> Plugin definition in pom
> {code:java}
> org.apache.maven.plugins
> maven-enforcer-plugin 3.0.0
> no-duplicate-declared-dependencies
> enforce
>
>
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MENFORCER-406) Enforcer plugin does not fail for duplicate dependency coming via transitive dependency
Kaustav Das created MENFORCER-406:
-
Summary: Enforcer plugin does not fail for duplicate dependency
coming via transitive dependency
Key: MENFORCER-406
URL: https://issues.apache.org/jira/browse/MENFORCER-406
Project: Maven Enforcer Plugin
Issue Type: Bug
Components: Plugin
Affects Versions: 3.0.0
Environment: apache maven 3.3.9
Reporter: Kaustav Das
Enforcer plugin not able to detect this duplicate dependency coming via
transitive dependency and project gets build successfully. Is there any way to
define any rule to enable the same?
Defined Plugin in pom
{code:java}
org.apache.maven.plugins
maven-enforcer-plugin 3.0.0
no-duplicate-declared-dependencies
enforce
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MENFORCER-405) Enforcer plugin does not fail for duplicate dependency defined in multi module project
[
https://issues.apache.org/jira/browse/MENFORCER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kaustav Das updated MENFORCER-405:
--
Description:
I have a multi module project and have accidentally defined dependency of one
artifact in multiple child maven module each having different version. Enforcer
plugin not able to detect this duplicate dependency and project gets build
successfully
Plugin definition in pom
{code:java}
org.apache.maven.plugins
maven-enforcer-plugin 3.0.0
no-duplicate-declared-dependencies
enforce
{code}
was:
I have a multi module project and have accidentally defined dependency of one
artifact in multiple child maven module each having different version. Enforcer
plugin not able to detect this duplicate dependency and project gets build
successfully
Plugin definition in pom
{code:java}
// code placeholder
{code}
org.apache.maven.plugins
maven-enforcer-plugin 3.0.0
no-duplicate-declared-dependencies
enforce
> Enforcer plugin does not fail for duplicate dependency defined in multi
> module project
> --
>
> Key: MENFORCER-405
> URL: https://issues.apache.org/jira/browse/MENFORCER-405
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: Kaustav Das
>Priority: Major
>
> I have a multi module project and have accidentally defined dependency of one
> artifact in multiple child maven module each having different version.
> Enforcer plugin not able to detect this duplicate dependency and project gets
> build successfully
>
> Plugin definition in pom
> {code:java}
> org.apache.maven.plugins
> maven-enforcer-plugin 3.0.0
> no-duplicate-declared-dependencies
> enforce
>
>
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MENFORCER-405) Enforcer plugin does not fail for duplicate dependency defined in multi module project
[
https://issues.apache.org/jira/browse/MENFORCER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kaustav Das updated MENFORCER-405:
--
Description:
I have a multi module project and have accidentally defined dependency of one
artifact in multiple child maven module each having different version. Enforcer
plugin not able to detect this duplicate dependency and project gets build
successfully
Plugin definition in pom
{code:java}
// code placeholder
{code}
org.apache.maven.plugins
maven-enforcer-plugin 3.0.0
no-duplicate-declared-dependencies
enforce
was:
I have a multi module project and have accidentally defined dependency of one
artifact in multiple child maven module each having different version. Enforcer
plugin not able to detect this duplicate dependency and project gets build
successfully
Plugin definition in pom
```
org.apache.maven.plugins
maven-enforcer-plugin
3.0.0
no-duplicate-declared-dependencies
enforce
```
> Enforcer plugin does not fail for duplicate dependency defined in multi
> module project
> --
>
> Key: MENFORCER-405
> URL: https://issues.apache.org/jira/browse/MENFORCER-405
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 3.0.0
>Reporter: Kaustav Das
>Priority: Major
>
> I have a multi module project and have accidentally defined dependency of one
> artifact in multiple child maven module each having different version.
> Enforcer plugin not able to detect this duplicate dependency and project gets
> build successfully
>
> Plugin definition in pom
> {code:java}
> // code placeholder
> {code}
> org.apache.maven.plugins
> maven-enforcer-plugin 3.0.0
> no-duplicate-declared-dependencies
> enforce
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MENFORCER-405) Enforcer plugin does not fail for duplicate dependency defined in multi module project
[ https://issues.apache.org/jira/browse/MENFORCER-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kaustav Das updated MENFORCER-405: -- Description: I have a multi module project and have accidentally defined dependency of one artifact in multiple child maven module each having different version. Enforcer plugin not able to detect this duplicate dependency and project gets build successfully Plugin definition in pom ``` org.apache.maven.plugins maven-enforcer-plugin 3.0.0 no-duplicate-declared-dependencies enforce ``` was: I have a multi module project and have accidentally defined dependency of one artifact in multiple child maven module each having different version. Enforcer plugin not able to detect this duplicate dependency and project gets build successfully Plugin definition in pom org.apache.maven.plugins maven-enforcer-plugin 3.0.0 no-duplicate-declared-dependencies enforce > Enforcer plugin does not fail for duplicate dependency defined in multi > module project > -- > > Key: MENFORCER-405 > URL: https://issues.apache.org/jira/browse/MENFORCER-405 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 3.0.0 >Reporter: Kaustav Das >Priority: Major > > I have a multi module project and have accidentally defined dependency of one > artifact in multiple child maven module each having different version. > Enforcer plugin not able to detect this duplicate dependency and project gets > build successfully > > Plugin definition in pom > > ``` > org.apache.maven.plugins > maven-enforcer-plugin > 3.0.0 > > > no-duplicate-declared-dependencies > > enforce > > > > > > > > > ``` -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (MENFORCER-405) Enforcer plugin does not fail for duplicate dependency defined in multi module project
Kaustav Das created MENFORCER-405: - Summary: Enforcer plugin does not fail for duplicate dependency defined in multi module project Key: MENFORCER-405 URL: https://issues.apache.org/jira/browse/MENFORCER-405 Project: Maven Enforcer Plugin Issue Type: Bug Components: Plugin Affects Versions: 3.0.0 Reporter: Kaustav Das I have a multi module project and have accidentally defined dependency of one artifact in multiple child maven module each having different version. Enforcer plugin not able to detect this duplicate dependency and project gets build successfully Plugin definition in pom org.apache.maven.plugins maven-enforcer-plugin 3.0.0 no-duplicate-declared-dependencies enforce -- This message was sent by Atlassian Jira (v8.20.1#820001)
