[GitHub] [maven-site] dependabot[bot] closed pull request #418: Bump plantuml from 1.2023.6 to 1.2023.7
dependabot[bot] closed pull request #418: Bump plantuml from 1.2023.6 to 1.2023.7 URL: https://github.com/apache/maven-site/pull/418 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-site] dependabot[bot] opened a new pull request, #422: Bump plantuml from 1.2023.6 to 1.2023.8
dependabot[bot] opened a new pull request, #422: URL: https://github.com/apache/maven-site/pull/422 Bumps [plantuml](https://github.com/plantuml/plantuml) from 1.2023.6 to 1.2023.8. Commits https://github.com/plantuml/plantuml/commit/92c5183386d403fe23616de3825afb58610316d6;>92c5183 chore: suppress some versions https://github.com/plantuml/plantuml/commit/63a09e24c55eeb8b456760c2e853d01b5c9f4e32;>63a09e2 chore: Version 1.2023.8 https://github.com/plantuml/plantuml/commit/18a7f99b556af3a451bdf9c8a41929f820106fd6;>18a7f99 fix: improve theme support https://github.com/plantuml/plantuml/commit/95026709a6619cc3f086820a7f9c099e90525b85;>9502670 chore: question about improving Version.java and gradle.properties https://github.com/plantuml/plantuml/commit/f72fec23c3027be69d7989938efea2520e6ed1dc;>f72fec2 fix: improve theme support https://github.com/plantuml/plantuml/commit/35ec8a700cccb47f2d9a0ced5d89085772cfaebd;>35ec8a7 chore: simply Version.java implementation https://github.com/plantuml/plantuml/commit/eb85d9c9c52302dd0ef11985735acbea297c1485;>eb85d9c chore: build only GPL and MIT version for beta https://github.com/plantuml/plantuml/commit/2a358adf3c1fb9fd21f30ec27f1fa0a8b1494f23;>2a358ad chore: restore tests under linux https://github.com/plantuml/plantuml/commit/2adee2f574f9942f251d484bfc5d0a126930ea76;>2adee2f chore: improve multilicence and add improve theme support https://github.com/plantuml/plantuml/commit/2803fa7e7b460e1aedcadb784cfa5ea18a193942;>2803fa7 chore: add javadoc for MIT because of OSSRH Additional commits viewable in https://github.com/plantuml/plantuml/compare/v1.2023.6...v1.2023.8;>compare view [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=net.sourceforge.plantuml:plantuml=maven=1.2023.6=1.2023.8)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MPOM-398) Bump maven-help-plugin from 3.3.0 to 3.4.0
[ https://issues.apache.org/jira/browse/MPOM-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MPOM-398. Resolution: Fixed > Bump maven-help-plugin from 3.3.0 to 3.4.0 > -- > > Key: MPOM-398 > URL: https://issues.apache.org/jira/browse/MPOM-398 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-30 > > > {{maven-help-plugin}} require {{Maven 3.6.3}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-apache-parent] slawekjaranowski merged pull request #135: [MPOM-398] Bump maven-help-plugin from 3.3.0 to 3.4.0
slawekjaranowski merged PR #135: URL: https://github.com/apache/maven-apache-parent/pull/135 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MWAR-464) Update dependencies in lifecycle mapping
Slawomir Jaranowski created MWAR-464: Summary: Update dependencies in lifecycle mapping Key: MWAR-464 URL: https://issues.apache.org/jira/browse/MWAR-464 Project: Maven WAR Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Fix For: 3.4.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MENFORCER-393) Upgrading to 3.0.0 causes `Could not build dependency tree` with repositories some unknown protocol
[ https://issues.apache.org/jira/browse/MENFORCER-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MENFORCER-393. - Fix Version/s: 3.3.1 Resolution: Fixed fixed in 3.3.0 - now I added IT for regressions, so reports in 3.3.1 > Upgrading to 3.0.0 causes `Could not build dependency tree` with repositories > some unknown protocol > --- > > Key: MENFORCER-393 > URL: https://issues.apache.org/jira/browse/MENFORCER-393 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: dependencyConvergence, Plugin >Affects Versions: 3.0.0 >Reporter: johnny willer gasperi goncalves >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.3.1 > > Attachments: enforcer_output > > > After upgrading to 3.0.0, it's not possible to validate the POM anymore, an > error like > {code:java} > Could not build dependency tree Could not collect dependencies: > {jarname}{code} > happens. > > I'm attaching the `mvn validate -X` dump (i have omitted some jars from the > output) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-393) Upgrading to 3.0.0 causes `Could not build dependency tree` with repositories some unknown protocol
[ https://issues.apache.org/jira/browse/MENFORCER-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725132#comment-17725132 ] ASF GitHub Bot commented on MENFORCER-393: -- slawekjaranowski merged PR #271: URL: https://github.com/apache/maven-enforcer/pull/271 > Upgrading to 3.0.0 causes `Could not build dependency tree` with repositories > some unknown protocol > --- > > Key: MENFORCER-393 > URL: https://issues.apache.org/jira/browse/MENFORCER-393 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: dependencyConvergence, Plugin >Affects Versions: 3.0.0 >Reporter: johnny willer gasperi goncalves >Assignee: Slawomir Jaranowski >Priority: Major > Attachments: enforcer_output > > > After upgrading to 3.0.0, it's not possible to validate the POM anymore, an > error like > {code:java} > Could not build dependency tree Could not collect dependencies: > {jarname}{code} > happens. > > I'm attaching the `mvn validate -X` dump (i have omitted some jars from the > output) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725131#comment-17725131 ] ASF GitHub Bot commented on MNG-7789: - hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201137338 ## maven-core/src/main/java/org/apache/maven/plugin/internal/PlexusContainerDefaultDependenciesValidator.java: ## @@ -40,14 +41,17 @@ class PlexusContainerDefaultDependenciesValidator extends AbstractMavenPluginDep super(pluginValidationManager); } -protected void doValidate(MavenSession mavenSession, MojoDescriptor mojoDescriptor) { -boolean pcdPresent = mojoDescriptor.getPluginDescriptor().getDependencies().stream() -.filter(d -> "org.codehaus.plexus".equals(d.getGroupId())) -.anyMatch(d -> "plexus-container-default".equals(d.getArtifactId())); +protected void doValidate( +RepositorySystemSession session, +Artifact pluginArtifact, +ArtifactDescriptorResult artifactDescriptorResult) { +boolean pcdPresent = artifactDescriptorResult.getDependencies().stream() +.filter(d -> "org.codehaus.plexus".equals(d.getArtifact().getGroupId())) +.anyMatch(d -> "plexus-container-default".equals(d.getArtifact().getArtifactId())); if (pcdPresent) { pluginValidationManager.reportPluginValidationIssue( -mavenSession, mojoDescriptor, "Plugin depends on plexus-container-default, which is EOL"); +session, pluginArtifact, "Plugin depends on plexus-container-default, which is EOL"); Review Comment: this looks like it could be a more generic "check for end of life" component checker if there other stuff that is EOLed, too. > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] hgschmie commented on a diff in pull request #1115: [MNG-7789] Dependency validation rules used wrong data
hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201137338 ## maven-core/src/main/java/org/apache/maven/plugin/internal/PlexusContainerDefaultDependenciesValidator.java: ## @@ -40,14 +41,17 @@ class PlexusContainerDefaultDependenciesValidator extends AbstractMavenPluginDep super(pluginValidationManager); } -protected void doValidate(MavenSession mavenSession, MojoDescriptor mojoDescriptor) { -boolean pcdPresent = mojoDescriptor.getPluginDescriptor().getDependencies().stream() -.filter(d -> "org.codehaus.plexus".equals(d.getGroupId())) -.anyMatch(d -> "plexus-container-default".equals(d.getArtifactId())); +protected void doValidate( +RepositorySystemSession session, +Artifact pluginArtifact, +ArtifactDescriptorResult artifactDescriptorResult) { +boolean pcdPresent = artifactDescriptorResult.getDependencies().stream() +.filter(d -> "org.codehaus.plexus".equals(d.getArtifact().getGroupId())) +.anyMatch(d -> "plexus-container-default".equals(d.getArtifact().getArtifactId())); if (pcdPresent) { pluginValidationManager.reportPluginValidationIssue( -mavenSession, mojoDescriptor, "Plugin depends on plexus-container-default, which is EOL"); +session, pluginArtifact, "Plugin depends on plexus-container-default, which is EOL"); Review Comment: this looks like it could be a more generic "check for end of life" component checker if there other stuff that is EOLed, too. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725130#comment-17725130 ] ASF GitHub Bot commented on MNG-7789: - hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201134456 ## maven-core/src/main/java/org/apache/maven/plugin/internal/MavenScopeDependenciesValidator.java: ## @@ -0,0 +1,70 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.maven.plugin.internal; + +import javax.inject.Inject; +import javax.inject.Named; +import javax.inject.Singleton; + +import java.util.Set; +import java.util.stream.Collectors; + +import org.apache.maven.plugin.PluginValidationManager; +import org.eclipse.aether.RepositorySystemSession; +import org.eclipse.aether.artifact.Artifact; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; +import org.eclipse.aether.util.artifact.JavaScopes; + +/** + * Detects Maven3 dependencies scope. + * + * @since 3.9.3 + */ +@Singleton +@Named +class MavenScopeDependenciesValidator extends AbstractMavenPluginDependenciesValidator { + +@Inject +MavenScopeDependenciesValidator(PluginValidationManager pluginValidationManager) { +super(pluginValidationManager); +} + +@Override +protected void doValidate( +RepositorySystemSession session, +Artifact pluginArtifact, +ArtifactDescriptorResult artifactDescriptorResult) { +Set mavenArtifacts = artifactDescriptorResult.getDependencies().stream() +.filter(d -> !JavaScopes.PROVIDED.equals(d.getScope()) && !JavaScopes.TEST.equals(d.getScope())) +.map(org.eclipse.aether.graph.Dependency::getArtifact) +.filter(a -> "org.apache.maven".equals(a.getGroupId())) +.filter(a -> !DefaultPluginValidationManager.EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA.contains( +a.getGroupId() + ":" + a.getArtifactId())) +.filter(a -> a.getVersion().startsWith("3.")) +.map(a -> a.getGroupId() + ":" + a.getArtifactId() + ":" + a.getVersion()) +.collect(Collectors.toSet()); + +if (!mavenArtifacts.isEmpty()) { +pluginValidationManager.reportPluginValidationIssue( +session, +pluginArtifact, +"Plugin should declare these Maven artifacts in `provided` scope: " + mavenArtifacts); Review Comment: same as above. Adding the line "if the plugin already declares them in `provided` scope, update the plugin-plugin to at least version x.y.z (see Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] hgschmie commented on a diff in pull request #1115: [MNG-7789] Dependency validation rules used wrong data
hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201134456 ## maven-core/src/main/java/org/apache/maven/plugin/internal/MavenScopeDependenciesValidator.java: ## @@ -0,0 +1,70 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.maven.plugin.internal; + +import javax.inject.Inject; +import javax.inject.Named; +import javax.inject.Singleton; + +import java.util.Set; +import java.util.stream.Collectors; + +import org.apache.maven.plugin.PluginValidationManager; +import org.eclipse.aether.RepositorySystemSession; +import org.eclipse.aether.artifact.Artifact; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; +import org.eclipse.aether.util.artifact.JavaScopes; + +/** + * Detects Maven3 dependencies scope. + * + * @since 3.9.3 + */ +@Singleton +@Named +class MavenScopeDependenciesValidator extends AbstractMavenPluginDependenciesValidator { + +@Inject +MavenScopeDependenciesValidator(PluginValidationManager pluginValidationManager) { +super(pluginValidationManager); +} + +@Override +protected void doValidate( +RepositorySystemSession session, +Artifact pluginArtifact, +ArtifactDescriptorResult artifactDescriptorResult) { +Set mavenArtifacts = artifactDescriptorResult.getDependencies().stream() +.filter(d -> !JavaScopes.PROVIDED.equals(d.getScope()) && !JavaScopes.TEST.equals(d.getScope())) +.map(org.eclipse.aether.graph.Dependency::getArtifact) +.filter(a -> "org.apache.maven".equals(a.getGroupId())) +.filter(a -> !DefaultPluginValidationManager.EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA.contains( +a.getGroupId() + ":" + a.getArtifactId())) +.filter(a -> a.getVersion().startsWith("3.")) +.map(a -> a.getGroupId() + ":" + a.getArtifactId() + ":" + a.getVersion()) +.collect(Collectors.toSet()); + +if (!mavenArtifacts.isEmpty()) { +pluginValidationManager.reportPluginValidationIssue( +session, +pluginArtifact, +"Plugin should declare these Maven artifacts in `provided` scope: " + mavenArtifacts); Review Comment: same as above. Adding the line "if the plugin already declares them in `provided` scope, update the plugin-plugin to at least version x.y.z (see
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725128#comment-17725128 ] ASF GitHub Bot commented on MNG-7789: - hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201132331 ## maven-core/src/main/java/org/apache/maven/plugin/internal/MavenArtifactsMavenPluginDescriptorDependenciesValidator.java: ## @@ -0,0 +1,74 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.maven.plugin.internal; + +import javax.inject.Inject; +import javax.inject.Named; +import javax.inject.Singleton; + +import java.util.Set; +import java.util.stream.Collectors; + +import org.apache.maven.execution.MavenSession; +import org.apache.maven.plugin.PluginValidationManager; +import org.apache.maven.plugin.descriptor.MojoDescriptor; + +/** + * Detects presence of unwanted Maven3 artifacts in plugin descriptor, possibly caused by multitude of reasons, among + * them is "wrong scope" dependency declaration as well. + * + * Historically, this class was named as "MavenScopeDependenciesValidator" due original intent to check "wrong Maven + * Artifact scopes". Since then, it turned out that the values validated (the plugin descriptor dependencies, that is + * produced at plugin build time by maven-plugin-plugin) may be off (for example due maven-plugin-plugin bug), and + * is potentially not inline with "reality" (actual plugin dependencies). + * + * The original intent related check is moved to + * {@link DefaultPluginDependenciesResolver#resolve(org.apache.maven.model.Plugin, java.util.List, org.eclipse.aether.RepositorySystemSession)} + * method instead. + * + * @since 3.9.3 + */ +@Singleton +@Named +class MavenArtifactsMavenPluginDescriptorDependenciesValidator +extends AbstractMavenPluginDescriptorDependenciesValidator { + +@Inject + MavenArtifactsMavenPluginDescriptorDependenciesValidator(PluginValidationManager pluginValidationManager) { +super(pluginValidationManager); +} + +@Override +protected void doValidate(MavenSession mavenSession, MojoDescriptor mojoDescriptor) { +Set mavenArtifacts = mojoDescriptor.getPluginDescriptor().getDependencies().stream() +.filter(d -> "org.apache.maven".equals(d.getGroupId())) +.filter(d -> !DefaultPluginValidationManager.EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA.contains( +d.getGroupId() + ":" + d.getArtifactId())) +.filter(d -> d.getVersion().startsWith("3.")) +.map(d -> d.getGroupId() + ":" + d.getArtifactId() + ":" + d.getVersion()) +.collect(Collectors.toSet()); + +if (!mavenArtifacts.isEmpty()) { +pluginValidationManager.reportPluginValidationIssue( +mavenSession, +mojoDescriptor, +"Plugin descriptor should not contain these Maven artifacts: " + mavenArtifacts); Review Comment: there should be an explanation *why* the descriptor should not contain them (and what a plugin author can do, e.g. "update the version of the maven-plugin-plugin to at least ..."). > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] hgschmie commented on a diff in pull request #1115: [MNG-7789] Dependency validation rules used wrong data
hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201132331 ## maven-core/src/main/java/org/apache/maven/plugin/internal/MavenArtifactsMavenPluginDescriptorDependenciesValidator.java: ## @@ -0,0 +1,74 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.maven.plugin.internal; + +import javax.inject.Inject; +import javax.inject.Named; +import javax.inject.Singleton; + +import java.util.Set; +import java.util.stream.Collectors; + +import org.apache.maven.execution.MavenSession; +import org.apache.maven.plugin.PluginValidationManager; +import org.apache.maven.plugin.descriptor.MojoDescriptor; + +/** + * Detects presence of unwanted Maven3 artifacts in plugin descriptor, possibly caused by multitude of reasons, among + * them is "wrong scope" dependency declaration as well. + * + * Historically, this class was named as "MavenScopeDependenciesValidator" due original intent to check "wrong Maven + * Artifact scopes". Since then, it turned out that the values validated (the plugin descriptor dependencies, that is + * produced at plugin build time by maven-plugin-plugin) may be off (for example due maven-plugin-plugin bug), and + * is potentially not inline with "reality" (actual plugin dependencies). + * + * The original intent related check is moved to + * {@link DefaultPluginDependenciesResolver#resolve(org.apache.maven.model.Plugin, java.util.List, org.eclipse.aether.RepositorySystemSession)} + * method instead. + * + * @since 3.9.3 + */ +@Singleton +@Named +class MavenArtifactsMavenPluginDescriptorDependenciesValidator +extends AbstractMavenPluginDescriptorDependenciesValidator { + +@Inject + MavenArtifactsMavenPluginDescriptorDependenciesValidator(PluginValidationManager pluginValidationManager) { +super(pluginValidationManager); +} + +@Override +protected void doValidate(MavenSession mavenSession, MojoDescriptor mojoDescriptor) { +Set mavenArtifacts = mojoDescriptor.getPluginDescriptor().getDependencies().stream() +.filter(d -> "org.apache.maven".equals(d.getGroupId())) +.filter(d -> !DefaultPluginValidationManager.EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA.contains( +d.getGroupId() + ":" + d.getArtifactId())) +.filter(d -> d.getVersion().startsWith("3.")) +.map(d -> d.getGroupId() + ":" + d.getArtifactId() + ":" + d.getVersion()) +.collect(Collectors.toSet()); + +if (!mavenArtifacts.isEmpty()) { +pluginValidationManager.reportPluginValidationIssue( +mavenSession, +mojoDescriptor, +"Plugin descriptor should not contain these Maven artifacts: " + mavenArtifacts); Review Comment: there should be an explanation *why* the descriptor should not contain them (and what a plugin author can do, e.g. "update the version of the maven-plugin-plugin to at least ..."). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725127#comment-17725127 ] ASF GitHub Bot commented on MNG-7789: - hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201131597 ## maven-core/src/main/java/org/apache/maven/plugin/internal/Maven3CompatDependenciesValidator.java: ## @@ -0,0 +1,61 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.maven.plugin.internal; + +import javax.inject.Inject; +import javax.inject.Named; +import javax.inject.Singleton; + +import org.apache.maven.plugin.PluginValidationManager; +import org.eclipse.aether.RepositorySystemSession; +import org.eclipse.aether.artifact.Artifact; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; +import org.eclipse.aether.util.artifact.JavaScopes; + +/** + * Detects Maven3 plugins using maven-compat Maven2 compatibility layer. + * + * @since 3.9.3 + */ +@Singleton +@Named +class Maven3CompatDependenciesValidator extends AbstractMavenPluginDependenciesValidator { + +@Inject +Maven3CompatDependenciesValidator(PluginValidationManager pluginValidationManager) { +super(pluginValidationManager); +} + +@Override +protected void doValidate( +RepositorySystemSession session, +Artifact pluginArtifact, +ArtifactDescriptorResult artifactDescriptorResult) { +for (org.eclipse.aether.graph.Dependency dependency : artifactDescriptorResult.getDependencies()) { +if ("org.apache.maven".equals(dependency.getArtifact().getGroupId()) +&& "maven-compat".equals(dependency.getArtifact().getArtifactId()) +&& !JavaScopes.TEST.equals(dependency.getScope())) { +pluginValidationManager.reportPluginValidationIssue( +session, +pluginArtifact, +"Plugin depends on the deprecated Maven 2.x compatibility layer, which may not be supported in Maven 4.x"); Review Comment: this says "may not be supported". It implies that there is chance that it may still be supported. This should be the same wording as above. > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] hgschmie commented on a diff in pull request #1115: [MNG-7789] Dependency validation rules used wrong data
hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201131597 ## maven-core/src/main/java/org/apache/maven/plugin/internal/Maven3CompatDependenciesValidator.java: ## @@ -0,0 +1,61 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.maven.plugin.internal; + +import javax.inject.Inject; +import javax.inject.Named; +import javax.inject.Singleton; + +import org.apache.maven.plugin.PluginValidationManager; +import org.eclipse.aether.RepositorySystemSession; +import org.eclipse.aether.artifact.Artifact; +import org.eclipse.aether.resolution.ArtifactDescriptorResult; +import org.eclipse.aether.util.artifact.JavaScopes; + +/** + * Detects Maven3 plugins using maven-compat Maven2 compatibility layer. + * + * @since 3.9.3 + */ +@Singleton +@Named +class Maven3CompatDependenciesValidator extends AbstractMavenPluginDependenciesValidator { + +@Inject +Maven3CompatDependenciesValidator(PluginValidationManager pluginValidationManager) { +super(pluginValidationManager); +} + +@Override +protected void doValidate( +RepositorySystemSession session, +Artifact pluginArtifact, +ArtifactDescriptorResult artifactDescriptorResult) { +for (org.eclipse.aether.graph.Dependency dependency : artifactDescriptorResult.getDependencies()) { +if ("org.apache.maven".equals(dependency.getArtifact().getGroupId()) +&& "maven-compat".equals(dependency.getArtifact().getArtifactId()) +&& !JavaScopes.TEST.equals(dependency.getScope())) { +pluginValidationManager.reportPluginValidationIssue( +session, +pluginArtifact, +"Plugin depends on the deprecated Maven 2.x compatibility layer, which may not be supported in Maven 4.x"); Review Comment: this says "may not be supported". It implies that there is chance that it may still be supported. This should be the same wording as above. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725126#comment-17725126 ] ASF GitHub Bot commented on MNG-7789: - hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201130613 ## maven-core/src/main/java/org/apache/maven/plugin/internal/Maven2DependenciesValidator.java: ## @@ -45,19 +46,22 @@ class Maven2DependenciesValidator extends AbstractMavenPluginDependenciesValidat } @Override -protected void doValidate(MavenSession mavenSession, MojoDescriptor mojoDescriptor) { -Set maven2Versions = mojoDescriptor.getPluginDescriptor().getDependencies().stream() +protected void doValidate( +RepositorySystemSession session, +Artifact pluginArtifact, +ArtifactDescriptorResult artifactDescriptorResult) { +Set maven2Versions = artifactDescriptorResult.getDependencies().stream() +.map(Dependency::getArtifact) .filter(d -> "org.apache.maven".equals(d.getGroupId())) -.filter(d -> !EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA.contains(d.getGroupId() + ":" + d.getArtifactId())) -.map(ComponentDependency::getVersion) +.filter(d -> !DefaultPluginValidationManager.EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA.contains( +d.getGroupId() + ":" + d.getArtifactId())) +.map(Artifact::getVersion) .filter(v -> v.startsWith("2.")) .collect(Collectors.toSet()); if (!maven2Versions.isEmpty()) { pluginValidationManager.reportPluginValidationIssue( -mavenSession, -mojoDescriptor, -"Plugin is a Maven 2.x plugin, which will be not supported in Maven 4.x"); +session, pluginArtifact, "Plugin is a Maven 2.x plugin, which will be not supported in Maven 4.x"); Review Comment: this says "will not be supported" > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] hgschmie commented on a diff in pull request #1115: [MNG-7789] Dependency validation rules used wrong data
hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201130613 ## maven-core/src/main/java/org/apache/maven/plugin/internal/Maven2DependenciesValidator.java: ## @@ -45,19 +46,22 @@ class Maven2DependenciesValidator extends AbstractMavenPluginDependenciesValidat } @Override -protected void doValidate(MavenSession mavenSession, MojoDescriptor mojoDescriptor) { -Set maven2Versions = mojoDescriptor.getPluginDescriptor().getDependencies().stream() +protected void doValidate( +RepositorySystemSession session, +Artifact pluginArtifact, +ArtifactDescriptorResult artifactDescriptorResult) { +Set maven2Versions = artifactDescriptorResult.getDependencies().stream() +.map(Dependency::getArtifact) .filter(d -> "org.apache.maven".equals(d.getGroupId())) -.filter(d -> !EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA.contains(d.getGroupId() + ":" + d.getArtifactId())) -.map(ComponentDependency::getVersion) +.filter(d -> !DefaultPluginValidationManager.EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA.contains( +d.getGroupId() + ":" + d.getArtifactId())) +.map(Artifact::getVersion) .filter(v -> v.startsWith("2.")) .collect(Collectors.toSet()); if (!maven2Versions.isEmpty()) { pluginValidationManager.reportPluginValidationIssue( -mavenSession, -mojoDescriptor, -"Plugin is a Maven 2.x plugin, which will be not supported in Maven 4.x"); +session, pluginArtifact, "Plugin is a Maven 2.x plugin, which will be not supported in Maven 4.x"); Review Comment: this says "will not be supported" -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725125#comment-17725125 ] ASF GitHub Bot commented on MNG-7789: - hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201128767 ## maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java: ## @@ -22,11 +22,7 @@ import javax.inject.Singleton; import java.io.File; -import java.util.Arrays; -import java.util.LinkedHashMap; -import java.util.LinkedHashSet; -import java.util.Locale; -import java.util.Map; +import java.util.*; Review Comment: *cringe* > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] hgschmie commented on a diff in pull request #1115: [MNG-7789] Dependency validation rules used wrong data
hgschmie commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1201128767 ## maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java: ## @@ -22,11 +22,7 @@ import javax.inject.Singleton; import java.io.File; -import java.util.Arrays; -import java.util.LinkedHashMap; -import java.util.LinkedHashSet; -import java.util.Locale; -import java.util.Map; +import java.util.*; Review Comment: *cringe* -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725124#comment-17725124 ] ASF GitHub Bot commented on MNG-7789: - slawekjaranowski commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1558021863 Plugin pom/descriptor dependencies can something else that is resolved by dependency collection and what finally is used to construct plugin class realm like: https://gist.github.com/slawekjaranowski/c65612fca4094ec8a2d09c6db3b8f78a > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] slawekjaranowski commented on pull request #1115: [MNG-7789] Dependency validation rules used wrong data
slawekjaranowski commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1558021863 Plugin pom/descriptor dependencies can something else that is resolved by dependency collection and what finally is used to construct plugin class realm like: https://gist.github.com/slawekjaranowski/c65612fca4094ec8a2d09c6db3b8f78a -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
[ https://issues.apache.org/jira/browse/MDEP-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725116#comment-17725116 ] ASF GitHub Bot commented on MDEP-799: - MartinWitt opened a new pull request, #325: URL: https://github.com/apache/maven-dependency-plugin/pull/325 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MDEP) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. I will squash and update the commit in the end. There is still open discussion. - [X] Format the pull request title like `[MDEP-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MDEP-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). - [X] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). I sent the mail for this a few minutes ago so it should be signed soon. I tried to understand the way you write unit/integration tests but it looks a bit complicated. What is the correct way to add a testcase? Best case, I can add a pom and check if the model written as json -> read by any JSON parser is equal to the model before. > improve mvn dependency:tree - add optional JSON output of the results > - > > Key: MDEP-799 > URL: https://issues.apache.org/jira/browse/MDEP-799 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Zhenxu Ke >Priority: Major > > I'd like to add an output type JSON, will open a pull request soon -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] MartinWitt opened a new pull request, #325: WIP: [MDEP-799] tree: add optional output type json
MartinWitt opened a new pull request, #325: URL: https://github.com/apache/maven-dependency-plugin/pull/325 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MDEP) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. I will squash and update the commit in the end. There is still open discussion. - [X] Format the pull request title like `[MDEP-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MDEP-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). - [X] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). I sent the mail for this a few minutes ago so it should be signed soon. I tried to understand the way you write unit/integration tests but it looks a bit complicated. What is the correct way to add a testcase? Best case, I can add a pom and check if the model written as json -> read by any JSON parser is equal to the model before. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725110#comment-17725110 ] ASF GitHub Bot commented on MNG-7789: - cstamas commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557880119 Will do that tomorrow, agreed. > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #1115: [MNG-7789] Dependency validation rules used wrong data
cstamas commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557880119 Will do that tomorrow, agreed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] dependabot[bot] opened a new pull request, #287: Bump hazelcast from 5.1.4 to 5.3.0 in /maven-resolver-named-locks-hazelcast
dependabot[bot] opened a new pull request, #287: URL: https://github.com/apache/maven-resolver/pull/287 Bumps [hazelcast](https://github.com/hazelcast/hazelcast) from 5.1.4 to 5.3.0. Release notes Sourced from https://github.com/hazelcast/hazelcast/releases;>hazelcast's releases. v5.3.0 This document lists the new features, enhancements, fixed issues and, removed or deprecated features for Hazelcast Platform 5.3.0 release. The numbers in the square brackets refer to the issues and pull requests in Hazelcast's GitHub repository. New Features Connector for Kafka Connect source (BETA): Import data from an external system directly into a Hazelcast data pipeline without the need of a Kafka cluster. Connector for MongoDB (BETA): Read and write from/to MongoDB via this connector and execute SQL queries on Mongo collections directly from Hazelcast. Partition-Aware SQL Client: Send the SQL commands only to the members having the relevant data, which reduces the network hops and improves the query performances. Data connection support in SQL: data connections and mappings using them can be managed using SQL commands. Breaking Changes Renamed the DataLinkFactory interface as DataConnection. https://redirect.github.com/hazelcast/hazelcast/issues/24224;>#24224 Removed the TO_ROW function as it is obsolete, you can use CAST (udtObj AS JSON) instead. https://redirect.github.com/hazelcast/hazelcast/issues/23808;>#23808 SQL mappings for internal maps (__sql.catalog and __jet.*) cannot be created anymore. https://redirect.github.com/hazelcast/hazelcast/issues/24282;>#24282 Changed the default cloud coordinator URL from coordinator.hazelcast.cloud to api.viridian.hazelcast.com. The default configuration now connects to https://viridian.hazelcast.com/sign-in?next=/;>https://viridian.hazelcast.com/sign-in?next=/ instead of Hazelcast Cloud. If you want to continue accessing your Hazelcast Cloud clusters, you need to set the hazelcast.client.cloud.url property to https://coordinator.hazelcast.cloud in your configuration. https://redirect.github.com/hazelcast/hazelcast/issues/23290;>#23290 Enhancements Cloud Hazelcast was sending requests to Kubernetes API when deploying an application with embedded Hazelcast and service-dns (DNS lookup mode) specified to a Kubernetes cluster. This was causing the requests to be unsuccessful and the application not to start. This mechanism has been improved by creating Kubernetes client only for the DNS lookup mode. https://redirect.github.com/hazelcast/hazelcast/issues/23883;>#23883 When advanced networking is enabled, the Kubernetes discovery plugin might have been discovering several endpoints (per each port) for each member's pod. The discovery plugin now matches only the private IP per endpoint, ignoring the port values. https://redirect.github.com/hazelcast/hazelcast/issues/23766;>#23766 Added support of link:https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-support-instance-metadata-service-version-2-default/#:~:text=Posted%20On%3A%20Oct%203%2C%202022,depth%20against%20unauthorized%20metadata%20access.%5BIMDSv2%5E%5D;>https://aws.amazon.com/about-aws/whats-new/2022/10/amazon-machine-images-support-instance-metadata-service-version-2-default/#:~:text=Posted%20On%3A%20Oct%203%2C%202022,depth%20against%20unauthorized%20metadata%20access.[IMDSv2^] for Hazelcast's AWS Discovery plugin. https://redirect.github.com/hazelcast/hazelcast/issues/23545;>#23545 Added the support of discovering ECS and EC2 members on AWS. See xref:deploy:deploying-on-aws.adoc[Deploying a Cluster on Amazon AWS]. https://redirect.github.com/hazelcast/hazelcast/issues/22411;>#22411 Storage Added support of generating suggested Data Definition Language (DDL) for a map with High-Density Memory Store and having no indexes. https://redirect.github.com/hazelcast/hazelcast/issues/24054;>#24054 Disk tier option of Tiered Storage is now disabled by default. https://redirect.github.com/hazelcast/hazelcast/issues/23747;>#23747 NOTE: Tiered Storage feature is still in BETA stage. Distribution Hazelcast no longer depends on JRuby; the JRuby ScriptFactory dependency must be explicitly added to the application. https://redirect.github.com/hazelcast/hazelcast/issues/23355;>#23355 Added the Kafka Connect extension to the distribution. https://redirect.github.com/hazelcast/hazelcast/issues/23312;>#23312 Shaded dependencies for Hazelcast Platform have been combined in a dedicated package (com.hazelcast.shaded). https://redirect.github.com/hazelcast/hazelcast/issues/23124;>#23124 Networking Added socket options for per-socket keep-alive configuration: keep-count, keep-idle-seconds, and keep-interval-seconds. You can set these options using either the advanced network configurations or Hazelcast system properties. See
[jira] [Commented] (MNG-7740) Target directory is flooded with consumer*pom files
[ https://issues.apache.org/jira/browse/MNG-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725098#comment-17725098 ] ASF GitHub Bot commented on MNG-7740: - gnodet commented on code in PR #1117: URL: https://github.com/apache/maven/pull/1117#discussion_r1200954771 ## maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java: ## @@ -77,13 +82,29 @@ public void injectTransformedArtifacts(MavenProject project, RepositorySystemSes Files.createDirectories(buildDir); generatedFile = Files.createTempFile(buildDir, CONSUMER_POM_CLASSIFIER, "pom"); } +deferDeleteFile(generatedFile); project.addAttachedArtifact(new ConsumerPomArtifact(project, generatedFile, session)); } else if (project.getModel().isRoot()) { throw new IllegalStateException( "The use of the root attribute on the model requires the buildconsumer feature to be active"); } } +private void deferDeleteFile(Path generatedFile) { +toDelete.add(generatedFile.toAbsolutePath().toString()); Review Comment: I didn't want to hold references to the objects such as the `FileSystem`, I've modelled it to be in line with the `File#deleteOnExit` implementation of openjdk which was using `String` instead of `File`. But I don't foresee any real problem keeping references to `Path`, provided that we do use the `toAbsolutePath()`. > Target directory is flooded with consumer*pom files > --- > > Key: MNG-7740 > URL: https://issues.apache.org/jira/browse/MNG-7740 > Project: Maven > Issue Type: Improvement > Components: build/consumer, Core >Affects Versions: 4.0.0-alpha-4 > Environment: Apache Maven 4.0.0-alpha-4 > (009cf4a7213aead8a7946a2397e2396c5927f30f) > Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4 > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > Default locale: en_NL, platform encoding: UTF-8 > OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac" >Reporter: Maarten Mulders >Priority: Minor > Labels: up-for-grabs > > After invoking Mavens {{validate}} or later lifecycle phase, there is a > *consumerXXXpom* file left in the build directory. Here, XXX is a bunch of > numbers. > It is not harmful, but I dislike the fact that for every invocation of Maven, > the file gets generated again and again. This can quickly lead to tens of > files that are never used again anymore. I feel we should clean those files > when we're done using them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1117: [MNG-7740] Remove old temporary consumer*pom files from buildDir
gnodet commented on code in PR #1117: URL: https://github.com/apache/maven/pull/1117#discussion_r1200954771 ## maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java: ## @@ -77,13 +82,29 @@ public void injectTransformedArtifacts(MavenProject project, RepositorySystemSes Files.createDirectories(buildDir); generatedFile = Files.createTempFile(buildDir, CONSUMER_POM_CLASSIFIER, "pom"); } +deferDeleteFile(generatedFile); project.addAttachedArtifact(new ConsumerPomArtifact(project, generatedFile, session)); } else if (project.getModel().isRoot()) { throw new IllegalStateException( "The use of the root attribute on the model requires the buildconsumer feature to be active"); } } +private void deferDeleteFile(Path generatedFile) { +toDelete.add(generatedFile.toAbsolutePath().toString()); Review Comment: I didn't want to hold references to the objects such as the `FileSystem`, I've modelled it to be in line with the `File#deleteOnExit` implementation of openjdk which was using `String` instead of `File`. But I don't foresee any real problem keeping references to `Path`, provided that we do use the `toAbsolutePath()`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7740) Target directory is flooded with consumer*pom files
[ https://issues.apache.org/jira/browse/MNG-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725092#comment-17725092 ] ASF GitHub Bot commented on MNG-7740: - gnodet commented on code in PR #1117: URL: https://github.com/apache/maven/pull/1117#discussion_r1200954771 ## maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java: ## @@ -77,13 +82,29 @@ public void injectTransformedArtifacts(MavenProject project, RepositorySystemSes Files.createDirectories(buildDir); generatedFile = Files.createTempFile(buildDir, CONSUMER_POM_CLASSIFIER, "pom"); } +deferDeleteFile(generatedFile); project.addAttachedArtifact(new ConsumerPomArtifact(project, generatedFile, session)); } else if (project.getModel().isRoot()) { throw new IllegalStateException( "The use of the root attribute on the model requires the buildconsumer feature to be active"); } } +private void deferDeleteFile(Path generatedFile) { +toDelete.add(generatedFile.toAbsolutePath().toString()); Review Comment: I didn't want to hold references to the objects such as the `FileSystem`, I've modelled it to be in line with the `File#deleteOnExit` implementation of openjdk which was using `String` instead of `File` to keep those. But I don't foresee any real problem keeping references to `Path`, provided that we do use the `toAbsolutePath()`. > Target directory is flooded with consumer*pom files > --- > > Key: MNG-7740 > URL: https://issues.apache.org/jira/browse/MNG-7740 > Project: Maven > Issue Type: Improvement > Components: build/consumer, Core >Affects Versions: 4.0.0-alpha-4 > Environment: Apache Maven 4.0.0-alpha-4 > (009cf4a7213aead8a7946a2397e2396c5927f30f) > Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4 > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > Default locale: en_NL, platform encoding: UTF-8 > OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac" >Reporter: Maarten Mulders >Priority: Minor > Labels: up-for-grabs > > After invoking Mavens {{validate}} or later lifecycle phase, there is a > *consumerXXXpom* file left in the build directory. Here, XXX is a bunch of > numbers. > It is not harmful, but I dislike the fact that for every invocation of Maven, > the file gets generated again and again. This can quickly lead to tens of > files that are never used again anymore. I feel we should clean those files > when we're done using them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1117: [MNG-7740] Remove old temporary consumer*pom files from buildDir
gnodet commented on code in PR #1117: URL: https://github.com/apache/maven/pull/1117#discussion_r1200954771 ## maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java: ## @@ -77,13 +82,29 @@ public void injectTransformedArtifacts(MavenProject project, RepositorySystemSes Files.createDirectories(buildDir); generatedFile = Files.createTempFile(buildDir, CONSUMER_POM_CLASSIFIER, "pom"); } +deferDeleteFile(generatedFile); project.addAttachedArtifact(new ConsumerPomArtifact(project, generatedFile, session)); } else if (project.getModel().isRoot()) { throw new IllegalStateException( "The use of the root attribute on the model requires the buildconsumer feature to be active"); } } +private void deferDeleteFile(Path generatedFile) { +toDelete.add(generatedFile.toAbsolutePath().toString()); Review Comment: I didn't want to hold references to the objects such as the `FileSystem`, I've modelled it to be in line with the `File#deleteOnExit` implementation of openjdk which was using `String` instead of `File` to keep those. But I don't foresee any real problem keeping references to `Path`, provided that we do use the `toAbsolutePath()`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ardalangh commented on issue #704: Usage of mvnd on Jenkins for parallel builds
ardalangh commented on issue #704: URL: https://github.com/apache/maven-mvnd/issues/704#issuecomment-1557823786 @ppalaga @OLibutzki Hi, apologies for the unrelated question. Can maven-mvnd be utilized for a Jenkins build where all maven builds are executed in containers that are killed upon build completion? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7780) DefaultArtifact.equals throws NullPointerException if o.version is null
[ https://issues.apache.org/jira/browse/MNG-7780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725087#comment-17725087 ] ASF GitHub Bot commented on MNG-7780: - gnodet merged PR #1108: URL: https://github.com/apache/maven/pull/1108 > DefaultArtifact.equals throws NullPointerException if o.version is null > --- > > Key: MNG-7780 > URL: https://issues.apache.org/jira/browse/MNG-7780 > Project: Maven > Issue Type: Bug >Affects Versions: 3.9.1, 4.0.0-alpha-5 >Reporter: Tobias Gruetzmacher >Priority: Major > > DefaultArtifact.validateIdentity() only throws if BOTH version and > versionRange are null, so it's possible to create an instance of > DefaultArtifact where version == null. If such an instance ever ends up in > DefaultArtifact.equals(o), the check {{a.getVersion().equals(version)}} will > throw a NullPointerException. > (This was observed while debugging an issue in versions-maven-plugin) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet merged pull request #1108: [MNG-7780] DefaultArtifact.equals throws NullPointerException if o.version is null
gnodet merged PR #1108: URL: https://github.com/apache/maven/pull/1108 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7740) Target directory is flooded with consumer*pom files
[ https://issues.apache.org/jira/browse/MNG-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725086#comment-17725086 ] ASF GitHub Bot commented on MNG-7740: - michael-o commented on code in PR #1117: URL: https://github.com/apache/maven/pull/1117#discussion_r1200938258 ## maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java: ## @@ -77,13 +82,29 @@ public void injectTransformedArtifacts(MavenProject project, RepositorySystemSes Files.createDirectories(buildDir); generatedFile = Files.createTempFile(buildDir, CONSUMER_POM_CLASSIFIER, "pom"); } +deferDeleteFile(generatedFile); project.addAttachedArtifact(new ConsumerPomArtifact(project, generatedFile, session)); } else if (project.getModel().isRoot()) { throw new IllegalStateException( "The use of the root attribute on the model requires the buildconsumer feature to be active"); } } +private void deferDeleteFile(Path generatedFile) { +toDelete.add(generatedFile.toAbsolutePath().toString()); Review Comment: Why not retain `Path`? > Target directory is flooded with consumer*pom files > --- > > Key: MNG-7740 > URL: https://issues.apache.org/jira/browse/MNG-7740 > Project: Maven > Issue Type: Improvement > Components: build/consumer, Core >Affects Versions: 4.0.0-alpha-4 > Environment: Apache Maven 4.0.0-alpha-4 > (009cf4a7213aead8a7946a2397e2396c5927f30f) > Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4 > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > Default locale: en_NL, platform encoding: UTF-8 > OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac" >Reporter: Maarten Mulders >Priority: Minor > Labels: up-for-grabs > > After invoking Mavens {{validate}} or later lifecycle phase, there is a > *consumerXXXpom* file left in the build directory. Here, XXX is a bunch of > numbers. > It is not harmful, but I dislike the fact that for every invocation of Maven, > the file gets generated again and again. This can quickly lead to tens of > files that are never used again anymore. I feel we should clean those files > when we're done using them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #1117: [MNG-7740] Remove old temporary consumer*pom files from buildDir
michael-o commented on code in PR #1117: URL: https://github.com/apache/maven/pull/1117#discussion_r1200938258 ## maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java: ## @@ -77,13 +82,29 @@ public void injectTransformedArtifacts(MavenProject project, RepositorySystemSes Files.createDirectories(buildDir); generatedFile = Files.createTempFile(buildDir, CONSUMER_POM_CLASSIFIER, "pom"); } +deferDeleteFile(generatedFile); project.addAttachedArtifact(new ConsumerPomArtifact(project, generatedFile, session)); } else if (project.getModel().isRoot()) { throw new IllegalStateException( "The use of the root attribute on the model requires the buildconsumer feature to be active"); } } +private void deferDeleteFile(Path generatedFile) { +toDelete.add(generatedFile.toAbsolutePath().toString()); Review Comment: Why not retain `Path`? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7740) Target directory is flooded with consumer*pom files
[ https://issues.apache.org/jira/browse/MNG-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725085#comment-17725085 ] ASF GitHub Bot commented on MNG-7740: - gnodet closed pull request #1105: [MNG-7740] Remove old temporary consumer*pom files from buildDir URL: https://github.com/apache/maven/pull/1105 > Target directory is flooded with consumer*pom files > --- > > Key: MNG-7740 > URL: https://issues.apache.org/jira/browse/MNG-7740 > Project: Maven > Issue Type: Improvement > Components: build/consumer, Core >Affects Versions: 4.0.0-alpha-4 > Environment: Apache Maven 4.0.0-alpha-4 > (009cf4a7213aead8a7946a2397e2396c5927f30f) > Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4 > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > Default locale: en_NL, platform encoding: UTF-8 > OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac" >Reporter: Maarten Mulders >Priority: Minor > Labels: up-for-grabs > > After invoking Mavens {{validate}} or later lifecycle phase, there is a > *consumerXXXpom* file left in the build directory. Here, XXX is a bunch of > numbers. > It is not harmful, but I dislike the fact that for every invocation of Maven, > the file gets generated again and again. This can quickly lead to tens of > files that are never used again anymore. I feel we should clean those files > when we're done using them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7740) Target directory is flooded with consumer*pom files
[ https://issues.apache.org/jira/browse/MNG-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725084#comment-17725084 ] ASF GitHub Bot commented on MNG-7740: - gnodet commented on PR #1105: URL: https://github.com/apache/maven/pull/1105#issuecomment-1557791393 Closing this PR in favour of #1117 > Target directory is flooded with consumer*pom files > --- > > Key: MNG-7740 > URL: https://issues.apache.org/jira/browse/MNG-7740 > Project: Maven > Issue Type: Improvement > Components: build/consumer, Core >Affects Versions: 4.0.0-alpha-4 > Environment: Apache Maven 4.0.0-alpha-4 > (009cf4a7213aead8a7946a2397e2396c5927f30f) > Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4 > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > Default locale: en_NL, platform encoding: UTF-8 > OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac" >Reporter: Maarten Mulders >Priority: Minor > Labels: up-for-grabs > > After invoking Mavens {{validate}} or later lifecycle phase, there is a > *consumerXXXpom* file left in the build directory. Here, XXX is a bunch of > numbers. > It is not harmful, but I dislike the fact that for every invocation of Maven, > the file gets generated again and again. This can quickly lead to tens of > files that are never used again anymore. I feel we should clean those files > when we're done using them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet closed pull request #1105: [MNG-7740] Remove old temporary consumer*pom files from buildDir
gnodet closed pull request #1105: [MNG-7740] Remove old temporary consumer*pom files from buildDir URL: https://github.com/apache/maven/pull/1105 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] gnodet commented on pull request #1105: [MNG-7740] Remove old temporary consumer*pom files from buildDir
gnodet commented on PR #1105: URL: https://github.com/apache/maven/pull/1105#issuecomment-1557791393 Closing this PR in favour of #1117 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7740) Target directory is flooded with consumer*pom files
[ https://issues.apache.org/jira/browse/MNG-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725082#comment-17725082 ] ASF GitHub Bot commented on MNG-7740: - gnodet opened a new pull request, #1117: URL: https://github.com/apache/maven/pull/1117 Supersedes #1105 > Target directory is flooded with consumer*pom files > --- > > Key: MNG-7740 > URL: https://issues.apache.org/jira/browse/MNG-7740 > Project: Maven > Issue Type: Improvement > Components: build/consumer, Core >Affects Versions: 4.0.0-alpha-4 > Environment: Apache Maven 4.0.0-alpha-4 > (009cf4a7213aead8a7946a2397e2396c5927f30f) > Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4 > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > Default locale: en_NL, platform encoding: UTF-8 > OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac" >Reporter: Maarten Mulders >Priority: Minor > Labels: up-for-grabs > > After invoking Mavens {{validate}} or later lifecycle phase, there is a > *consumerXXXpom* file left in the build directory. Here, XXX is a bunch of > numbers. > It is not harmful, but I dislike the fact that for every invocation of Maven, > the file gets generated again and again. This can quickly lead to tens of > files that are never used again anymore. I feel we should clean those files > when we're done using them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7740) Target directory is flooded with consumer*pom files
[ https://issues.apache.org/jira/browse/MNG-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725081#comment-17725081 ] ASF GitHub Bot commented on MNG-7740: - gnodet commented on code in PR #1105: URL: https://github.com/apache/maven/pull/1105#discussion_r1200930937 ## maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java: ## @@ -77,13 +80,34 @@ public void injectTransformedArtifacts(MavenProject project, RepositorySystemSes Files.createDirectories(buildDir); generatedFile = Files.createTempFile(buildDir, CONSUMER_POM_CLASSIFIER, "pom"); } + +removeOldConsumerPomFiles(generatedFile); Review Comment: > > @Giovds have a look at [gnodet@11009e9](https://github.com/gnodet/maven/commit/11009e9f6921657e31384bd9838d5ab1edb1aacc), could you double check that it works for you ? > > Cool, TIL! Just verified it and it does work for me. The files are cleaned up. > > Do note that the final result means there will be no consumer*pom file in the build dir whatsoever. I don't know if it was kept for a reason. Perhaps the file is/will be (re)used for build-consumer features beyond a single run? If it's not and it's a temp file, why not always use the temp dir e.g.? > > * Without to much research: * Seems like (in this class at least) the `CONSUMER_POM_CLASSIFIER` is private so not used by other classes and the build dir is never queried for the file, only in-memory artifact lists? Yes, I think it was written to disk because it was needed as a file and there was no easy way to delete it at the end of the process, but they're not supposed to outlive the session. > Target directory is flooded with consumer*pom files > --- > > Key: MNG-7740 > URL: https://issues.apache.org/jira/browse/MNG-7740 > Project: Maven > Issue Type: Improvement > Components: build/consumer, Core >Affects Versions: 4.0.0-alpha-4 > Environment: Apache Maven 4.0.0-alpha-4 > (009cf4a7213aead8a7946a2397e2396c5927f30f) > Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4 > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime: > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home > Default locale: en_NL, platform encoding: UTF-8 > OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac" >Reporter: Maarten Mulders >Priority: Minor > Labels: up-for-grabs > > After invoking Mavens {{validate}} or later lifecycle phase, there is a > *consumerXXXpom* file left in the build directory. Here, XXX is a bunch of > numbers. > It is not harmful, but I dislike the fact that for every invocation of Maven, > the file gets generated again and again. This can quickly lead to tens of > files that are never used again anymore. I feel we should clean those files > when we're done using them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1105: [MNG-7740] Remove old temporary consumer*pom files from buildDir
gnodet commented on code in PR #1105: URL: https://github.com/apache/maven/pull/1105#discussion_r1200930937 ## maven-core/src/main/java/org/apache/maven/internal/transformation/ConsumerPomArtifactTransformer.java: ## @@ -77,13 +80,34 @@ public void injectTransformedArtifacts(MavenProject project, RepositorySystemSes Files.createDirectories(buildDir); generatedFile = Files.createTempFile(buildDir, CONSUMER_POM_CLASSIFIER, "pom"); } + +removeOldConsumerPomFiles(generatedFile); Review Comment: > > @Giovds have a look at [gnodet@11009e9](https://github.com/gnodet/maven/commit/11009e9f6921657e31384bd9838d5ab1edb1aacc), could you double check that it works for you ? > > Cool, TIL! Just verified it and it does work for me. The files are cleaned up. > > Do note that the final result means there will be no consumer*pom file in the build dir whatsoever. I don't know if it was kept for a reason. Perhaps the file is/will be (re)used for build-consumer features beyond a single run? If it's not and it's a temp file, why not always use the temp dir e.g.? > > * Without to much research: * Seems like (in this class at least) the `CONSUMER_POM_CLASSIFIER` is private so not used by other classes and the build dir is never queried for the file, only in-memory artifact lists? Yes, I think it was written to disk because it was needed as a file and there was no easy way to delete it at the end of the process, but they're not supposed to outlive the session. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725079#comment-17725079 ] ASF GitHub Bot commented on MNG-7789: - gnodet commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557773421 > This PR does not add any check to it, it actually moves them off from it. One check remains, thay yes, may be killed off actually. Can we then delete the AbstractMavenPluginDescriptorDependenciesValidator and MavenArtifactsMavenPluginDescriptorDependenciesValidator classes which are new ? This would remove all usage of `PluginDescriptor#getDependencies()` from maven (apart from the `clone` and UTs). > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #1115: [MNG-7789] Dependency validation rules used wrong data
gnodet commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557773421 > This PR does not add any check to it, it actually moves them off from it. One check remains, thay yes, may be killed off actually. Can we then delete the AbstractMavenPluginDescriptorDependenciesValidator and MavenArtifactsMavenPluginDescriptorDependenciesValidator classes which are new ? This would remove all usage of `PluginDescriptor#getDependencies()` from maven (apart from the `clone` and UTs). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] michael-o opened a new pull request, #642: fix SAX bug
michael-o opened a new pull request, #642: URL: https://github.com/apache/maven-surefire/pull/642 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725077#comment-17725077 ] ASF GitHub Bot commented on MNG-7789: - cstamas commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557749704 This PR does not add any check to it, it actually moves them off from it. One check remains, thay yes, may be killed off actually. > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #1115: [MNG-7789] Dependency validation rules used wrong data
cstamas commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557749704 This PR does not add any check to it, it actually moves them off from it. One check remains, thay yes, may be killed off actually. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725076#comment-17725076 ] ASF GitHub Bot commented on MNG-7789: - gnodet commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557729532 > Today, descriptor/dependencies are not used anywhere (maybe in some UTs) in maven, the POM drives plugin dependencies. Hence the realization and this PR (it moves existing code to check POM originating deps). > The descriptor/deps is at (plugin) build time derived from POM, and as we saw, is affected by possible mpp bugs like that one in 3.6.2 Then, why checking those and add validation warnings ? Wouldn't it make sense to actually deprecate them, not generate them anymore with the next m-p-p plugins ? > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #1115: [MNG-7789] Dependency validation rules used wrong data
gnodet commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557729532 > Today, descriptor/dependencies are not used anywhere (maybe in some UTs) in maven, the POM drives plugin dependencies. Hence the realization and this PR (it moves existing code to check POM originating deps). > The descriptor/deps is at (plugin) build time derived from POM, and as we saw, is affected by possible mpp bugs like that one in 3.6.2 Then, why checking those and add validation warnings ? Wouldn't it make sense to actually deprecate them, not generate them anymore with the next m-p-p plugins ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725075#comment-17725075 ] ASF GitHub Bot commented on MNG-7789: - gnodet commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1200901478 ## maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java: ## @@ -46,6 +42,13 @@ @Singleton @Named public final class DefaultPluginValidationManager extends AbstractEventSpy implements PluginValidationManager { +/** + * The collection of "G:A" combinations that do NOT belong to Maven Core, hence, should be excluded from + * "expected in provided scope" type of checks. + */ +static final Collection EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA = +Collections.unmodifiableCollection(Arrays.asList( +"org.apache.maven:maven-archiver", "org.apache.maven:maven-jxr", "org.apache.maven:plexus-utils")); Review Comment: Yes, and this very artifact will not exist anymore in 4.0.0-m6, and that's why I asked the question. It does not exist in 3.9.x either. But afaik, you added a check on this artifact on https://github.com/apache/maven/commit/53b64732378fe27a91cb66dad5693d6d0c71628a#diff-95336d0fc4e39e625e90137247157a9d73ed8094dfb4e3431b589a9d94c3dedeR38 Do you recall for which use case you added this check ? > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1115: [MNG-7789] Dependency validation rules used wrong data
gnodet commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1200901478 ## maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java: ## @@ -46,6 +42,13 @@ @Singleton @Named public final class DefaultPluginValidationManager extends AbstractEventSpy implements PluginValidationManager { +/** + * The collection of "G:A" combinations that do NOT belong to Maven Core, hence, should be excluded from + * "expected in provided scope" type of checks. + */ +static final Collection EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA = +Collections.unmodifiableCollection(Arrays.asList( +"org.apache.maven:maven-archiver", "org.apache.maven:maven-jxr", "org.apache.maven:plexus-utils")); Review Comment: Yes, and this very artifact will not exist anymore in 4.0.0-m6, and that's why I asked the question. It does not exist in 3.9.x either. But afaik, you added a check on this artifact on https://github.com/apache/maven/commit/53b64732378fe27a91cb66dad5693d6d0c71628a#diff-95336d0fc4e39e625e90137247157a9d73ed8094dfb4e3431b589a9d94c3dedeR38 Do you recall for which use case you added this check ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725072#comment-17725072 ] ASF GitHub Bot commented on MNG-7789: - cstamas commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557705730 Today, descriptor/dependencies are not used anywhere (maybe in some UTs) in maven, the POM drives plugin dependencies. Hence the realization and this PR (it moves existing code to check POM originating deps). The descriptor/deps is at (plugin) build time derived from POM, and as we saw, is affected by possible mpp bugs like that one in 3.6.2 > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #1115: [MNG-7789] Dependency validation rules used wrong data
cstamas commented on PR #1115: URL: https://github.com/apache/maven/pull/1115#issuecomment-1557705730 Today, descriptor/dependencies are not used anywhere (maybe in some UTs) in maven, the POM drives plugin dependencies. Hence the realization and this PR (it moves existing code to check POM originating deps). The descriptor/deps is at (plugin) build time derived from POM, and as we saw, is affected by possible mpp bugs like that one in 3.6.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. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725070#comment-17725070 ] ASF GitHub Bot commented on MNG-7789: - cstamas commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1200887062 ## maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java: ## @@ -46,6 +42,13 @@ @Singleton @Named public final class DefaultPluginValidationManager extends AbstractEventSpy implements PluginValidationManager { +/** + * The collection of "G:A" combinations that do NOT belong to Maven Core, hence, should be excluded from + * "expected in provided scope" type of checks. + */ +static final Collection EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA = +Collections.unmodifiableCollection(Arrays.asList( +"org.apache.maven:maven-archiver", "org.apache.maven:maven-jxr", "org.apache.maven:plexus-utils")); Review Comment: You tell me https://repo.maven.apache.org/maven2/org/apache/maven/plexus-utils/ > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas commented on a diff in pull request #1115: [MNG-7789] Dependency validation rules used wrong data
cstamas commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1200887062 ## maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java: ## @@ -46,6 +42,13 @@ @Singleton @Named public final class DefaultPluginValidationManager extends AbstractEventSpy implements PluginValidationManager { +/** + * The collection of "G:A" combinations that do NOT belong to Maven Core, hence, should be excluded from + * "expected in provided scope" type of checks. + */ +static final Collection EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA = +Collections.unmodifiableCollection(Arrays.asList( +"org.apache.maven:maven-archiver", "org.apache.maven:maven-jxr", "org.apache.maven:plexus-utils")); Review Comment: You tell me https://repo.maven.apache.org/maven2/org/apache/maven/plexus-utils/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725068#comment-17725068 ] ASF GitHub Bot commented on MNG-7789: - gnodet commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1200735153 ## maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java: ## @@ -46,6 +42,13 @@ @Singleton @Named public final class DefaultPluginValidationManager extends AbstractEventSpy implements PluginValidationManager { +/** + * The collection of "G:A" combinations that do NOT belong to Maven Core, hence, should be excluded from + * "expected in provided scope" type of checks. + */ +static final Collection EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA = +Collections.unmodifiableCollection(Arrays.asList( +"org.apache.maven:maven-archiver", "org.apache.maven:maven-jxr", "org.apache.maven:plexus-utils")); Review Comment: I know those values have not changed, but is the `org.apache.maven` groupId expected for `plexus-utils` ? > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7714) sp < final
[ https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725067#comment-17725067 ] ASF GitHub Bot commented on MNG-7714: - elharo commented on code in PR #1099: URL: https://github.com/apache/maven/pull/1099#discussion_r1200872369 ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -422,6 +436,106 @@ public String toString() { } } +/** + * Represents a combination in the version item list. + * It is usually a combination of a string and a number, with the string first and the number second + */ +private static class CombinationItem implements Item { + +StringItem stringValue; + +Item digitValue; + +CombinationItem(String v) { Review Comment: or version? ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -422,6 +436,106 @@ public String toString() { } } +/** + * Represents a combination in the version item list. + * It is usually a combination of a string and a number, with the string first and the number second + */ +private static class CombinationItem implements Item { + +StringItem stringValue; + +Item digitValue; + +CombinationItem(String v) { +int index = 0; +for (int i = 0; i < v.length(); i++) { +char c = v.charAt(i); +if (Character.isDigit(c)) { Review Comment: Please elaborate with reference to the docs. I don't think non-ASCII digits are included in maven's version comparison algorithm. Though now that I look at it I don't think we say that: https://maven.apache.org/pom.html We should probably bring this up on the dev mailing list to see if there are any unexpected consequences here of non-ASCII digits. ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -199,6 +202,7 @@ public int compareTo(Item item) { return -1; case STRING_ITEM: +case COMBINATION_ITEM: Review Comment: I don't see the change. Perhaps you need to push the branch. ## maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java: ## @@ -147,10 +154,10 @@ void testVersionsEqual() { checkVersionsEqual("1.0.0x", "1-x"); // aliases -checkVersionsEqual("1ga", "1"); -checkVersionsEqual("1release", "1"); -checkVersionsEqual("1final", "1"); -checkVersionsEqual("1cr", "1rc"); +checkVersionsEqualOrder("1ga", "1"); Review Comment: still easier to follow if you add new tests without changing the existing test methods. > sp < final > -- > > Key: MNG-7714 > URL: https://issues.apache.org/jira/browse/MNG-7714 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: 4.0.0-alpha-6 > > > Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701 > The claim is that sp < final, which if true is incorrect according to spec. > It is easy to demonstrate that this is not fixed and also not in line with > the spec, with just this one important example (yes this does break for us): > $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001 > 1.0.sp1-redhat-0001 > Display parameters as parsed by Maven (in canonical form and as a list of > tokens) and comparison result: > 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]] >1.0.final-redhat-0001 < 1.0.sp1-redhat-0001 > 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat, > [1 > versus > $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001 > 1.0.sp1-redhat-0001 > Display parameters as parsed by Maven (in canonical form and as a list of > tokens) and comparison result: > 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]] >1.0.final-redhat-0001 > 1.0.sp1-redhat-0001 > 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat, > [1] > As you can see, our `sp` release is now ordered after our `final` release > despite this clear text in the "spec": > Non-numeric tokens ("qualifiers") have the alphabetical order, except for > the following tokens which come first in this order: "alpha" < "beta" < > "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp" > It's clear that this tokenization isn't really correct by any reasonable > measurement, and breaking large amounts of (our) existing artifacts in the > wild is definitely not OK. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1115: [MNG-7789] Dependency validation rules used wrong data
gnodet commented on code in PR #1115: URL: https://github.com/apache/maven/pull/1115#discussion_r1200735153 ## maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginValidationManager.java: ## @@ -46,6 +42,13 @@ @Singleton @Named public final class DefaultPluginValidationManager extends AbstractEventSpy implements PluginValidationManager { +/** + * The collection of "G:A" combinations that do NOT belong to Maven Core, hence, should be excluded from + * "expected in provided scope" type of checks. + */ +static final Collection EXPECTED_PROVIDED_SCOPE_EXCLUSIONS_GA = +Collections.unmodifiableCollection(Arrays.asList( +"org.apache.maven:maven-archiver", "org.apache.maven:maven-jxr", "org.apache.maven:plexus-utils")); Review Comment: I know those values have not changed, but is the `org.apache.maven` groupId expected for `plexus-utils` ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] elharo commented on a diff in pull request #1099: [MNG-7714] Fixed a scenario in version sorting where sp1 is less than final
elharo commented on code in PR #1099: URL: https://github.com/apache/maven/pull/1099#discussion_r1200872369 ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -422,6 +436,106 @@ public String toString() { } } +/** + * Represents a combination in the version item list. + * It is usually a combination of a string and a number, with the string first and the number second + */ +private static class CombinationItem implements Item { + +StringItem stringValue; + +Item digitValue; + +CombinationItem(String v) { Review Comment: or version? ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -422,6 +436,106 @@ public String toString() { } } +/** + * Represents a combination in the version item list. + * It is usually a combination of a string and a number, with the string first and the number second + */ +private static class CombinationItem implements Item { + +StringItem stringValue; + +Item digitValue; + +CombinationItem(String v) { +int index = 0; +for (int i = 0; i < v.length(); i++) { +char c = v.charAt(i); +if (Character.isDigit(c)) { Review Comment: Please elaborate with reference to the docs. I don't think non-ASCII digits are included in maven's version comparison algorithm. Though now that I look at it I don't think we say that: https://maven.apache.org/pom.html We should probably bring this up on the dev mailing list to see if there are any unexpected consequences here of non-ASCII digits. ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -199,6 +202,7 @@ public int compareTo(Item item) { return -1; case STRING_ITEM: +case COMBINATION_ITEM: Review Comment: I don't see the change. Perhaps you need to push the branch. ## maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java: ## @@ -147,10 +154,10 @@ void testVersionsEqual() { checkVersionsEqual("1.0.0x", "1-x"); // aliases -checkVersionsEqual("1ga", "1"); -checkVersionsEqual("1release", "1"); -checkVersionsEqual("1final", "1"); -checkVersionsEqual("1cr", "1rc"); +checkVersionsEqualOrder("1ga", "1"); Review Comment: still easier to follow if you add new tests without changing the existing test methods. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
[ https://issues.apache.org/jira/browse/MDEP-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725064#comment-17725064 ] ASF GitHub Bot commented on MDEP-799: - michael-o commented on PR #207: URL: https://github.com/apache/maven-dependency-plugin/pull/207#issuecomment-1557684971 > I strongly prefer no extra dependencies for this. JSON libraries in particular are a world of security bugs, unmaintained code, violations of Java conventions, and overall poor design. For JSON output, writing strings is straight-forward. A library shouldn't be necessary to implement this. > > Possibly tests (and only tests) might want to parse the JSON, and for that a library would be helpful. Do not use Jackson. javax.json or perhaps GSON might be OK. GSON is superseded already. > improve mvn dependency:tree - add optional JSON output of the results > - > > Key: MDEP-799 > URL: https://issues.apache.org/jira/browse/MDEP-799 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Zhenxu Ke >Priority: Major > > I'd like to add an output type JSON, will open a pull request soon -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
[ https://issues.apache.org/jira/browse/MDEP-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725061#comment-17725061 ] ASF GitHub Bot commented on MDEP-799: - elharo commented on PR #207: URL: https://github.com/apache/maven-dependency-plugin/pull/207#issuecomment-1557681374 I strongly prefer no extra dependencies for this. JSON libraries in particular are a world of security bugs, unmaintained code, violations of Java conventions, and overall poor design. For JSON output, writing strings is straight-forward. A library shouldn't be necessary to implement this. Possibly tests (and only tests) might want to parse the JSON, and for that a library would be helpful. Do not use Jackson. javax.json or perhaps GSON might be OK. > improve mvn dependency:tree - add optional JSON output of the results > - > > Key: MDEP-799 > URL: https://issues.apache.org/jira/browse/MDEP-799 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Zhenxu Ke >Priority: Major > > I'd like to add an output type JSON, will open a pull request soon -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
[ https://issues.apache.org/jira/browse/MDEP-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725048#comment-17725048 ] ASF GitHub Bot commented on MDEP-799: - MartinWitt commented on PR #207: URL: https://github.com/apache/maven-dependency-plugin/pull/207#issuecomment-1557614971 Hey, as this PR seems stale, and I want this feature, I would implement this in a new PR. Do you prefer to use a JSON library, which one do you like, or shall I write a JSON printer myself? > improve mvn dependency:tree - add optional JSON output of the results > - > > Key: MDEP-799 > URL: https://issues.apache.org/jira/browse/MDEP-799 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Zhenxu Ke >Priority: Major > > I'd like to add an output type JSON, will open a pull request soon -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] MartinWitt commented on pull request #207: [MDEP-799] - improve dependency:tree to add optional JSON output of the results
MartinWitt commented on PR #207: URL: https://github.com/apache/maven-dependency-plugin/pull/207#issuecomment-1557614971 Hey, as this PR seems stale, and I want this feature, I would implement this in a new PR. Do you prefer to use a JSON library, which one do you like, or shall I write a JSON printer myself? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MENFORCER-426) DependencyConvergence in 3.1.0 fails when using version ranges
[ https://issues.apache.org/jira/browse/MENFORCER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MENFORCER-426. - Fix Version/s: next-release Resolution: Fixed I close as we can not do more in plugin, by the way issue was fixed in Maven 3.9.2 > DependencyConvergence in 3.1.0 fails when using version ranges > -- > > Key: MENFORCER-426 > URL: https://issues.apache.org/jira/browse/MENFORCER-426 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: dependencyConvergence, Standard Rules >Affects Versions: 3.0.0, 3.1.0 >Reporter: Joe Barnett >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: next-release > > > In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's > DependencyConvergence rule passes. Using version 3.1.0 starts to show > convergence errors that I believe may be related to using version ranges to > declare dependencies: > {code:java} > [WARNING] > Dependency convergence error for com.trib3:graphql:jar:1.32.3279:compile > paths to dependency are: > +-com.joe.quizzy:server:jar:1.0-SNAPSHOT > +-com.joe.quizzy:graphql:jar:1.0-SNAPSHOT:compile > +-com.trib3:graphql:jar:1.32.3279:compile > and > +-com.joe.quizzy:server:jar:1.0-SNAPSHOT > +-com.trib3:graphql:jar:1.32.3324:compile > {code} > both {{com.joe.quizzy:server}} and {{com.joe.quizzy:graphql}} declare a > dependency on {{com.trib3:graphql}}, with a version of > {{[1.32.1,1.33-SNAPSHOT)}}. that version range should (currently) resolve to > 1.32.3324 in both usages, but in enforcer 3.1.0's DependencyConvergence check > does not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-426) DependencyConvergence in 3.1.0 fails when using version ranges
[ https://issues.apache.org/jira/browse/MENFORCER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725043#comment-17725043 ] ASF GitHub Bot commented on MENFORCER-426: -- slawekjaranowski merged PR #259: URL: https://github.com/apache/maven-enforcer/pull/259 > DependencyConvergence in 3.1.0 fails when using version ranges > -- > > Key: MENFORCER-426 > URL: https://issues.apache.org/jira/browse/MENFORCER-426 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: dependencyConvergence, Standard Rules >Affects Versions: 3.0.0, 3.1.0 >Reporter: Joe Barnett >Assignee: Slawomir Jaranowski >Priority: Major > > In our project, using version 3.0.0-M3 of the maven-enforcer-plugin's > DependencyConvergence rule passes. Using version 3.1.0 starts to show > convergence errors that I believe may be related to using version ranges to > declare dependencies: > {code:java} > [WARNING] > Dependency convergence error for com.trib3:graphql:jar:1.32.3279:compile > paths to dependency are: > +-com.joe.quizzy:server:jar:1.0-SNAPSHOT > +-com.joe.quizzy:graphql:jar:1.0-SNAPSHOT:compile > +-com.trib3:graphql:jar:1.32.3279:compile > and > +-com.joe.quizzy:server:jar:1.0-SNAPSHOT > +-com.trib3:graphql:jar:1.32.3324:compile > {code} > both {{com.joe.quizzy:server}} and {{com.joe.quizzy:graphql}} declare a > dependency on {{com.trib3:graphql}}, with a version of > {{[1.32.1,1.33-SNAPSHOT)}}. that version range should (currently) resolve to > 1.32.3324 in both usages, but in enforcer 3.1.0's DependencyConvergence check > does not. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MSHADE-444) Parameter localRepository uses deprecated parameter expression ${localRepository}
Basil Crow created MSHADE-444: - Summary: Parameter localRepository uses deprecated parameter expression ${localRepository} Key: MSHADE-444 URL: https://issues.apache.org/jira/browse/MSHADE-444 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 3.4.1 Reporter: Basil Crow h3. Reproduction steps * Use Maven 3.9.2. * Run {{mvn clean verify}} in a Maven project that uses Maven Shade Plugin. h3. Expected Results No warning h3. Actual Results {noformat} [WARNING] * org.apache.maven.plugins:maven-shade-plugin:3.4.1 […] [WARNING] Mojo issue(s): [WARNING]* Mojo shade:shade (org.apache.maven.plugins.shade.mojo.ShadeMojo) [WARNING] - Parameter 'localRepository' uses deprecated parameter expression '${localRepository}': ArtifactRepository type is deprecated and its use in Mojos should be avoided. {noformat} h3. Anything else? See https://maven.apache.org/docs/3.9.2/release-notes.html#notable-new-features for the root cause. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725026#comment-17725026 ] ASF GitHub Bot commented on MNG-6829: - timtebeek commented on PR #189: URL: https://github.com/apache/maven-compiler-plugin/pull/189#issuecomment-1557544527 Failure _seems _ unrelated to the change; and also fails on the main branch. Welcome to challenge that, I'll go over some of the others first. > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-compiler-plugin] timtebeek commented on pull request #189: [MNG-6829] Replace StringUtils#isEmpty(String) & #isNotEmpty(String)
timtebeek commented on PR #189: URL: https://github.com/apache/maven-compiler-plugin/pull/189#issuecomment-1557544527 Failure _seems _ unrelated to the change; and also fails on the main branch. Welcome to challenge that, I'll go over some of the others first. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MDEP-870) artifact pom not overwritten
[ https://issues.apache.org/jira/browse/MDEP-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MDEP-870: Affects Version/s: 3.6.0 > artifact pom not overwritten > > > Key: MDEP-870 > URL: https://issues.apache.org/jira/browse/MDEP-870 > Project: Maven Dependency Plugin > Issue Type: Bug >Affects Versions: 3.3.0, 3.6.0 >Reporter: Jürgen >Priority: Minor > > the situation: > copy-dependencies, copyPom true, stripVersion true > no clean of target directory beforehand > the artifact jar + associated pom already in target directory (with different > artifact version due to project branch switch) > ./artifact.jar (1.0.0) > ./artifact.pom (1.0.0) > what happens, copy-dependencies will copy the new artifact.jar to target > directory, but not copy the associated pom, leaving the old (for a different > version) pom > ./artifact.jar (2.0.0, 1.0.0 was overwritten) > ./artifact.pom (1.0.0, not overwritten!) > my gut feeling is, that > {code:java} > CopyDependenciesMojo.copyPoms() { > ... >if (!pomDestFile.exists()) copyFile > ... > }{code} > is the wrong check. the pom should be copied/overwritten, if it's artifact > was copied/overwritten. > cf. > [https://github.com/apache/maven-dependency-plugin/blob/e52bc0248c00dbf5458a0ce080db260148dab4b9/src/main/java/org/apache/maven/plugins/dependency/fromDependencies/CopyDependenciesMojo.java#L286] > same is true for current 3.6.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725014#comment-17725014 ] ASF GitHub Bot commented on MNG-6829: - timtebeek commented on code in PR #79: URL: https://github.com/apache/maven-verifier/pull/79#discussion_r1200709064 ## src/main/java/org/apache/maven/shared/verifier/Verifier.java: ## @@ -1861,7 +1861,7 @@ public void setDefaultCliArguments( String[] defaultCliArguments ) private void setForkMode() { -if ( StringUtils.isEmpty( mavenHome ) && StringUtils.isEmpty( forkMode ) ) +if ( (mavenHome == null || mavenHome.isEmpty()) && (forkMode == null || forkMode.isEmpty()) ) Review Comment: ```suggestion if ( ( mavenHome == null || mavenHome.isEmpty() ) && ( forkMode == null || forkMode.isEmpty() ) ) ``` > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-verifier] timtebeek commented on a diff in pull request #79: [MNG-6829] Replace StringUtils#isEmpty(String) & #isNotEmpty(String)
timtebeek commented on code in PR #79: URL: https://github.com/apache/maven-verifier/pull/79#discussion_r1200709064 ## src/main/java/org/apache/maven/shared/verifier/Verifier.java: ## @@ -1861,7 +1861,7 @@ public void setDefaultCliArguments( String[] defaultCliArguments ) private void setForkMode() { -if ( StringUtils.isEmpty( mavenHome ) && StringUtils.isEmpty( forkMode ) ) +if ( (mavenHome == null || mavenHome.isEmpty()) && (forkMode == null || forkMode.isEmpty()) ) Review Comment: ```suggestion if ( ( mavenHome == null || mavenHome.isEmpty() ) && ( forkMode == null || forkMode.isEmpty() ) ) ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet commented on issue #852: `JAVA_HOME` should be discriminating
gnodet commented on issue #852: URL: https://github.com/apache/maven-mvnd/issues/852#issuecomment-1557462948 > I have added a commit to #851 - so @gnodet please veto that one if needed. I think it should be documented as discriminated, but it is handled specifically in a bunch of cases (as shown by the failings ITs), I think it may better to add some javadoc that will end-up in the help, wdyt ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPMD-379) Support PMD 7.0.0
[ https://issues.apache.org/jira/browse/MPMD-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725010#comment-17725010 ] Andreas Dangel commented on MPMD-379: - This is currently needed in two cases: When toolchain is used, then PMD is not invoked within the current JVM process, but a new one is spawned. This is, what Executor#setupLogLevel is responsible for - recreating the environment, that maven cli already provided, in the new process. The other case is the parameter {{showPmdLog}} - if this is true, then any slf4j log message from within PMD should show up as usual. But if this is set to false, then we want to silence out any PMD logging. Since this parameter can be true for one module and false for another, the log levels needs to switch at runtime if no toolchain is in use. This is what Executor#setupPmdLogging is doing. We could however decide, to remove this parameter and keep the logging enabled all the time. That would make it easier. Are there any best practices on how to deal with logs from third-party-libs (in that case, PMD is a 3rd-party lib to maven)? If one wanted to silence out the logging from PMD, then one could change maven's simplelogger.properties (or provide equivalent system properties via MAVEN_OPTS). > Support PMD 7.0.0 > - > > Key: MPMD-379 > URL: https://issues.apache.org/jira/browse/MPMD-379 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: CPD, PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Major > > Add support for the new major version of PMD. > This has some non-backward compatible changes. Upgrading m-pmd-p to PMD 7 > most likely means, that only PMD 7 will be supported onwards (no backwards > compatibility supported). > wip branch: [https://github.com/apache/maven-pmd-plugin/compare/master...pmd7] > > A snapshot version that is compatible with the current 7.0.0 release > candidates is available here as version {*}3.21.1-pmd-7-SNAPSHOT{*}: > {code:java} > > apache.snapshots > Apache Snapshot Repository > https://repository.apache.org/snapshots > > false > > > true > > {code} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725007#comment-17725007 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #58: URL: https://github.com/apache/maven-install-plugin/pull/58 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725006#comment-17725006 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #3: URL: https://github.com/apache/maven-docck-plugin/pull/3 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725002#comment-17725002 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #159: URL: https://github.com/apache/maven-jlink-plugin/pull/159 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725001#comment-17725001 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #79: URL: https://github.com/apache/maven-verifier/pull/79 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725005#comment-17725005 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #109: URL: https://github.com/apache/maven-doxia-sitetools/pull/109 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724998#comment-17724998 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #34: URL: https://github.com/apache/maven-archiver/pull/34 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724997#comment-17724997 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #189: URL: https://github.com/apache/maven-compiler-plugin/pull/189 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725004#comment-17725004 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #3: URL: https://github.com/apache/maven-jarsigner/pull/3 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725003#comment-17725003 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #40: URL: https://github.com/apache/maven-deploy-plugin/pull/40 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17725000#comment-17725000 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #641: URL: https://github.com/apache/maven-surefire/pull/641 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6829) Remove commons-lang3 dependency
[ https://issues.apache.org/jira/browse/MNG-6829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724999#comment-17724999 ] ASF GitHub Bot commented on MNG-6829: - timtebeek opened a new pull request, #20: URL: https://github.com/apache/maven-reporting-impl/pull/20 Use this link to re-run the recipe: https://public.moderne.io/recipes/org.openrewrite.java.migrate.apache.commons.lang.IsNotEmptyToJdk?organizationId=QXBhY2hlIE1hdmVu > Remove commons-lang3 dependency > --- > > Key: MNG-6829 > URL: https://issues.apache.org/jira/browse/MNG-6829 > Project: Maven > Issue Type: Sub-task > Components: Bootstrap Build >Affects Versions: 3.6.3 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Labels: close-pending > Fix For: 4.0.x-candidate > > Attachments: dtPKn.xlsx > > > Currently we use {{commons-lang3}} for the following classes > * {{StringUtils}} can be replaced by usage of either {{plexus-utils}} or > {{maven-shared-utils}} or as I tested with self implementation > * {{SystemUtils}} is only used in some tests which can simply replaced by > using JUnit Jupiter with all the support it has. > * {{Validate}} is a precondition class which checks for parameters etc. can > be implemented very easily (done already to see how it works). Later this > could be made part of {{maven-shared-utils}}. > * Currently the {{StringUtils.substringAfterLast( resourceName, "/" )}} is > used in {{ConsoleMavenTransferListener}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-surefire] michael-o opened a new pull request, #640: Stacked fixes
michael-o opened a new pull request, #640: URL: https://github.com/apache/maven-surefire/pull/640 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7789) Plugin Dependency Validations use wrong data set
[ https://issues.apache.org/jira/browse/MNG-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7789: - Fix Version/s: 4.0.0-alpha-6 4.0.0 > Plugin Dependency Validations use wrong data set > > > Key: MNG-7789 > URL: https://issues.apache.org/jira/browse/MNG-7789 > Project: Maven > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 3.9.2 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > They all use pluginDescriptor/dependencies, that are NOT used to calculate > plugin dependencies, POM is. Except for one new check (the one added in > MNG-7786) the others should be refactored to use POM instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MCHECKSTYLE-407) Maven Site + Surefire + Checkstyle fails to build
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724962#comment-17724962 ] Michael Osipov edited comment on MCHECKSTYLE-407 at 5/22/23 2:09 PM: - Please upgrade to the most recent versions of Maven 3.8.x, Surefire and Checkstyle Plugin and retry again. was (Author: michael-o): Please upgrade to the most recent versions of Maven 3.8.x, Surefire and Checkstyle and retry again. > Maven Site + Surefire + Checkstyle fails to build > - > > Key: MCHECKSTYLE-407 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-407 > Project: Maven Checkstyle Plugin > Issue Type: Bug > Components: checkstyle:check >Affects Versions: 3.1.2 > Environment: Apache Maven 3.8.1 > (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) > Maven home: /usr/local/Cellar/maven/3.8.1/libexec > Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac" >Reporter: Nas Kavian >Priority: Major > Fix For: waiting-for-feedback > > > Summary: > * when I use checkstyle with phase=validate, `mvn site` works. > * when I use checkstyle with phase=test, `mvn site` fails with an error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.9.1:site (default-site) on > project payments-web: failed to get report for > org.apache.maven.plugins:maven-surefire-report-plugin: Failed to execute goal > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check (default) on > project payments-web: Unable to parse configuration of mojo > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check: Basic element > 'excludes' must not contain child elements > The checkstyle configuration looks like this: > > org.apache.maven.plugins > maven-checkstyle-plugin > 3.1.2 > > > test > > check > > > > > > The surefire configuration looks like this: > > org.apache.maven.plugins > maven-surefire-plugin > 3.0.0-M5 > > > ${exclude.tests} > > ${tests} > > **/*Test.java > > > > > The error about "excludes" is referring to the "excludes" in the surefire > plugin. > > This is a partial stacktrace: > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-site-plugin:3.9.1:site (default-site) on > project payments-web: failed to get report for > org.apache.maven.plugins:maven-surefire-report-plugin > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > ... > ... > Caused by: org.apache.maven.plugin.MojoExecutionException: failed to get > report for org.apache.maven.plugins:maven-surefire-report-plugin > at > org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildMavenReports > (DefaultMavenReportExecutor.java:159) > at > org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.getReports > (AbstractSiteRenderingMojo.java:226) > ... > ... > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check > (default) on project payments-web: Unable to parse configuration of mojo > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check: Basic element > 'excludes' must not contain child elements > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > ... > ... > Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to > parse configuration of mojo > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check: Basic element > 'excludes' must not contain child elements > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields > (DefaultMavenPluginManager.java:665) > at >
[jira] [Commented] (MCHECKSTYLE-407) Maven Site + Surefire + Checkstyle fails to build
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724962#comment-17724962 ] Michael Osipov commented on MCHECKSTYLE-407: Please upgrade to the most recent versions of Maven 3.8.x, Surefire and Checkstyle and retry again. > Maven Site + Surefire + Checkstyle fails to build > - > > Key: MCHECKSTYLE-407 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-407 > Project: Maven Checkstyle Plugin > Issue Type: Bug > Components: checkstyle:check >Affects Versions: 3.1.2 > Environment: Apache Maven 3.8.1 > (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) > Maven home: /usr/local/Cellar/maven/3.8.1/libexec > Java version: 1.8.0_241, vendor: Oracle Corporation, runtime: > /Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.14.6", arch: "x86_64", family: "mac" >Reporter: Nas Kavian >Priority: Major > Fix For: waiting-for-feedback > > > Summary: > * when I use checkstyle with phase=validate, `mvn site` works. > * when I use checkstyle with phase=test, `mvn site` fails with an error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.9.1:site (default-site) on > project payments-web: failed to get report for > org.apache.maven.plugins:maven-surefire-report-plugin: Failed to execute goal > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check (default) on > project payments-web: Unable to parse configuration of mojo > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check: Basic element > 'excludes' must not contain child elements > The checkstyle configuration looks like this: > > org.apache.maven.plugins > maven-checkstyle-plugin > 3.1.2 > > > test > > check > > > > > > The surefire configuration looks like this: > > org.apache.maven.plugins > maven-surefire-plugin > 3.0.0-M5 > > > ${exclude.tests} > > ${tests} > > **/*Test.java > > > > > The error about "excludes" is referring to the "excludes" in the surefire > plugin. > > This is a partial stacktrace: > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-site-plugin:3.9.1:site (default-site) on > project payments-web: failed to get report for > org.apache.maven.plugins:maven-surefire-report-plugin > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > ... > ... > Caused by: org.apache.maven.plugin.MojoExecutionException: failed to get > report for org.apache.maven.plugins:maven-surefire-report-plugin > at > org.apache.maven.reporting.exec.DefaultMavenReportExecutor.buildMavenReports > (DefaultMavenReportExecutor.java:159) > at > org.apache.maven.plugins.site.render.AbstractSiteRenderingMojo.getReports > (AbstractSiteRenderingMojo.java:226) > ... > ... > Caused by: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to > execute goal org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check > (default) on project payments-web: Unable to parse configuration of mojo > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check: Basic element > 'excludes' must not contain child elements > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > ... > ... > Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to > parse configuration of mojo > org.apache.maven.plugins:maven-checkstyle-plugin:3.1.2:check: Basic element > 'excludes' must not contain child elements > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields > (DefaultMavenPluginManager.java:665) > at > org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo > (DefaultMavenPluginManager.java:597) > ... > ... > Caused by: > org.codehaus.plexus.component.configurator.ComponentConfigurationException: > Basic element
[jira] [Commented] (MDEP-799) improve mvn dependency:tree - add optional JSON output of the results
[ https://issues.apache.org/jira/browse/MDEP-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724960#comment-17724960 ] ASF GitHub Bot commented on MDEP-799: - monperrus commented on PR #207: URL: https://github.com/apache/maven-dependency-plugin/pull/207#issuecomment-1557266817 super cool feature, hope we can get it merged! > improve mvn dependency:tree - add optional JSON output of the results > - > > Key: MDEP-799 > URL: https://issues.apache.org/jira/browse/MDEP-799 > Project: Maven Dependency Plugin > Issue Type: New Feature > Components: tree >Reporter: Zhenxu Ke >Priority: Major > > I'd like to add an output type JSON, will open a pull request soon -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-870) artifact pom not overwritten
Jürgen created MDEP-870: --- Summary: artifact pom not overwritten Key: MDEP-870 URL: https://issues.apache.org/jira/browse/MDEP-870 Project: Maven Dependency Plugin Issue Type: Bug Affects Versions: 3.3.0 Reporter: Jürgen the situation: copy-dependencies, copyPom true, stripVersion true no clean of target directory beforehand the artifact jar + associated pom already in target directory (with different artifact version due to project branch switch) ./artifact.jar (1.0.0) ./artifact.pom (1.0.0) what happens, copy-dependencies will copy the new artifact.jar to target directory, but not copy the associated pom, leaving the old (for a different version) pom ./artifact.jar (2.0.0, 1.0.0 was overwritten) ./artifact.pom (1.0.0, not overwritten!) my gut feeling is, that {code:java} CopyDependenciesMojo.copyPoms() { ... if (!pomDestFile.exists()) copyFile ... }{code} is the wrong check. the pom should be copied/overwritten, if it's artifact was copied/overwritten. cf. [https://github.com/apache/maven-dependency-plugin/blob/e52bc0248c00dbf5458a0ce080db260148dab4b9/src/main/java/org/apache/maven/plugins/dependency/fromDependencies/CopyDependenciesMojo.java#L286] same is true for current 3.6.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-mvnd] ppalaga opened a new issue, #853: Show UI shortcuts upon hitting `h`, list them in `mvnd --help`
ppalaga opened a new issue, #853: URL: https://github.com/apache/maven-mvnd/issues/853 The shortcuts are currently hard to discover. We should list them in the output of `mvnd --help` and we should also show the list in the UI. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga opened a new issue, #852: Shouldn't `JAVA_HOME` be discriminating?
ppalaga opened a new issue, #852: URL: https://github.com/apache/maven-mvnd/issues/852 I guess yes, at least for the sake of documenting it. I see that in `DaemonCompatibilitySpec`, it has a special position among the other discriminating options. But still, it is de facto discriminating, so we should put the discriminating flag on it. WDYT @gnodet ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7714) sp < final
[ https://issues.apache.org/jira/browse/MNG-7714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17724926#comment-17724926 ] ASF GitHub Bot commented on MNG-7714: - CrazyHZM commented on code in PR #1099: URL: https://github.com/apache/maven/pull/1099#discussion_r1200430828 ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -199,6 +202,7 @@ public int compareTo(Item item) { return -1; case STRING_ITEM: +case COMBINATION_ITEM: Review Comment: Done. > sp < final > -- > > Key: MNG-7714 > URL: https://issues.apache.org/jira/browse/MNG-7714 > Project: Maven > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Elliotte Rusty Harold >Priority: Major > Fix For: 4.0.0-alpha-6 > > > Ported from a comment on https://issues.apache.org/jira/browse/MNG-7701 > The claim is that sp < final, which if true is incorrect according to spec. > It is easy to demonstrate that this is not fixed and also not in line with > the spec, with just this one important example (yes this does break for us): > $ jbang org.apache.maven:maven-artifact:3.8.6 1.0.final-redhat-0001 > 1.0.sp1-redhat-0001 > Display parameters as parsed by Maven (in canonical form and as a list of > tokens) and comparison result: > 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]] >1.0.final-redhat-0001 < 1.0.sp1-redhat-0001 > 2. 1.0.sp1-redhat-0001 -> 1.0.sp-1-redhat-1; tokens: [1, 0, sp, [1, [redhat, > [1 > versus > $ jbang org.apache.maven:maven-artifact:3.8.7 1.0.final-redhat-0001 > 1.0.sp1-redhat-0001 > Display parameters as parsed by Maven (in canonical form and as a list of > tokens) and comparison result: > 1. 1.0.final-redhat-0001 -> 1-redhat-1; tokens: [1, [redhat, [1]]] >1.0.final-redhat-0001 > 1.0.sp1-redhat-0001 > 2. 1.0.sp1-redhat-0001 -> 1-sp-1-redhat-1; tokens: [1, [sp, [1, [redhat, > [1] > As you can see, our `sp` release is now ordered after our `final` release > despite this clear text in the "spec": > Non-numeric tokens ("qualifiers") have the alphabetical order, except for > the following tokens which come first in this order: "alpha" < "beta" < > "milestone" < "rc" = "cr" < "snapshot" < "" = "final" = "ga" < "sp" > It's clear that this tokenization isn't really correct by any reasonable > measurement, and breaking large amounts of (our) existing artifacts in the > wild is definitely not OK. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] CrazyHZM commented on a diff in pull request #1099: [MNG-7714] Fixed a scenario in version sorting where sp1 is less than final
CrazyHZM commented on code in PR #1099: URL: https://github.com/apache/maven/pull/1099#discussion_r1200430828 ## maven-artifact/src/main/java/org/apache/maven/artifact/versioning/ComparableVersion.java: ## @@ -199,6 +202,7 @@ public int compareTo(Item item) { return -1; case STRING_ITEM: +case COMBINATION_ITEM: Review Comment: Done. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga opened a new pull request, #851: Show which options are discriminating in the output of mvnd --help
ppalaga opened a new pull request, #851: URL: https://github.com/apache/maven-mvnd/pull/851 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] michael-o opened a new pull request, #639: Use choice message format to render percentage and time
michael-o opened a new pull request, #639: URL: https://github.com/apache/maven-surefire/pull/639 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] michael-o opened a new pull request, #638: Improve string representation of elapsed time
michael-o opened a new pull request, #638: URL: https://github.com/apache/maven-surefire/pull/638 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean install` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jxr] dependabot[bot] commented on pull request #90: Bump maven-parent from 37 to 39
dependabot[bot] commented on PR #90: URL: https://github.com/apache/maven-jxr/pull/90#issuecomment-1557059656 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-jxr] elharo closed pull request #90: Bump maven-parent from 37 to 39
elharo closed pull request #90: Bump maven-parent from 37 to 39 URL: https://github.com/apache/maven-jxr/pull/90 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] ppalaga merged pull request #850: {@link } JavaDoc refs missing in the output of mvnd --help
ppalaga merged PR #850: URL: https://github.com/apache/maven-mvnd/pull/850 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org