[GitHub] [maven-apache-parent] kwin commented on pull request #35: MPOM-261 create buildinfo file for reproducible builds
kwin commented on pull request #35: URL: https://github.com/apache/maven-apache-parent/pull/35#issuecomment-783170906 @hboutemy Thanks for the answers. I understand that it is too early right now for buildinfo to be published (due to the format not finalized) to Maven Central. Are you also implying that the buildinfo is not necessary even in the long-term for Maven based projects as the relevant information can be derived from pom.xml and MANIFEST.MF or do you agree that the buildinfo in the long term should be published along with the artifacts? For me the primary goal is to verify that the build artifacts published/downloaded from Central are really based on a specific source. For that the buildinfo is crucial as otherwise you have to rely on heuristics (https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318#Reproducible/VerifiableBuilds-Rebuilding). 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-apache-parent] hboutemy commented on pull request #35: MPOM-261 create buildinfo file for reproducible builds
hboutemy commented on pull request #35: URL: https://github.com/apache/maven-apache-parent/pull/35#issuecomment-783165080 currently, I don't see any value in having buildinfo in Maven Central And given the format is not really stable, if people publish buildinfo, anybody wanting to consume it would have to hard-code tweaks bsaed on which flavour has been generated on 288 releases that you see on Reproducible Central, only a few have buildinfo on Central (that's SBT projects...): no Maven project at all has buildinfo 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-apache-parent] dependabot[bot] opened a new pull request #36: Bump maven-invoker-plugin from 3.2.1 to 3.2.2
dependabot[bot] opened a new pull request #36: URL: https://github.com/apache/maven-apache-parent/pull/36 Bumps [maven-invoker-plugin](https://github.com/apache/maven-invoker-plugin) from 3.2.1 to 3.2.2. Commits https://github.com/apache/maven-invoker-plugin/commit/efe8ee0bc66068da1e4bbb4f80d74c8c0ba6ca4b;>efe8ee0 [maven-release-plugin] prepare release maven-invoker-plugin-3.2.2 https://github.com/apache/maven-invoker-plugin/commit/32eef92a247a12ab1686f0566f04ac53ddeda77d;>32eef92 [MINVOKER-277] Require Maven 3.1.1 https://github.com/apache/maven-invoker-plugin/commit/7fc141894986923dcca022e955bd52a236cb7407;>7fc1418 Bump maven-artifact-transfer from 0.11.0 to 0.13.1 https://github.com/apache/maven-invoker-plugin/commit/f1ea2c657408918b4af3e26a0a30e392376635ff;>f1ea2c6 [MINVOKER-276] Update maven-invoker from 3.0.1 to 3.1.0 https://github.com/apache/maven-invoker-plugin/commit/d2f5cb6bb831eefc51450baa7b981e6139834af3;>d2f5cb6 Bump actions/cache from v2 to v2.1.4 https://github.com/apache/maven-invoker-plugin/commit/9afab19b423494a5b666727a89f015c3fb81b01d;>9afab19 Update maven-site-plugin to 3.9.1 and use Fluido Skin 1.9 https://github.com/apache/maven-invoker-plugin/commit/ebe5c5ae69af7b7b17649a66769aa9d7124cb153;>ebe5c5a [MINVOKER-254] Bump groovy-all from 2.4.20 to 2.4.21 https://github.com/apache/maven-invoker-plugin/commit/bfecb96f148d217d8765fcc6b7644c8fc57d4b24;>bfecb96 [MINVOKER-260] confirm streamLogs by IT tests https://github.com/apache/maven-invoker-plugin/commit/a46bf19905ec0560c3119537836b4391e43f44ee;>a46bf19 [MINVOKER-272] use Java 7 Files.createTempDirectory(...) API https://github.com/apache/maven-invoker-plugin/commit/c18d8e5a7a708abfcf9c11a5caef247e63b4ee38;>c18d8e5 Enable Dependabot v2 Additional commits viewable in https://github.com/apache/maven-invoker-plugin/compare/maven-invoker-plugin-3.2.1...maven-invoker-plugin-3.2.2;>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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNGSITE-410) on website, Maven Getting Started page, sample pom.xml has no description element, but subsequent explanation of the sample pom.xml thinks it does
[ https://issues.apache.org/jira/browse/MNGSITE-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MNGSITE-410. Resolution: Fixed > on website, Maven Getting Started page, sample pom.xml has no description > element, but subsequent explanation of the sample pom.xml thinks it does > -- > > Key: MNGSITE-410 > URL: https://issues.apache.org/jira/browse/MNGSITE-410 > Project: Maven Project Web Site > Issue Type: Bug > Environment: website >Reporter: Tim Stewart >Priority: Minor > > On web page [https://maven.apache.org/guides/getting-started/] the sample > pom.xml does not contain a element, but below the sample > pom.xml it says: "This is a very simple POM but still displays the key > elements every POM contains, so let's walk through each of them to > familiarize you with the POM essentials: ... • _description This element > provides a basic description of your project. This is often used in Maven's > generated documentation._" > So the explanation of the "description" element assumes the pom.xml contains > one, but it does not. > Recommended fix: include a "description" element in the sample pom.xml. Or, > alternatively, remove references to the description "element" from the > bulleted explanation of elements below the sample pom.xml -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MPOM-262) Update Java version to 8
[ https://issues.apache.org/jira/browse/MPOM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288095#comment-17288095 ] Michael Osipov edited comment on MPOM-262 at 2/21/21, 10:11 PM: Infact, Oracle provides updates for money. was (Author: michael-o): Infact, Oracle provides updates for updates. > Update Java version to 8 > > > Key: MPOM-262 > URL: https://issues.apache.org/jira/browse/MPOM-262 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf, maven >Reporter: Sylwester Lachiewicz >Priority: Major > > Oracle Java 7 is EOL: [https://www.java.com/en/download/help/java_7.html] > > Github Actions also removed it from default images: > [https://github.com/actions/virtual-environments/issues/2446] > > Many other ASF common/shared libs require newer Java 8. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-262) Update Java version to 8
[ https://issues.apache.org/jira/browse/MPOM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288095#comment-17288095 ] Michael Osipov commented on MPOM-262: - Infact, Oracle provides updates for updates. > Update Java version to 8 > > > Key: MPOM-262 > URL: https://issues.apache.org/jira/browse/MPOM-262 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf, maven >Reporter: Sylwester Lachiewicz >Priority: Major > > Oracle Java 7 is EOL: [https://www.java.com/en/download/help/java_7.html] > > Github Actions also removed it from default images: > [https://github.com/actions/virtual-environments/issues/2446] > > Many other ASF common/shared libs require newer Java 8. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-262) Update Java version to 8
[ https://issues.apache.org/jira/browse/MPOM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288094#comment-17288094 ] Sylwester Lachiewicz commented on MPOM-262: --- Thx corrected. > Update Java version to 8 > > > Key: MPOM-262 > URL: https://issues.apache.org/jira/browse/MPOM-262 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf, maven >Reporter: Sylwester Lachiewicz >Priority: Major > > Oracle Java 7 is EOL: [https://www.java.com/en/download/help/java_7.html] > > Github Actions also removed it from default images: > [https://github.com/actions/virtual-environments/issues/2446] > > Many other ASF common/shared libs require newer Java 8. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MPOM-262) Update Java version to 8
[ https://issues.apache.org/jira/browse/MPOM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MPOM-262: -- Description: Oracle Java 7 is EOL: [https://www.java.com/en/download/help/java_7.html] Github Actions also removed it from default images: [https://github.com/actions/virtual-environments/issues/2446] Many other ASF common/shared libs require newer Java 8. was: Java 7 is EOL from 2015: [https://www.java.com/en/download/help/java_7.html] Github Actions also removed it from default images: [https://github.com/actions/virtual-environments/issues/2446] Many other ASF common/shared libs requires newer Java 8. > Update Java version to 8 > > > Key: MPOM-262 > URL: https://issues.apache.org/jira/browse/MPOM-262 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf, maven >Reporter: Sylwester Lachiewicz >Priority: Major > > Oracle Java 7 is EOL: [https://www.java.com/en/download/help/java_7.html] > > Github Actions also removed it from default images: > [https://github.com/actions/virtual-environments/issues/2446] > > Many other ASF common/shared libs require newer Java 8. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MENFORCER-379) Update maven-common-artifact-filters to 3.2.0
[ https://issues.apache.org/jira/browse/MENFORCER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MENFORCER-379. -- Resolution: Fixed > Update maven-common-artifact-filters to 3.2.0 > - > > Key: MENFORCER-379 > URL: https://issues.apache.org/jira/browse/MENFORCER-379 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-262) Update Java version to 8
[ https://issues.apache.org/jira/browse/MPOM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288093#comment-17288093 ] Michael Osipov commented on MPOM-262: - That's wrong. Oracle Java is EOL, not Java or OpenJDK. Many vendors still support it. > Update Java version to 8 > > > Key: MPOM-262 > URL: https://issues.apache.org/jira/browse/MPOM-262 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf, maven >Reporter: Sylwester Lachiewicz >Priority: Major > > Java 7 is EOL from 2015: [https://www.java.com/en/download/help/java_7.html] > > Github Actions also removed it from default images: > [https://github.com/actions/virtual-environments/issues/2446] > > Many other ASF common/shared libs requires newer Java 8. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MTOOLCHAINS-36) No javac should be an error
[ https://issues.apache.org/jira/browse/MTOOLCHAINS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MTOOLCHAINS-36. --- Resolution: Duplicate > No javac should be an error > --- > > Key: MTOOLCHAINS-36 > URL: https://issues.apache.org/jira/browse/MTOOLCHAINS-36 > Project: Maven Toolchains Plugin > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Delany >Priority: Major > > If the selected toolchain is configured to point to a JRE instead of a JDK, > it should fail with an error. Instead there is a warning. > [WARNING] Unable to autodetect 'javac' path, using 'javac' from the > environment. > I'm assuming it falls back to whatever javac is available on the system? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MENFORCER-379) Update maven-common-artifact-filters to 3.2.0
[ https://issues.apache.org/jira/browse/MENFORCER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288084#comment-17288084 ] Hudson commented on MENFORCER-379: -- Build failed in Jenkins: Maven » Maven TLP » maven-enforcer » master #38 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-enforcer/job/master/38/ > Update maven-common-artifact-filters to 3.2.0 > - > > Key: MENFORCER-379 > URL: https://issues.apache.org/jira/browse/MENFORCER-379 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MENFORCER-267) Upgrade to make Maven 3.1+
[ https://issues.apache.org/jira/browse/MENFORCER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MENFORCER-267: -- Assignee: (was: Sylwester Lachiewicz) > Upgrade to make Maven 3.1+ > -- > > Key: MENFORCER-267 > URL: https://issues.apache.org/jira/browse/MENFORCER-267 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.0.0-M3 >Reporter: Karl Heinz Marbaise >Priority: Major > Fix For: 3.0.0, 3.0.0-M4 > > > * maven-dependency-tree needs to be updated to 3.0.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MENFORCER-372) Switch to JUnit5
[ https://issues.apache.org/jira/browse/MENFORCER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MENFORCER-372: --- Labels: Java8 (was: ) > Switch to JUnit5 > > > Key: MENFORCER-372 > URL: https://issues.apache.org/jira/browse/MENFORCER-372 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Priority: Minor > Labels: Java8 > Fix For: 3.0.1 > > > Since even Maven switched to JUnit5 [1], it'd be great to move forward and > use JUnit5 in Enforcer too. The only problem is that it requires Java 8. [2] > Even if it won't happen with 3.x version, it's ok to put this task to backlog. > > [1] > [https://github.com/apache/maven/commit/bb916d0784c7631866167928e4d0615df3317567] > > [2] [https://junit.org/junit5/docs/current/user-guide/#overview-java-versions] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MENFORCER-371) Require Maven 3.1.1
[ https://issues.apache.org/jira/browse/MENFORCER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz closed MENFORCER-371. -- Resolution: Fixed > Require Maven 3.1.1 > --- > > Key: MENFORCER-371 > URL: https://issues.apache.org/jira/browse/MENFORCER-371 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0, 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MENFORCER-371) Require Maven 3.1.1
[ https://issues.apache.org/jira/browse/MENFORCER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz reassigned MENFORCER-371: -- Assignee: Sylwester Lachiewicz > Require Maven 3.1.1 > --- > > Key: MENFORCER-371 > URL: https://issues.apache.org/jira/browse/MENFORCER-371 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0, 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MENFORCER-371) Require Maven 3.1.1
[ https://issues.apache.org/jira/browse/MENFORCER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MENFORCER-371: --- Fix Version/s: 3.0.0 > Require Maven 3.1.1 > --- > > Key: MENFORCER-371 > URL: https://issues.apache.org/jira/browse/MENFORCER-371 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Priority: Minor > Fix For: 3.0.0, 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288077#comment-17288077 ] Tamás Cservenák commented on MNG-7097: -- So IT recap so far: * MNG5783 IT: fails for a reason (is good), as Maven with PR will NOT download nor provide slf4j while resolving plugin dependencies. We need to do something about this * MNG7045 IT: fails on GH and when locally run in IT suite, but the POM _works_ when invoked with locally built Maven with PR, so something is fishy here (or am doing something wrong). > Plugin Dependency Resolution: don't download Maven-provided artifacts > - > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] famod commented on a change in pull request #446: [MNG-6511] - Optional project selection
famod commented on a change in pull request #446:
URL: https://github.com/apache/maven/pull/446#discussion_r579859091
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -176,38 +177,69 @@ public DefaultGraphBuilder( BuildResumptionDataRepository
buildResumptionDataRep
{
List result = projects;
-if ( !request.getSelectedProjects().isEmpty() )
+ProjectActivation projectActivation = request.getProjectActivation();
+Set requiredSelectors =
projectActivation.getRequiredActiveProjectSelectors();
+Set optionalSelectors =
projectActivation.getOptionalActiveProjectSelectors();
+if ( !requiredSelectors.isEmpty() || !optionalSelectors.isEmpty() )
{
-File reactorDirectory = getReactorDirectory( request );
+Set selectedProjects = new HashSet<>(
requiredSelectors.size() + optionalSelectors.size() );
+selectedProjects.addAll( getProjectsBySelectors( request,
projects, requiredSelectors, true ) );
+selectedProjects.addAll( getProjectsBySelectors( request,
projects, optionalSelectors, false ) );
+
+// it can be empty when an optional project is missing from the
reactor, fallback to returning all projects
+if ( !selectedProjects.isEmpty() )
+{
+result = new ArrayList<>( selectedProjects );
+
+result = includeAlsoMakeTransitively( result, request, graph );
+
+// Order the new list in the original order
+List sortedProjects = graph.getSortedProjects();
+result.sort( comparing( sortedProjects::indexOf ) );
+}
+}
+
+return result;
+}
-Collection selectedProjects = new LinkedHashSet<>();
+private Set getProjectsBySelectors( MavenExecutionRequest
request, List projects,
+ Set
projectSelectors, boolean required )
+throws MavenExecutionException
+{
+Set selectedProjects = new LinkedHashSet<>();
+File reactorDirectory = getReactorDirectory( request );
-for ( String selector : request.getSelectedProjects() )
+for ( String selector : projectSelectors )
+{
+Optional optSelectedProject = projects.stream()
+.filter( project -> isMatchingProject( project, selector,
reactorDirectory ) )
+.findFirst();
+if ( !optSelectedProject.isPresent() )
{
-MavenProject selectedProject = projects.stream()
-.filter( project -> isMatchingProject( project,
selector, reactorDirectory ) )
-.findFirst()
-.orElseThrow( () -> new MavenExecutionException(
-"Could not find the selected project in the
reactor: " + selector, request.getPom() ) );
-selectedProjects.add( selectedProject );
-
-List children =
selectedProject.getCollectedProjects();
-if ( children != null )
+String message = "Could not find the selected project in the
reactor: " + selector;
+if ( required )
+{
+throw new MavenExecutionException( message,
request.getPom() );
+}
+else
{
-selectedProjects.addAll( children );
+LOGGER.warn( message );
Review comment:
TBH, I didn't follow the discussion of optional profiles, but shouldn't
this be `info` instead?
I mean I as a user have already made very clear at this point (via "?") that
the project is optional. So why warn me if it isn't there? For me this is
purely informative.
IMO, the same applies to optional profiles.
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] famod commented on pull request #446: [MNG-6511] - Optional project selection
famod commented on pull request #446: URL: https://github.com/apache/maven/pull/446#issuecomment-782919336 I might be blind, but shouldn't this be documented in `-help`? As of 3.6.3, "!" isn't documented either and should be added as well. 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] [Updated] (MENFORCER-379) Update maven-common-artifact-filters to 3.2.0
[ https://issues.apache.org/jira/browse/MENFORCER-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sylwester Lachiewicz updated MENFORCER-379: --- Summary: Update maven-common-artifact-filters to 3.2.0 (was: Update maven-common-artifact-filters to 3.1.1/3.1.2) > Update maven-common-artifact-filters to 3.2.0 > - > > Key: MENFORCER-379 > URL: https://issues.apache.org/jira/browse/MENFORCER-379 > Project: Maven Enforcer Plugin > Issue Type: Dependency upgrade > Components: Plugin >Affects Versions: 3.0.0-M3 >Reporter: Krosheninnikov Artem >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.0.0-M4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288076#comment-17288076
]
Falko Modler commented on MNG-6511:
---
[~martinkanters] Oh great, didn't realize that there is already a PR! Thanks!
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] famod commented on a change in pull request #446: [MNG-6511] - Optional project selection
famod commented on a change in pull request #446:
URL: https://github.com/apache/maven/pull/446#discussion_r579859091
##
File path:
maven-core/src/main/java/org/apache/maven/graph/DefaultGraphBuilder.java
##
@@ -176,38 +177,69 @@ public DefaultGraphBuilder( BuildResumptionDataRepository
buildResumptionDataRep
{
List result = projects;
-if ( !request.getSelectedProjects().isEmpty() )
+ProjectActivation projectActivation = request.getProjectActivation();
+Set requiredSelectors =
projectActivation.getRequiredActiveProjectSelectors();
+Set optionalSelectors =
projectActivation.getOptionalActiveProjectSelectors();
+if ( !requiredSelectors.isEmpty() || !optionalSelectors.isEmpty() )
{
-File reactorDirectory = getReactorDirectory( request );
+Set selectedProjects = new HashSet<>(
requiredSelectors.size() + optionalSelectors.size() );
+selectedProjects.addAll( getProjectsBySelectors( request,
projects, requiredSelectors, true ) );
+selectedProjects.addAll( getProjectsBySelectors( request,
projects, optionalSelectors, false ) );
+
+// it can be empty when an optional project is missing from the
reactor, fallback to returning all projects
+if ( !selectedProjects.isEmpty() )
+{
+result = new ArrayList<>( selectedProjects );
+
+result = includeAlsoMakeTransitively( result, request, graph );
+
+// Order the new list in the original order
+List sortedProjects = graph.getSortedProjects();
+result.sort( comparing( sortedProjects::indexOf ) );
+}
+}
+
+return result;
+}
-Collection selectedProjects = new LinkedHashSet<>();
+private Set getProjectsBySelectors( MavenExecutionRequest
request, List projects,
+ Set
projectSelectors, boolean required )
+throws MavenExecutionException
+{
+Set selectedProjects = new LinkedHashSet<>();
+File reactorDirectory = getReactorDirectory( request );
-for ( String selector : request.getSelectedProjects() )
+for ( String selector : projectSelectors )
+{
+Optional optSelectedProject = projects.stream()
+.filter( project -> isMatchingProject( project, selector,
reactorDirectory ) )
+.findFirst();
+if ( !optSelectedProject.isPresent() )
{
-MavenProject selectedProject = projects.stream()
-.filter( project -> isMatchingProject( project,
selector, reactorDirectory ) )
-.findFirst()
-.orElseThrow( () -> new MavenExecutionException(
-"Could not find the selected project in the
reactor: " + selector, request.getPom() ) );
-selectedProjects.add( selectedProject );
-
-List children =
selectedProject.getCollectedProjects();
-if ( children != null )
+String message = "Could not find the selected project in the
reactor: " + selector;
+if ( required )
+{
+throw new MavenExecutionException( message,
request.getPom() );
+}
+else
{
-selectedProjects.addAll( children );
+LOGGER.warn( message );
Review comment:
TBH, I didn't follow the discussion of optional profiles, but shouldn't
this be `info` instead?
I mean I as a user have already made very clear at this point (via "?") that
the project is optional. So why warn me if it isn't there? For me this is
purely informative.
IMO, same for optional profiles.
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-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts
[
https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288075#comment-17288075
]
Tamás Cservenák commented on MNG-7097:
--
So there's more to it: I found nice explanation WHY all this sub-optimal
(download more than really needed) things happen in MNG-5783. It seems there
are plugins using {{$\{plugin.artifacts\}}} to set up their classpath
circumventing Maven...
> Plugin Dependency Resolution: don't download Maven-provided artifacts
> -
>
> Key: MNG-7097
> URL: https://issues.apache.org/jira/browse/MNG-7097
> Project: Maven
> Issue Type: Task
> Components: Performance, Plugins and Lifecycle
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
>
> Current Maven behavior for resolving plugin dependencies is to download full
> transitive graph of plugin dependency, but for executing plugin it filters
> out core artifacts from graph (excludes them).
> This results in unnecessary downloads of core artifacts, multiplied by
> multiple versions used by different plugins, and local repository end up
> having artifacts that may even surprise users.
> Most notable examples: maven-core (user: "Why did Maven download maven-core-X
> when I use maven-Y?"), plexus-container-default (user: "Why does Maven
> download 10+ versions of this legacy artifact (adv user: when
> sisu-inject-plexus shim is used instead)?"), multiple versions of
> plexus-utils etc...
> We need to investigate what exactly happens with downloaded, but unused core
> artifacts (if they are completely excluded based on GAV, we are safest), and
> simply exclude them even from resolution/collection, as they are really not
> needed.
> This will not "improve build speed", but does lessen "bandwidth", as
> experiments shows that cutting plugin dependencies for core artifacts for
> Maven project itself makes about 1k less remote requests (artifact and
> artifact checksum downloads).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-557) In dependency analysis, support Spring Boot style intentional transitive compile-time dependencies
[
https://issues.apache.org/jira/browse/MDEP-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288074#comment-17288074
]
M. Justin commented on MDEP-557:
A non-Spring example of this sort of dependency is the {{junit-jupiter}}
dependency (per
[junit5#1629|https://github.com/junit-team/junit5/issues/1629]), which combines
{{junit-jupiter-api}}, {{junit-jupiter-params}} and {{junit-jupiter-engine}},
as they are often used together.
> In dependency analysis, support Spring Boot style intentional transitive
> compile-time dependencies
> --
>
> Key: MDEP-557
> URL: https://issues.apache.org/jira/browse/MDEP-557
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Reporter: M. Justin
>Priority: Minor
> Labels: S2
>
> h1. Request
> It would be useful if using Spring Boot "starter" dependencies as intended
> didn't cause warnings with dependency:analyze (and related goals).
> h1. Background
> Spring Boot has a notion of "starter" dependencies. One of the primary
> purposes of starter dependencies is to transitively bring in numerous other
> dependencies to be used at both runtime and compile time. Per [Spring Boot's
> documentation|http://docs.spring.io/spring-boot/docs/1.5.1.RELEASE/reference/htmlsingle/#using-boot-starter]:
> {quote}
> Starters are a set of convenient dependency descriptors that you can include
> in your application. You get a one-stop-shop for all the Spring and related
> technology that you need, without having to hunt through sample code and copy
> paste loads of dependency descriptors. For example, if you want to get
> started using Spring and JPA for database access, just include the
> spring-boot-starter-data-jpa dependency in your project, and you are good to
> go.
> The starters contain a lot of the dependencies that you need to get a project
> up and running quickly and with a consistent, supported set of managed
> transitive dependencies.
> {quote}
> However, this is at odds with the analysis done by
> [dependency:analyze|https://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html]
> (and similar goals in the dependency plugin). The analyze goals will warn
> that the starter projects are "unused declared dependencies" and any
> compile-time dependencies that are transitively brought in this way will
> produce "used undeclared dependencies" warnings. Note that this warning
> behavior is consistent with the [Maven dependency
> documentation|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope]
> where it states that it is intended that all compile dependencies be
> explicitly listed, rather than transitively used at compile time:
> {quote}it is intended that \[transitive compile dependencies\] should be
> runtime scope instead, so that all compile dependencies must be explicitly
> listed - however, there is the case where the library you depend on extends a
> class from another library, forcing you to have available at compile time.
> For this reason, compile time dependencies remain as compile scope even when
> they are transitive.{quote}
> As a concrete example, here are the warnings generated by {{mvn
> dependency:analyze}} on Spring Boot's own "[Getting
> Started|https://spring.io/guides/gs/spring-boot/]; example:
> {code}Used undeclared dependencies found:
>org.springframework:spring-web:jar:4.3.6.RELEASE:compile
>org.springframework.boot:spring-boot-test:jar:1.5.1.RELEASE:test
>
> org.springframework.boot:spring-boot-test-autoconfigure:jar:1.5.1.RELEASE:test
>org.springframework:spring-test:jar:4.3.6.RELEASE:test
>org.springframework.boot:spring-boot:jar:1.5.1.RELEASE:compile
>org.hamcrest:hamcrest-library:jar:1.3:test
>org.springframework:spring-context:jar:4.3.6.RELEASE:compile
>junit:junit:jar:4.12:test
>
> org.springframework.boot:spring-boot-autoconfigure:jar:1.5.1.RELEASE:compile
>org.springframework:spring-beans:jar:4.3.6.RELEASE:compile
> Unused declared dependencies found:
>org.springframework.boot:spring-boot-starter-web:jar:1.5.1.RELEASE:compile
>org.springframework.boot:spring-boot-starter-test:jar:1.5.1.RELEASE:test
>
> org.springframework.boot:spring-boot-starter-actuator:jar:1.5.1.RELEASE:compile{code}
> My initial thought was that perhaps Spring Boot was misuing the Maven
> dependency mechanism through their approach, however that is not their
> interpretation (see the discussion at
> [spring-boot#8341|https://github.com/spring-projects/spring-boot/issues/8341]).
> So, assuming I'm interpreting things correctly, it seems like the thought is
> that Spring Boot's usage of dependencies is A-OK. Given this, and the impact
[jira] [Created] (MPOM-262) Update Java version to 8
Sylwester Lachiewicz created MPOM-262: - Summary: Update Java version to 8 Key: MPOM-262 URL: https://issues.apache.org/jira/browse/MPOM-262 Project: Maven POMs Issue Type: Dependency upgrade Components: asf, maven Reporter: Sylwester Lachiewicz Java 7 is EOL from 2015: [https://www.java.com/en/download/help/java_7.html] Github Actions also removed it from default images: [https://github.com/actions/virtual-environments/issues/2446] Many other ASF common/shared libs requires newer Java 8. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6511) Option -pl ! foo should not fail if foo does not exist
[
https://issues.apache.org/jira/browse/MNG-6511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288073#comment-17288073
]
Martin Kanters commented on MNG-6511:
-
[~famod]
[~mthmulders] and I are working on this. PRs are created already, but there is
still some work to be done by us. I expect that to be resolved somewhere end of
this week, early next week
core: https://github.com/apache/maven/pull/446
ITs: https://github.com/apache/maven-integration-testing/pull/100
If the optional project does not exist, it will log a warning (consistent with
profiles).
> Option -pl ! foo should not fail if foo does not exist
> --
>
> Key: MNG-6511
> URL: https://issues.apache.org/jira/browse/MNG-6511
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.3.9, 3.6.0
>Reporter: Falko Modler
>Priority: Major
>
> While I completely understand why Maven throws an error when
> {{\-pl/--projects}} defines/contains a non-existing project, I don't really
> see why the negation of a non-existing project yields the same error, e.g.:
> {noformat}
> c:\_dev\git\gitflow-incremental-builder>mvn -pl !foo
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: foo @
> [ERROR] Could not find the selected project in the reactor: foo -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {noformat}
> I'd say that at most this should be a warning, not an error.
> This change would come in handy to reuse scripts with certain default options
> (e.g. quickly build everything without tests, checkstyle, _exclude moduleX_,
> etc.) on different hierarchy levels of larger multi module project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] cstamas edited a comment on pull request #450: [MNG-7097] Plugin Dependency Resolution Improvement
cstamas edited a comment on pull request #450: URL: https://github.com/apache/maven/pull/450#issuecomment-782915543 Something is strange: for example this one fails (on GH but also locally as well): ``` mng7045 DropUselessAndOutdatedCdiApi.it() FAILURE (0.3 s) ``` **but**, when I run the POM in IT from CLI with this PR built mvn it is OK (is simple, uses GMavenPlus plugin and a script) 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] cstamas commented on pull request #450: [MNG-7097] Plugin Dependency Resolution Improvement
cstamas commented on pull request #450: URL: https://github.com/apache/maven/pull/450#issuecomment-782915543 Something is strange: for example this one fails (on GH but also locally as well): ``` mng7045 DropUselessAndOutdatedCdiApi.it() FAILURE (0.3 s) ``` **but**, when I run the POM in IT from CLI (is simple, uses GMavenPlus plugin and a script), it passes ok... 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] (MSITE-870) mark Maven-exported dependencies as scope provided
[ https://issues.apache.org/jira/browse/MSITE-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288062#comment-17288062 ] Hudson commented on MSITE-870: -- Build succeeded in Jenkins: Maven » Maven TLP » maven-site-plugin » master #23 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-site-plugin/job/master/23/ > mark Maven-exported dependencies as scope provided > -- > > Key: MSITE-870 > URL: https://issues.apache.org/jira/browse/MSITE-870 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 3.9.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.10.0 > > > see MPLUGIN-370 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MSITE-870) mark Maven-exported dependencies as scope provided
[ https://issues.apache.org/jira/browse/MSITE-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSITE-870. --- Resolution: Fixed done in https://github.com/apache/maven-site-plugin/commit/db969cf3ab7781d17c40694f741928c18661ad59 > mark Maven-exported dependencies as scope provided > -- > > Key: MSITE-870 > URL: https://issues.apache.org/jira/browse/MSITE-870 > Project: Maven Site Plugin > Issue Type: Improvement >Affects Versions: 3.9.1 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.10.0 > > > see MPLUGIN-370 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSITE-870) mark Maven-exported dependencies as scope provided
Herve Boutemy created MSITE-870: --- Summary: mark Maven-exported dependencies as scope provided Key: MSITE-870 URL: https://issues.apache.org/jira/browse/MSITE-870 Project: Maven Site Plugin Issue Type: Improvement Affects Versions: 3.9.1 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 3.10.0 see MPLUGIN-370 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288049#comment-17288049 ] Herve Boutemy commented on MNG-7097: MPLUGIN-370 created to improve Maven Plugin Plugin to ease detect when such provided scope can/should be defined (remain useful for older Maven versions) > Plugin Dependency Resolution: don't download Maven-provided artifacts > - > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MPLUGIN-370) check that plugin dependencies that are already exported by Maven are scope provided
Herve Boutemy created MPLUGIN-370: - Summary: check that plugin dependencies that are already exported by Maven are scope provided Key: MPLUGIN-370 URL: https://issues.apache.org/jira/browse/MPLUGIN-370 Project: Maven Plugin Tools Issue Type: New Feature Affects Versions: 3.6.0 Reporter: Herve Boutemy see MNG-7097: Maven 4 will optimize downloads even when these dependencies are not with provided scope but for older Maven versions, marking the dependencies provided remains useful: if maven-plugin-plugin helps do the configuration, it will be easier -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287927#comment-17287927 ] Herve Boutemy edited comment on MNG-7097 at 2/21/21, 6:20 PM: -- another topic: we should also document that plugins themselves should declare such Maven-provided dependencies as scope provided this will avoid the download for earlier Maven versions and we should update every Maven plugin we maintain, and also archetypes (done in MARCHETYPES-51)... was (Author: hboutemy): another topic: we should also document that plugins themselves should declare such Maven-provided dependencies as scope provided this will avoid the download for earlier Maven versions and we should update every Maven plugin we maintain, and also archetypes... > Plugin Dependency Resolution: don't download Maven-provided artifacts > - > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288045#comment-17288045 ] Hudson commented on MNG-7097: - Build succeeded in Jenkins: Maven » Maven TLP » maven-site » master #131 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven-site/job/master/131/ > Plugin Dependency Resolution: don't download Maven-provided artifacts > - > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPOM-261) Create buildinfo file by default
[ https://issues.apache.org/jira/browse/MPOM-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288030#comment-17288030 ] Herve Boutemy commented on MPOM-261: question: what do you expect from generating buildinfo on each build? as written in PR comments, we don't need to record buildinfo: see https://github.com/jvm-repo-rebuild/reproducible-central that was done without saving buildinfo at initial build time And also instructions in https://maven.apache.org/guides/mini/guide-reproducible-builds.html don't create buildinfo on first run artifact:buildinfo is there to check reproducible build on rebuilds > Create buildinfo file by default > > > Key: MPOM-261 > URL: https://issues.apache.org/jira/browse/MPOM-261 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Priority: Major > > The https://github.com/apache/maven-artifact-plugin should be enabled by > default so that buildinfo files are being generated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-apache-parent] kwin commented on pull request #35: MPOM-261 create buildinfo file for reproducible builds
kwin commented on pull request #35: URL: https://github.com/apache/maven-apache-parent/pull/35#issuecomment-782898519 @hboutemy Don't you think that buildinfo files should be available by default from Maven Central? Which parts of Maven Central currently has buildinfo being generated? I only see 288 releases 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-apache-parent] hboutemy commented on pull request #35: MPOM-261 create buildinfo file for reproducible builds
hboutemy commented on pull request #35: URL: https://github.com/apache/maven-apache-parent/pull/35#issuecomment-782897908 we don't need to record buildinfo: see https://github.com/jvm-repo-rebuild/reproducible-central that was done without saving buildinfo at initial build time artifact:buildinfo is there to check reproducible build on rebuilds 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-apache-parent] kwin commented on pull request #29: [MPOM-247] make minimum POM version configurable via property
kwin commented on pull request #29: URL: https://github.com/apache/maven-apache-parent/pull/29#issuecomment-782897677 @rfscholte Are you fine with this PR? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-apache-parent] kwin opened a new pull request #35: MPOM-261 create buildinfo file for reproducible builds
kwin opened a new pull request #35: URL: https://github.com/apache/maven-apache-parent/pull/35 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] [Created] (MPOM-261) Create buildinfo file by default
Konrad Windszus created MPOM-261: Summary: Create buildinfo file by default Key: MPOM-261 URL: https://issues.apache.org/jira/browse/MPOM-261 Project: Maven POMs Issue Type: Improvement Components: asf Affects Versions: ASF-23 Reporter: Konrad Windszus The https://github.com/apache/maven-artifact-plugin should be enabled by default so that buildinfo files are being generated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7103) Make generic VersionScheme a component
[
https://issues.apache.org/jira/browse/MNG-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288019#comment-17288019
]
Tamás Cservenák commented on MNG-7103:
--
https://github.com/apache/maven/pull/449
> Make generic VersionScheme a component
> --
>
> Key: MNG-7103
> URL: https://issues.apache.org/jira/browse/MNG-7103
> Project: Maven
> Issue Type: Task
> Components: core
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
>
> Maven Resolver, while provides {{VersionScheme}} implementation (the
> {{GenericVersionScheme}} does not binds it (makes it a component) nor creates
> instance from it (it works against interfaces, actual implementation is left
> to "integration" like Maven is).
> As Maven is the main "user" of GenericVersionScheme, it makes sense to bind
> it in Maven Realm.
> Right now, instances of it are created "ad-hoc" (wherever needed) instead of
> being injected (and shared as singleton), as implementation is
> stateless/thread-safe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOLVER-164) DefaultDependencyCollector filterVersions seems always return full version range
[
https://issues.apache.org/jira/browse/MRESOLVER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287935#comment-17287935
]
Tamás Cservenák commented on MRESOLVER-164:
---
I'd agree here: {{DefaultModelResolver}} picks highest version as well, so it
really looks like some oversight (or suboptimal behaviour that was not "worth"
to address before?).
I'd suggest to move this issue to MNG, as Maven Resolver *has all the needed
bits* to make this possible, it is "just "the fact that user (Maven) of
resolver *does not make use of those bits*.
> DefaultDependencyCollector filterVersions seems always return full version
> range
>
>
> Key: MRESOLVER-164
> URL: https://issues.apache.org/jira/browse/MRESOLVER-164
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.4.2, 1.6.1
>Reporter: Xiang Li
>Priority: Major
>
> Related to MNG-7049 but I think the root cause is in maven-resolver so I
> opened a new issue. Correct me if it is better to still use the old ticket.
> During using version ranges, I notice that maven will download all poms from
> a version range, which happen in that
> [loop|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L404],
> the reason is that
> [verFilter|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155]
> here seems return null. Since by default, versionFilter is set to null by
> DefaultRepositorySystemSession, and I do not see many examples that
> setVersionFilter get used for some reason.
> Another thing that confuses me is that version range is resolved by
> DefaultVersionRangeResolver in maven rather than maven-resolver here.
>
> I wonder if it possible to set HighestVersionFilter
> [here|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155]
> instead of return all version range results. I am happy to contribute a PR
> with some guidance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MRESOLVER-164) DefaultDependencyCollector filterVersions seems always return full version range
[
https://issues.apache.org/jira/browse/MRESOLVER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287935#comment-17287935
]
Tamás Cservenák edited comment on MRESOLVER-164 at 2/21/21, 12:35 PM:
--
I'd agree here: {{DefaultModelResolver}} picks highest version as well, so it
really looks like some oversight (or suboptimal behaviour that was not "worth"
to address before?).
I'd suggest to move this issue to MNG, as Maven Resolver *has all the needed
bits* to make this possible, it is "just "the fact that user (Maven) of
resolver *does not make use of those bits*. [~michael-o] if you agree, pls move
this issue to MNG...
was (Author: cstamas):
I'd agree here: {{DefaultModelResolver}} picks highest version as well, so it
really looks like some oversight (or suboptimal behaviour that was not "worth"
to address before?).
I'd suggest to move this issue to MNG, as Maven Resolver *has all the needed
bits* to make this possible, it is "just "the fact that user (Maven) of
resolver *does not make use of those bits*.
> DefaultDependencyCollector filterVersions seems always return full version
> range
>
>
> Key: MRESOLVER-164
> URL: https://issues.apache.org/jira/browse/MRESOLVER-164
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.4.2, 1.6.1
>Reporter: Xiang Li
>Priority: Major
>
> Related to MNG-7049 but I think the root cause is in maven-resolver so I
> opened a new issue. Correct me if it is better to still use the old ticket.
> During using version ranges, I notice that maven will download all poms from
> a version range, which happen in that
> [loop|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L404],
> the reason is that
> [verFilter|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155]
> here seems return null. Since by default, versionFilter is set to null by
> DefaultRepositorySystemSession, and I do not see many examples that
> setVersionFilter get used for some reason.
> Another thing that confuses me is that version range is resolved by
> DefaultVersionRangeResolver in maven rather than maven-resolver here.
>
> I wonder if it possible to set HighestVersionFilter
> [here|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155]
> instead of return all version range results. I am happy to contribute a PR
> with some guidance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] cstamas commented on a change in pull request #450: [MNG-7097] Plugin Dependency Resolution Improvement
cstamas commented on a change in pull request #450: URL: https://github.com/apache/maven/pull/450#discussion_r579799693 ## File path: maven-core/src/main/java/org/apache/maven/extension/internal/CoreExportsProvider.java ## @@ -27,7 +27,8 @@ import org.eclipse.sisu.Nullable; /** - * CoreExportsProvider + * CoreExportsProvider, that CANNOT be javax.inject.Provider as ctor would have circular dep. Review comment: Fixed, tx 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] pzygielo commented on a change in pull request #450: [MNG-7097] Plugin Dependency Resolution Improvement
pzygielo commented on a change in pull request #450: URL: https://github.com/apache/maven/pull/450#discussion_r579799094 ## File path: maven-core/src/main/java/org/apache/maven/extension/internal/CoreExportsProvider.java ## @@ -27,7 +27,8 @@ import org.eclipse.sisu.Nullable; /** - * CoreExportsProvider + * CoreExportsProvider, that CANNOT be javax.inject.Provider as ctor would have circular dep. Review comment: `javadoc: error: unknown tag: tty` 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-7104) Make Maven components proper components
[ https://issues.apache.org/jira/browse/MNG-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MNG-7104: Assignee: Tamás Cservenák > Make Maven components proper components > --- > > Key: MNG-7104 > URL: https://issues.apache.org/jira/browse/MNG-7104 > Project: Maven > Issue Type: Task >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > For historical reasons (Plexus never supported ctor injection, just member > injection), many if not all classes of Maven codebase even today (with SISU > as DI provider) uses field injection. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (MNG-7103) Make generic VersionScheme a component
[
https://issues.apache.org/jira/browse/MNG-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák reassigned MNG-7103:
Assignee: Tamás Cservenák
> Make generic VersionScheme a component
> --
>
> Key: MNG-7103
> URL: https://issues.apache.org/jira/browse/MNG-7103
> Project: Maven
> Issue Type: Task
> Components: core
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
>
> Maven Resolver, while provides {{VersionScheme}} implementation (the
> {{GenericVersionScheme}} does not binds it (makes it a component) nor creates
> instance from it (it works against interfaces, actual implementation is left
> to "integration" like Maven is).
> As Maven is the main "user" of GenericVersionScheme, it makes sense to bind
> it in Maven Realm.
> Right now, instances of it are created "ad-hoc" (wherever needed) instead of
> being injected (and shared as singleton), as implementation is
> stateless/thread-safe.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287930#comment-17287930 ] Tamás Cservenák commented on MNG-7097: -- While the UTs of maven pass ok, this obviously fails IT, so it needs eyeballing why, and possibly adjusting ITs (if they for example enumerate things in local repo that after this change are not present anymore). > Plugin Dependency Resolution: don't download Maven-provided artifacts > - > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287927#comment-17287927 ] Herve Boutemy edited comment on MNG-7097 at 2/21/21, 12:05 PM: --- another topic: we should also document that plugins themselves should declare such Maven-provided dependencies as scope provided this will avoid the download for earlier Maven versions and we should update every Maven plugin we maintain, and also archetypes... was (Author: hboutemy): another topic: we should also document that plugins themselves should declare such Maven-provided dependencies as scope provided this will avoid the download for earlier Maven versions and we should update every Maven plugin we maintain... > Plugin Dependency Resolution: don't download Maven-provided artifacts > - > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287927#comment-17287927 ] Herve Boutemy commented on MNG-7097: another topic: we should also document that plugins themselves should declare such Maven-provided dependencies as scope provided this will avoid the download for earlier Maven versions and we should update every Maven plugin we maintain... > Plugin Dependency Resolution: don't download Maven-provided artifacts > - > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7097) Plugin Dependency Resolution: don't download Maven-provided artifacts
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-7097: --- Summary: Plugin Dependency Resolution: don't download Maven-provided artifacts (was: Plugin Dependency Resolution) > Plugin Dependency Resolution: don't download Maven-provided artifacts > - > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] cstamas opened a new pull request #450: [MNG-7097] Plugin Dependency Resolution Improvement
cstamas opened a new pull request #450: URL: https://github.com/apache/maven/pull/450 Implements a helper component for plugin dependency resolution that provider filter and selector that leaves out core artifacts from collection and resolution. 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-7097) Plugin Dependency Resolution
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287922#comment-17287922 ] Herve Boutemy commented on MNG-7097: for the record, here is the code extensions.xml that drive the eviction process: https://maven.apache.org/ref/3.6.3/maven-core/core-extensions.html every "exportedArtifact" from the previous list is evicted from resolution notice that plexus-utils is not evicted: only 4 classes are marked "exportedPackage", but plexus-utils is not exported artifact a little bit like Wagon: some classes/packages are exported, but no artifacts > Plugin Dependency Resolution > > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7063) Infinite loop using Shade plugin and JUnit 5 dependency
[
https://issues.apache.org/jira/browse/MNG-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287917#comment-17287917
]
Hudson commented on MNG-7063:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #107
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/107/
> Infinite loop using Shade plugin and JUnit 5 dependency
> ---
>
> Key: MNG-7063
> URL: https://issues.apache.org/jira/browse/MNG-7063
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Thiago Henrique Hupner
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> When trying my project with Maven 4.0.0, it got in an infinite loop.
> I've figured out that adding the JUnit 5 dependency and using the Shade
> plugin transformer causes the problem.
> With Maven 3.6.3 this problem doesn't happen.
>
> {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
> org.example
> maven-bug
> 1.0-SNAPSHOT
>
> 8
> 8
>
> jar
>
>
> com.google.guava
> guava
> 29.0-jre
>
>
> org.junit.jupiter
> junit-jupiter-api
> 5.7.0
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> 3.2.4
>
>
> package
>
> shade
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-7097) Plugin Dependency Resolution
[ https://issues.apache.org/jira/browse/MNG-7097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamás Cservenák reassigned MNG-7097: Assignee: Tamás Cservenák > Plugin Dependency Resolution > > > Key: MNG-7097 > URL: https://issues.apache.org/jira/browse/MNG-7097 > Project: Maven > Issue Type: Task > Components: Performance, Plugins and Lifecycle >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > > Current Maven behavior for resolving plugin dependencies is to download full > transitive graph of plugin dependency, but for executing plugin it filters > out core artifacts from graph (excludes them). > This results in unnecessary downloads of core artifacts, multiplied by > multiple versions used by different plugins, and local repository end up > having artifacts that may even surprise users. > Most notable examples: maven-core (user: "Why did Maven download maven-core-X > when I use maven-Y?"), plexus-container-default (user: "Why does Maven > download 10+ versions of this legacy artifact (adv user: when > sisu-inject-plexus shim is used instead)?"), multiple versions of > plexus-utils etc... > We need to investigate what exactly happens with downloaded, but unused core > artifacts (if they are completely excluded based on GAV, we are safest), and > simply exclude them even from resolution/collection, as they are really not > needed. > This will not "improve build speed", but does lessen "bandwidth", as > experiments shows that cutting plugin dependencies for core artifacts for > Maven project itself makes about 1k less remote requests (artifact and > artifact checksum downloads). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] cstamas commented on pull request #418: [MNG-6114] Elements from the global settings should be ordered before…
cstamas commented on pull request #418: URL: https://github.com/apache/maven/pull/418#issuecomment-782838092 IMHO this looks okay. 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] [Closed] (MNG-7063) Infinite loop using Shade plugin and JUnit 5 dependency
[
https://issues.apache.org/jira/browse/MNG-7063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MNG-7063.
---
Resolution: Fixed
Final fix with
[8ceb6c6e99a3268d6091357f116d3acc2ba17b5a|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=8ceb6c6e99a3268d6091357f116d3acc2ba17b5a]
With this the attached pom breaks out of the loop as expected.
> Infinite loop using Shade plugin and JUnit 5 dependency
> ---
>
> Key: MNG-7063
> URL: https://issues.apache.org/jira/browse/MNG-7063
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
>Reporter: Thiago Henrique Hupner
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> When trying my project with Maven 4.0.0, it got in an infinite loop.
> I've figured out that adding the JUnit 5 dependency and using the Shade
> plugin transformer causes the problem.
> With Maven 3.6.3 this problem doesn't happen.
>
> {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
> org.example
> maven-bug
> 1.0-SNAPSHOT
>
> 8
> 8
>
> jar
>
>
> com.google.guava
> guava
> 29.0-jre
>
>
> org.junit.jupiter
> junit-jupiter-api
> 5.7.0
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-shade-plugin
> 3.2.4
>
>
> package
>
> shade
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] michael-o commented on pull request #418: [MNG-6114] Elements from the global settings should be ordered before…
michael-o commented on pull request #418: URL: https://github.com/apache/maven/pull/418#issuecomment-782828088 @cstamas @stephenc Any opinion? 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] michael-o commented on pull request #448: [MNG-7102] The child modules of excluded projects are now excluded
michael-o commented on pull request #448: URL: https://github.com/apache/maven/pull/448#issuecomment-782828043 I wonder what would happen if I have this: root: mod_a, mod_b, mod_c mod_c: mod_c_1, mod_c_2, mod_c_3 mod_c_2: mod_c_2_1, mod_c_2_2, mod_c_2_3 mod_c_2_2: mod_c_2_2_1, mod_c_2_2_2 `mvn -pl !mod_c2,mod_c_2_2` I think this should be the equivalent of `mvn -pl mod_c_2_2`. 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] (MRESOLVER-164) DefaultDependencyCollector filterVersions seems always return full version range
[ https://issues.apache.org/jira/browse/MRESOLVER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287888#comment-17287888 ] Michael Osipov commented on MRESOLVER-164: -- [~xiangli1996], can you bundle up your problem into a Maven IT? We'd need to evaluate [~cstamas]'s changes againt Maven master. [~cstamas], WDYT was this just an oversight during programming? With a range I see no reason to download versions in between which aren't used anyway. > DefaultDependencyCollector filterVersions seems always return full version > range > > > Key: MRESOLVER-164 > URL: https://issues.apache.org/jira/browse/MRESOLVER-164 > Project: Maven Resolver > Issue Type: Bug >Affects Versions: 1.4.2, 1.6.1 >Reporter: Xiang Li >Priority: Major > > Related to MNG-7049 but I think the root cause is in maven-resolver so I > opened a new issue. Correct me if it is better to still use the old ticket. > During using version ranges, I notice that maven will download all poms from > a version range, which happen in that > [loop|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L404], > the reason is that > [verFilter|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155] > here seems return null. Since by default, versionFilter is set to null by > DefaultRepositorySystemSession, and I do not see many examples that > setVersionFilter get used for some reason. > Another thing that confuses me is that version range is resolved by > DefaultVersionRangeResolver in maven rather than maven-resolver here. > > I wonder if it possible to set HighestVersionFilter > [here|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155] > instead of return all version range results. I am happy to contribute a PR > with some guidance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNGSITE-440) Report plugin not configured correctly according to documentation
[
https://issues.apache.org/jira/browse/MNGSITE-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MNGSITE-440:
-
Labels: up-for-grabs (was: )
> Report plugin not configured correctly according to documentation
> -
>
> Key: MNGSITE-440
> URL: https://issues.apache.org/jira/browse/MNGSITE-440
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Jan Monterrubio
>Priority: Minor
> Labels: up-for-grabs
>
> Using the referenced documentation:
> [http://maven.apache.org/guides/mini/guide-configuring-plugins.html#configuring-reporting-plugins
>
> |http://maven.apache.org/guides/mini/guide-configuring-plugins.html#configuring-reporting-plugins]
> I believe there is an issue with the way the report mojo is configured when
> invoking the site vs invoking the goal directly.
> h1. Reproducible Sample
> A minimal plugin that reproduces the issue can be found here:
> [https://github.com/AnEmortalKid/sample-report-plugin] , a project that uses
> the plugin can be found in the same repository under
> src/test/resources/it/config-print
>
> h3. Setup
> Mojo
> {code:java}
> @Mojo(name = "word", defaultPhase = LifecyclePhase.SITE, threadSafe =
> true)public class SampleReport extends AbstractMavenReport {
> @Parameter private String word;
> protected void executeReport(Locale locale) throws MavenReportException {
> getLog().info("Word is " + word); }
> public String getOutputName() {return "word.html"; }
> public String getName(Locale locale) {return "word"; }
> public String getDescription(Locale locale) {return "Prints a word from
> config"; }}{code}
> h3. Project
> {code:java}
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> 4.0.0
> io.anemortalkid
> config-print
> 1.0.0-SNAPSHOT
>
> UTF-8
>
>
>
>
>
> io.anemortalkid
> sample-report-plugin
> 1.0.0-SNAPSHOT
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 3.9.0
>
>
>
>
>
> io.anemortalkid
> sample-report-plugin
>
> fromBuild
>
>
>
>
>
>
>
> io.anemortalkid
> sample-report-plugin
>
> fromReporting
>
>
>
>
> {code}
> h2. Site Invocation
>
> Invoking the site phase yields the correct behavior according to the doc:
> "It uses *only* the parameters defined in the element of each
> reporting Plugin specified in the element, i.e. {{site}} always
> *ignores* the parameters defined in the element of each
> plugin specified in ."
> {code:java}
> [INFO] --- maven-site-plugin:3.9.0:site (default-site) @ config-print ---
> [INFO] configuring report plugin
> io.anemortalkid:sample-report-plugin:1.0.0-SNAPSHOT
> [INFO] 1 report detected for sample-report-plugin:1.0.0-SNAPSHOT: word
> [WARNING] Report plugin
> org.apache.maven.plugins:maven-project-info-reports-plugin has an empty
> version.
> [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.
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-project-info-reports-plugin:3.1.1
> [INFO] 15 reports detected for maven-project-info-reports-plugin:3.1.1:
> ci-management, dependencies, dependency-info, dependency-management,
> distribution-management, index, issue-management, licenses, mailing-lists,
> modules, plugin-management, plugins, scm, summary, team
> [INFO] Rendering site with default locale English (en)
> [WARNING] No project URL defined - decoration links will not be relativized!
> [INFO] Rendering content with
> org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
> [INFO] Generating "word" report ---
> sample-report-plugin:1.0.0-SNAPSHOT:word
> [INFO] Word is fromReporting
> [INFO] Generating "Dependency Information" report ---
> maven-project-info-reports-plugin:3.1.1:dependency-info
> [INFO] Generating "About" report ---
> maven-project-info-reports-plugin:3.1.1:index
> [INFO] Generating "Plugin Management" report ---
>
[jira] [Updated] (MSHARED-979) maven-shared-components uses commons-io 2.6 which is vulnerable to sonatype-2018-0705
[
https://issues.apache.org/jira/browse/MSHARED-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MSHARED-979:
-
Labels: Java8 (was: )
> maven-shared-components uses commons-io 2.6 which is vulnerable to
> sonatype-2018-0705
> -
>
> Key: MSHARED-979
> URL: https://issues.apache.org/jira/browse/MSHARED-979
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.3.3
>Reporter: Scott Marshall
>Priority: Major
> Labels: Java8
>
> maven-shared-components uses commons-io 2.6 which is vulnerable to
> sonatype-2018-0705
> h4. ISSUE
> sonatype-2018-0705
> h4. SEVERITY
> Sonatype CVSS 3:7.8
> CVE CVSS 2.0:0.0
>
> h4. EXPLANATION
> The {{commons-io}} package is vulnerable to Path Traversal. The
> {{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the
> hostname value received from user input before processing client requests. An
> attacker could abuse this behavior by crafting a special payload containing
> unexpected characters that could allow the access to unintended resources.
> h4. ROOT CAUSE
> commons-io-2.6.jarorg/apache/commons/io/FilenameUtils.class[1.1 ,
> 2.7-SNAPSHOT)
> org-apache-commons-io-RELEASE113.jarorg/apache/commons/io/FilenameUtils.class[1.1
> , 2.7-SNAPSHOT)
>
> h4. ADVISORIES
> Project:[https://github.com/apache/commons-io/pull/52]
> Project:https://issues.apache.org/jira/browse/IO-556
> Project:https://issues.apache.org/jira/browse/IO-559
> h4. CVSS DETAILS
> Sonatype CVSS 3:7.8
> CVSS Vector:CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MSHARED-979) maven-shared-components uses commons-io 2.6 which is vulnerable to sonatype-2018-0705
[
https://issues.apache.org/jira/browse/MSHARED-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylwester Lachiewicz updated MSHARED-979:
-
Component/s: maven-shared-utils
> maven-shared-components uses commons-io 2.6 which is vulnerable to
> sonatype-2018-0705
> -
>
> Key: MSHARED-979
> URL: https://issues.apache.org/jira/browse/MSHARED-979
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-shared-utils
>Affects Versions: maven-shared-utils-3.3.3
>Reporter: Scott Marshall
>Priority: Major
>
> maven-shared-components uses commons-io 2.6 which is vulnerable to
> sonatype-2018-0705
> h4. ISSUE
> sonatype-2018-0705
> h4. SEVERITY
> Sonatype CVSS 3:7.8
> CVE CVSS 2.0:0.0
>
> h4. EXPLANATION
> The {{commons-io}} package is vulnerable to Path Traversal. The
> {{getPrefixLength}} method in {{FilenameUtils.class}} improperly verifies the
> hostname value received from user input before processing client requests. An
> attacker could abuse this behavior by crafting a special payload containing
> unexpected characters that could allow the access to unintended resources.
> h4. ROOT CAUSE
> commons-io-2.6.jarorg/apache/commons/io/FilenameUtils.class[1.1 ,
> 2.7-SNAPSHOT)
> org-apache-commons-io-RELEASE113.jarorg/apache/commons/io/FilenameUtils.class[1.1
> , 2.7-SNAPSHOT)
>
> h4. ADVISORIES
> Project:[https://github.com/apache/commons-io/pull/52]
> Project:https://issues.apache.org/jira/browse/IO-556
> Project:https://issues.apache.org/jira/browse/IO-559
> h4. CVSS DETAILS
> Sonatype CVSS 3:7.8
> CVSS Vector:CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
