[GitHub] [maven-ear-plugin] mabrarov commented on a change in pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on a change in pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#discussion_r499204091 ## File path: src/test/java/org/apache/maven/plugins/ear/it/EarMojoIT.java ## @@ -1,996 +1,963 @@ -package org.apache.maven.plugins.ear.it; Review comment: Reverted accidental changes in line endings This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on a change in pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on a change in pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#discussion_r499202940 ## File path: src/test/java/org/apache/maven/plugins/ear/it/EarMojoIT.java ## @@ -1,996 +1,963 @@ -package org.apache.maven.plugins.ear.it; Review comment: Looks like accidental changes in line endings (which I failed to revert) causes wrong diff shown for this file. Use "Hide whitespace changes" option for review. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on a change in pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on a change in pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#discussion_r499201646 ## File path: src/test/java/org/apache/maven/plugins/ear/it/EarMojoIT.java ## @@ -1,996 +1,963 @@ -package org.apache.maven.plugins.ear.it; Review comment: I have no idea why GitHub shows this file as fully rewritten. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on a change in pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on a change in pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#discussion_r499201646 ## File path: src/test/java/org/apache/maven/plugins/ear/it/EarMojoIT.java ## @@ -1,996 +1,963 @@ -package org.apache.maven.plugins.ear.it; Review comment: I have no idea why GitHub shows this file as fully rewritten. Maybe GitHub just cannot show large diff consisting of many changed lines (due to removal of useless `@throws` JavaDoc). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-703195593 I added some integration tests but they do not cover all permutations (i.e. all changed branches) of options like: 1. [skinnyWars](https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#unpackTypes) 1. [skipClassPathModification](https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#unpackTypes) 1. [unpackTypes](https://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#unpackTypes) 1. "dirty" build without `clean` goal execution This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206897#comment-17206897
]
Michael Osipov commented on MNG-6965:
-
Found it, last issue is gone. All Its pass now.
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MEAR-286) filtered resources not copied if run-its profile not activated
[ https://issues.apache.org/jira/browse/MEAR-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206892#comment-17206892 ] Marat Abrarov commented on MEAR-286: I believe that I fixed this bug in https://github.com/apache/maven-ear-plugin/pull/18 > filtered resources not copied if run-its profile not activated > -- > > Key: MEAR-286 > URL: https://issues.apache.org/jira/browse/MEAR-286 > Project: Maven Ear Plugin > Issue Type: Bug >Affects Versions: 3.0.0, 3.1.0 >Reporter: Herve Boutemy >Priority: Major > > found during Reproducible Builds check for 3.1.0 release... > Notice that reference builds published to Central Repository have the > filtered resource (/META-INF/plexus/components.xml) because our release > process using maven-release-plugin activates the run-its profile: at least, > official releases are ok > issue happens only for manual "light" builds (run without ITs) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov edited a comment on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov edited a comment on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-703171162 I fixed [2nd root cause](https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-703167969) of MEAR-267 in 89816ae: ```bash $ git clone --branch MEAR-267_Manifest_classpath_modification https://github.com/mabrarov/MEAR-267-issue-demo.git && \ mvn -q -B -f MEAR-267-issue-demo/pom.xml verify -Dmaven-ear-plugin.version=3.1.1-SNAPSHOT 2>&1 | grep -c WFLYSRV0059 ... 0 ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-703171162 I fixed [2nd root cause](https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-703167969) of MEAR-267 in 89816ae This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov edited a comment on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov edited a comment on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-703167969 Hmm... I made one more test: ```bash $ git clone --branch MEAR-267_Manifest_classpath_modification https://github.com/mabrarov/MEAR-267-issue-demo.git && \ mvn -q -B -f MEAR-267-issue-demo/pom.xml verify -Dmaven-ear-plugin.version=3.1.1-SNAPSHOT 2>&1 | grep WFLYSRV0059 ``` and it demonstrates: ```text 00:35:52,808 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry guava-19.0.jar in /content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar does not point to a valid jar for a Class-Path reference. ``` that MEAR-267 has multiple root causes and I fixed in this pull request just one of them. In MEAR-267-issue-demo we have skinnyWars option turned off and it looks like this makes Maven EAR Plugin skipping modification of manifest of EJB JAR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206865#comment-17206865
]
Michael Osipov commented on MNG-6965:
-
I am hanging for ours trying to understand why Plexus Utils is necessary. I
think there is some hidden exception which make the loading fail for the IT
MNG-2749. OR the entire IT is conceptionlly broken.
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov edited a comment on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov edited a comment on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-703167969 Hmm... I made one more test: ```bash $ git clone --branch MEAR-267_Manifest_classpath_modification https://github.com/mabrarov/MEAR-267-issue-demo.git && \ mvn -q -B -f MEAR-267-issue-demo/pom.xml verify -Dmaven-ear-plugin.version=3.1.1-SNAPSHOT 2>&1 | grep WFLYSRV0059 ``` and it demonstrates: ```text 00:35:52,808 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry guava-19.0.jar in /content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar does not point to a valid jar for a Class-Path reference. ``` that MEAR-267 has multiple root causes and I fixed in this pull request just one of them. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-703167969 Hmm... I made one more test: ```bash $ git clone --branch MEAR-267_Manifest_classpath_modification https://github.com/mabrarov/MEAR-267-issue-demo.git && \ mvn -q -B -f MEAR-267-issue-demo/pom.xml verify 2>&1 | grep WFLYSRV0059 ``` and it demonstrates: ```text 00:35:52,808 WARN [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0059: Class Path entry guava-19.0.jar in /content/MEAR-267.ear/com.leokom-MEAR-267-ejb-1.0-SNAPSHOT.jar does not point to a valid jar for a Class-Path reference. ``` that MEAR-267 has multiple root causes and I fixed in this pull request just one of them. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #19: [MEAR-267] - Fixed detection if JAR module is included into classpath of particular EAR module manifest
mabrarov commented on pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19#issuecomment-703162560 Taking into account enhancements in `EarMojoIT` made in pull request #17 I would create tests for this pull request after that pull request is merged, because it looks like we need those enhancements here 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6983) Plugin key can get out of sync with artifactId and groupId
[
https://issues.apache.org/jira/browse/MNG-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206855#comment-17206855
]
Hudson commented on MNG-6983:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6965 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6965/15/
> Plugin key can get out of sync with artifactId and groupId
> --
>
> Key: MNG-6983
> URL: https://issues.apache.org/jira/browse/MNG-6983
> Project: Maven
> Issue Type: Bug
> Components: core, Plugins and Lifecycle
>Affects Versions: 3.6.3
>Reporter: Paul Pazderski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: pluginNotExecuted.zip
>
>
> I have a project build with maven where some maven plugins are not executed
> without any warning or error shown in output. I was able to reproduce the
> issue with a minimal example. (see attachment)
> The expected result of this example is to get the one source file compiled if
> you invoke {{mvn compile}}.
> If I run this example using Maven 3.6.3 the following output appears:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:child
> >--
> [INFO] Building child 0.0.1-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ child
> ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> [...]\pluginNotExecuted\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child ---
> [INFO] No sources to compile
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.644 s
> [INFO] Finished at: [...]
> [INFO]
>
> {noformat}
> Notice that there is no execution of the build-helper-maven-plugin (and as
> consequence no source compiled) and no indication why it is missing.
> From what I've found the problem seem to be the usage of variable in the
> plugins groupId. If you replace either the variable in parent- or child-pom
> with the actual value the build shows a warning
> {noformat}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.example:child:jar:0.0.1-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 16, column 21
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {noformat}
> If you replace both variables with the actual value everything works as
> expected.
>
> I investigated the problem further and will provide more details with a pull
> request for a possible fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206851#comment-17206851
]
Hudson commented on MNG-6772:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6965 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6965/15/
> Super POM overwrites remapped central repository in nested import POMs
> --
>
> Key: MNG-6772
> URL: https://issues.apache.org/jira/browse/MNG-6772
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.6.2
>Reporter: Eddie Wiegers
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} which is meant to
> specifically override the entry in the Super POM. This is specifically what
> [JFrog Artifactory
> recommends|https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]
> doing, and seems valid in situations where the _real_ Maven Central may be
> unreachable.
>
> The override takes precedence almost all of the time. However, there is at
> least one scenario where this is not the case, and that is when importing a
> POM that in turn imports another POM.
>
> Digging into the code, it appears the reason this happens is because the
> {{DefaultModelBuilder}} overwrites repositories after interpolation is
> complete:
> [https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411]
>
> From what I can tell, this is done with the intention of overwriting
> repositories that were added to the local resolver prior to interpolation
> with the interpolated version. Due to the way the {{DefaultModelResolver}}
> works, an unintended side effect is that the {{central}} repository from the
> Super POM is added once after each interpolation. The first time the
> repository is added, it is added to the {{repositoryIds}} but doesn't
> actually remove the original repository. The second time it is added is when
> the original repository will be replaced. Currently, the repositoryIds are
> preserved in the {{ModelResolver}} when resolving import POMs, leading to the
> behavior I am seeing where the second nested import POM ends up being where
> the failure occurs.
>
> I am planning on submitting a PR to clone the {{ModelResolver}} in a way that
> resets the repositoryIds prior to import POMs being resolved, since they are
> separate artifact builds. That seems like the most consistent fix to me that
> covers cases outside of the the Super POM's {{central}} definition.
>
> *Workarounds*:
> The current workaround is to use a repository ID other than {{central}} for
> my Artifactory repository, which isn't ideal since it leaves the potential
> for long timeouts to occur on the real {{central}} when an artifact can't be
> resolved from my Artifactory repository.
>
> Mirrors are not an ideal workaround since getting them in place on all
> possible build environments isn't trivial.
>
> When looking at the code I noticed
> {{RepositorySystemSession#isIgnoreArtifactDescriptorRepositories()}} being
> checked in various places, which seems like it would also act as a potential
> workaround, but I don't see a way to enable this value via MavenCLI or
> properties of any kind. It seems like this value aligns well with what
> Artifactory is already trying to enforce, so it would make sense to enable
> this in projects that intend to exclusively use Artifactory. Is there a
> supported way to set this value outside of constructing a Maven build in code?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6991) settings-defined local repository is not honored
[
https://issues.apache.org/jira/browse/MNG-6991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206854#comment-17206854
]
Hudson commented on MNG-6991:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6965 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6965/15/
> settings-defined local repository is not honored
>
>
> Key: MNG-6991
> URL: https://issues.apache.org/jira/browse/MNG-6991
> Project: Maven
> Issue Type: Bug
>Reporter: François Guillot
>Assignee: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> We have functional tests using the latest Maven snapshots and they started
> polluting the global ~/.m2/repository.
> [This
> commit|https://github.com/apache/maven/commit/ac80f5c2b93743c36e2b24ca91a47a0f13de981f]
> introduced a bug in the handling of the local repository definition.
> The local repository is taken from settings
> [here|https://github.com/apache/maven/blob/b962ff361aee64a291db588e9f88d86c5f9dee0c/maven-core/src/main/java/org/apache/maven/execution/DefaultMavenExecutionRequestPopulator.java#L234].
> but then, before, Maven was doing (in MavenCli)
> {code}
> String localRepoProperty = request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> if ( localRepoProperty == null )
> {
> localRepoProperty = request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY );
> }
> if ( localRepoProperty != null )
> {
> request.setLocalRepositoryPath( localRepoProperty );
> }
> {code}
> effectively replacing the local repository definition only if
> `maven.repo.local` was defined in user or system properties.
>
> After the commit mentioned above, the code does
> {code}
> request.setLocalRepositoryPath( determineLocalRepositoryPath( request
> ) );
> ...
> private String determineLocalRepositoryPath( final
> MavenExecutionRequest request )
> {
> return request.getUserProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY,
> request.getSystemProperties().getProperty(
> MavenCli.LOCAL_REPO_PROPERTY ) // null if not found
> );
> }
> {code}
> effectively _always_ replacing the local repository definition, potentially
> nulling it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6987) Reorder groupId before artifactId when writing an exclusion using maven-model
[
https://issues.apache.org/jira/browse/MNG-6987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206852#comment-17206852
]
Hudson commented on MNG-6987:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6965 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6965/15/
> Reorder groupId before artifactId when writing an exclusion using maven-model
> -
>
> Key: MNG-6987
> URL: https://issues.apache.org/jira/browse/MNG-6987
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.3
>Reporter: Marc Bruggmann
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.7.0
>
>
> We are using {{maven-model}} to parse, modify, and write back a POM file
> roughly like so:
>
> {code:java}
> MavenXpp3Reader reader = new MavenXpp3Reader();
> Model model = reader.read(new FileReader(input));
> // make modifications to the model
> MavenXpp3Writer writer = new MavenXpp3Writer();
> writer.write(new FileWriter(output), model);{code}
>
> The exclusion shows up in the output file like this:
> {code:java}
>
>
> plexus-cipher
> org.sonatype.plexus
>
>
> {code}
> In most other places in the POM, we order the groupId before the artifactId.
> It would be nice to do it the same way for exclusion, like so:
> {code:java}
>
>
> org.sonatype.plexus
> plexus-cipher
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206856#comment-17206856
]
Hudson commented on MNG-6965:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6965 #15
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6965/15/
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6949) As a developer on Maven Core I would like to verify my build before merge
[ https://issues.apache.org/jira/browse/MNG-6949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206853#comment-17206853 ] Hudson commented on MNG-6949: - Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6965 #15 See https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6965/15/ > As a developer on Maven Core I would like to verify my build before merge > - > > Key: MNG-6949 > URL: https://issues.apache.org/jira/browse/MNG-6949 > Project: Maven > Issue Type: Improvement >Reporter: Martin Kanters >Assignee: Sylwester Lachiewicz >Priority: Major > Fix For: 3.7.0 > > > One of the requirements before providing a pull request to Maven is that you > have to run `mvn verify` and the integration tests. This is to ensure that > the PR that is delivered is of good quality. I do not disagree with this > approach, but it can be easy to forget to run this, especially in the case of > processing (small) review comments. > For me it already happened a couple of times that a failing test was found at > the time when the pull request was getting merged in master. By utilizing > GitHub Actions we can ensure that the PR's requirements are fulfilled. This > is meant as an addition on top of local tests and the CI job on Jenkins tests > that commiters execute during merger, not a replacement. > > I have implemented this last weekend and would like to propose this. It is > based on another Maven project's GitHub Action workflow, but has been > extended. It features the following: > # mvn verify on Ubuntu, Windows and MacOS machines, with Java 8, 11, 14. > # integration tests against the new Maven build (from step 1). > By default it will run against the latest master version of > apache/maven-integration-testing. > However, if the developer has a branch with the same name as the maven PR on > a forked maven-integration-testing project, it will check that out instead. > Link to the pull request: [https://github.com/apache/maven/pull/365]. > Currently the action is not running on the PR itself, I guess that is due to > settings in the apache/maven project. > It is running on the branch of our fork, though: > [https://github.com/infosupport/maven/actions/runs/150771674]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov commented on a change in pull request #17: [MEAR-287] Fixed failure when destination directory exists
mabrarov commented on a change in pull request #17:
URL: https://github.com/apache/maven-ear-plugin/pull/17#discussion_r499178059
##
File path: src/test/java/org/apache/maven/plugins/ear/it/EarMojoIT.java
##
@@ -993,4 +993,24 @@ public void testProject087()
{
doTestProject( "project-087", new String[] {
"eartest-ejb-sample-one-1.0.jar", "eartest-ejb-sample-two-1.0.jar" } );
}
+
+/**
+ * Builds WAR and EAR as part of multi-module project twice so that the
2nd build is guaranteed to be performed when
+ * target directories and files exist.
+ * @throws Exception in case of an error.
Review comment:
Removed in eeb458b
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MEAR-267) assembly.xml contains incorrect references to modules
[
https://issues.apache.org/jira/browse/MEAR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206849#comment-17206849
]
Marat Abrarov commented on MEAR-267:
I implemented possible fix for this bug in [pull request
#19|https://github.com/apache/maven-ear-plugin/pull/19]. I appreciate if
[~hboutemy] and [~elharo] could help me with review and creation of tests.
> assembly.xml contains incorrect references to modules
> -
>
> Key: MEAR-267
> URL: https://issues.apache.org/jira/browse/MEAR-267
> Project: Maven Ear Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Leonid Rozenblyum
>Priority: Major
>
> SCENARIO:
> Create a EAR project with maven-ear-plugin 3.0.0
> execute mvn ear:ear
> EXPECTED:
> assembly.xml contains reference to the jar/war equivalent to their physical
> names inside
> the EAR
> (e.g. if the jar is named tryEar-ejb-1.0-SNAPSHOT.jar then assembly.xml
> reference would be:
> {quote}{{}}
> tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
> (this worked in 2.10.1)
> ACTUALLY:
> assembly.xml contains reference
> {quote}
> com.leokom-tryEar-ejb-1.0-SNAPSHOT.jar
>
> {quote}
>
> Due to this difference - JBoss/WildFly cannot deploy the EAR.
> (it's easy to reproduce: you may create a ear project from some standard ones
> from maven-archetypes and change maven-ear-plugin version to 3.0.0).
>
> UPDATE: Sorry, maybe it's a bug in M2E-WTP plugin of Eclipse. I tried this
> scenario in standalone mode without Eclipse - and assembly.xml is consistent
> with the jar files
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov opened a new pull request #19: [MEAR-267] - Fixed detection if EAR JAR module is included into classpath of particular EAR module manifest
mabrarov opened a new pull request #19: URL: https://github.com/apache/maven-ear-plugin/pull/19 Fixed detection if JAR module is included into classpath of particular EAR module manifest (like WAR or EJB module manifest). This is required for correct modification of Class-Path entry of manifest of EAR modules when skinnyWars option is turned on. Note that this PR has no tests (yet) but I tested it manually with feature/MEAR-267_test branch of https://github.com/mabrarov/dockerfile-test: ```bash $ git clone --branch feature/MEAR-267_test https://github.com/mabrarov/dockerfile-test.git && \ mvn -f dockerfile-test/pom.xml clean package -Ddocker.skip -Dmaven-ear-plugin.version=3.1.1-SNAPSHOT ``` where expected manifest of WAR inside built EAR, i.e. dockerfile-test/ear/target/ear-1.1.7-SNAPSHOT.ear/org.mabrarov.dockerfile-test-war-1.1.7-SNAPSHOT.war/META-INF/MANIFEST.MF looks like: ```text Manifest-Version: 1.0 Class-Path: lib/org.apache.commons-commons-text-1.7.jar lib/org.apache .commons-commons-lang3-3.9.jar Build-Jdk-Spec: 1.8 Created-By: Maven WAR Plugin 3.3.1 git-commit: e0458e2c48333f2847abfe58b7d1d0b3e23e8941 ``` while original manifest of WAR, i.e. dockerfile-test/war/target/war-1.1.7-SNAPSHOT.war/META-INF/MANIFEST.MF looks like: ```text Manifest-Version: 1.0 Class-Path: commons-text-1.7.jar commons-lang3-3.9.jar Build-Jdk-Spec: 1.8 Created-By: Maven WAR Plugin 3.3.1 git-commit: e0458e2c48333f2847abfe58b7d1d0b3e23e8941 ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206844#comment-17206844
]
Michael Osipov commented on MNG-6965:
-
After rebasing, I am down to:
{noformat}
[ERROR] Failures:
[ERROR]
MavenITmng2749ExtensionAvailableToPluginTest>AbstractMavenIntegrationTestCase.runTest:255->testitMNG2749:62
[INFO]
[ERROR] Tests run: 849, Failures: 1, Errors: 0, Skipped: 0
{noformat}
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6965:
Comment: was deleted
(was: Failure for {{MavenITmng2749ExtensionAvailableToPluginTest}} is now
gone)
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206841#comment-17206841
]
Michael Osipov commented on MNG-6965:
-
Failure for {{MavenITmng2749ExtensionAvailableToPluginTest}} is now gone
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6994) Clarify remote repository resolution order
[
https://issues.apache.org/jira/browse/MNG-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206833#comment-17206833
]
Konrad Windszus commented on MNG-6994:
--
PR at https://github.com/apache/maven-site/pull/205.
> Clarify remote repository resolution order
> --
>
> Key: MNG-6994
> URL: https://issues.apache.org/jira/browse/MNG-6994
> Project: Maven
> Issue Type: Improvement
> Components: Documentation: General
>Reporter: Konrad Windszus
>Priority: Major
>
> It is possible to declare remote repositories in {{settings.xml}} and
> {{pom.xml}}. While for the {{settings.xml}} it has to be given in a profile,
> for {{pom.xml}} it can be given in the top-level {{repositories}} element as
> well as in profiles. The order in which an artifact is tried to be resolved
> from the different remote repo is sometimes crucial to know (e.g. to speed up
> build times by first checking against remote repos having most of the
> artifacts like Maven Central)
> It would be nice to document this in
> https://maven.apache.org/guides/introduction/introduction-to-repositories.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ARCHETYPE-612) Required property interactive prompt ordering incorrect when reassigning default for a "core" property
[
https://issues.apache.org/jira/browse/ARCHETYPE-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Hutchison updated ARCHETYPE-612:
--
Description:
The interactive archetype project generation attempts to be smart in ordering
required properties so that when a default value for one property includes a
reference to another, they are asked for in the correct order. This also
however tries to ask the "core" properties (groupId, archetypeId, version, and
package) in a fixed order, and any others in alphabetical order, if they do not
have dependencies.
I was trying to setup an archetype with a couple of prompts which would be
referenced in the default values for groupId, archetypeId and package.
Basically attempting to standardise the setup for these based on the
"application" and "database" the repository was for, so we would have:
* groupId: {{com.example.${application}.data}}
* archetypeId: {{${database}}}
* package: {{com.example.${application}.data.${database}}}
When doing this however, the package is prompted for before the value it's
default depends on.
This snippet from archetype-metadata.xml will trigger the issue as a test
{code:java}
com.devwithimagination
test-${a-prop}
${groupId}.${artifactId}.${z-prop}
{code}
Running this archetype interactively will output something like this:
{code:java}
$ mvn archetype:generate -DarchetypeArtifactId=archetype-test
-DarchetypeGroupId=com.devwithimagination.archetypes
[INFO] Generating project in Interactive mode
[INFO] Archetype
[com.devwithimagination.archetypes:archetype-test:1.0-SNAPSHOT] found in
catalog local
[INFO] Using property: groupId = com.devwithimagination
Define value for property 'version' 1.0-SNAPSHOT: :
Define value for property 'package'
com.devwithimagination.archetypes.archetype-test.${z-prop}: :
Define value for property 'a-prop': 123
Define value for property 'artifactId' test-123: :
Define value for property 'z-prop':
{code}
So {{package}} was prompted for before {{artifactId}} and {{z-prop}} which it
needed for the default value. In typing this up I just noticed it used the
{{archetypeArtifactId}} in the default value instead.
I have got a failing test case for {{RequiredPropertyComparatorTest}} which
shows the comparator isn't performing the sort correctly.
A possible solution for this could be what ARCHETYPE-443 proposed, and respect
the property order defined in the archetype metadata file. Any "core" required
properties could still be prompted for in their default order, unless the
archetype author had also included them in {{archetype-metadata.xml}}. With
that change, it would be up to the archetype author to ensure that properties
are correctly ordered. ARCHETYPE-562 points to other issues with this sort.
I have been having a look at making the sort smarter, but so far I've not been
able to keep the name based ordering working while fixing the property
dependency based sort.
was:
The interactive archetype project generation attempts to be smart in ordering
required properties so that when a default value for one property includes a
reference to another, they are asked for in the correct order. This also
however tries to ask the "core" properties (groupId, archetypeId, version, and
package) in a fixed order, and any others in alphabetical order, if they do not
have dependencies.
I was trying to setup an archetype with a couple of prompts which would be
referenced in the default values for groupId, archetypeId and package.
Basically attempting to standardise the setup for these based on the
"application" and "database" the repository was for, so we would have:
* groupId: `com.example.${application}.data`
* archetypeId: `${database}`
* package: `com.example.${application}.data.${database}`
When doing this however, the package is prompted for before the value it's
default depends on.
This snippet from archetype-metadata.xml will trigger the issue as a test
{code:java}
com.devwithimagination
test-${a-prop}
${groupId}.${artifactId}.${z-prop}
{code}
Running this archetype interactively will output something like this:
{code:java}
$ mvn archetype:generate -DarchetypeArtifactId=archetype-test
-DarchetypeGroupId=com.devwithimagination.archetypes
[INFO] Generating project in Interactive mode
[INFO] Archetype
[com.devwithimagination.archetypes:archetype-test:1.0-SNAPSHOT] found in
catalog local
[INFO] Using property: groupId = com.devwithimagination
Define value for property 'version' 1.0-SNAPSHOT: :
Define value for property 'package'
com.devwithimagination.archetypes.archetype-test.${z-prop}: :
Define value for property 'a-prop': 123
Define value for property 'artifactId' test-123: :
Define value for property 'z-prop':
{code}
So `package` was p
[GitHub] [maven-ear-plugin] mabrarov opened a new pull request #18: [MEAR-286] Maven project enhancement
mabrarov opened a new pull request #18: URL: https://github.com/apache/maven-ear-plugin/pull/18 * Moved filtering of resources out of run-its maven profile because this filtering is needed not just for integration tests ```bash $ mvn clean install -e -DskipTests && mvn clean verify -e -Prun-its artifact:buildinfo -Dreference.repo=central ... [INFO] --- maven-artifact-plugin:1.0-SNAPSHOT:buildinfo (default-cli) @ maven-ear-plugin --- [WARNING] SCM source tag in buildinfo source.scm.tag=HEAD does not permit rebuilders reproducible source checkout [INFO] Saved info on build to xxx...\maven-ear-plugin\target\maven-ear-plugin-3.1.1-SNAPSHOT.buildinfo [INFO] Checking against reference build from central... [WARNING] Reference buildinfo file not found: it will be generated from downloaded reference artifacts [INFO] Reference build java.version: 1.8 (from MANIFEST.MF Build-Jdk-Spec) [INFO] Reference build os.name: Windows (from pom.properties newline) [INFO] Minimal buildinfo generated from downloaded artifacts: xxx...\maven-ear-plugin\target\reference\maven-ear-plugin-3.1.1-SNAPSHOT.buildinfo [INFO] Reproducible Build output summary: 1 files ok [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 06:27 min [INFO] Finished at: 2020-10-03T20:55:25+03:00 [INFO] ``` * Support of `invoker.it.skip` maven property (can be specified in command line) which can be used to skip integration tests utilizing Maven Invoker Plugin, i.e. to run just integration tests utilizing Maven Failsafe Plugin: ```bash [INFO] --- maven-invoker-plugin:3.2.1:install (integration-test) @ maven-ear-plugin --- [INFO] Installing xxx...\maven-ear-plugin\pom.xml to xxx...\maven-ear-plugin\target\test-classes\m2repo\org\apache\maven\plugins\maven-ear-plugin\3.1.1-SNAPSHOT\maven-ear-plugin-3.1.1-SNAPSHOT.pom [INFO] Installing xxx...\maven-ear-plugin\target\maven-ear-plugin-3.1.1-SNAPSHOT.jar to xxx...\maven-ear-plugin\target\test-classes\m2repo\org\apache\maven\plugins\maven-ear-plugin\3.1.1-SNAPSHOT\maven-ear-plugin-3.1.1-SNAPSHOT.jar Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.1.1/maven-war-plugin-2.1.1.pom Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-war-plugin/2.1.1/maven-war-plugin-2.1.1.pom (6.6 kB at 11 kB/s) ... [INFO] [INFO] --- maven-invoker-plugin:3.2.1:integration-test (integration-test) @ maven-ear-plugin --- [INFO] Skipping invocation per configuration. If this is incorrect, ensure the skipInvocation parameter is not set to true. [INFO] [INFO] --- maven-failsafe-plugin:2.22.2:integration-test (default) @ maven-ear-plugin --- [INFO] [INFO] --- [INFO] T E S T S [INFO] --- [INFO] Running org.apache.maven.plugins.ear.it.EarMojoIT Building: project-001 ... [INFO] Tests run: 87, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 275.704 s - in org.apache.maven.plugins.ear.it.EarMojoIT [INFO] [INFO] Results: [INFO] [INFO] Tests run: 87, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] --- maven-checkstyle-plugin:3.0.0:check (checkstyle-check) @ maven-ear-plugin --- [INFO] There are 3 errors reported by Checkstyle 6.18 with config/maven_checks.xml ruleset. [INFO] Ignored 3 errors, 0 violation remaining. [INFO] [INFO] --- maven-invoker-plugin:3.2.1:verify (integration-test) @ maven-ear-plugin --- [INFO] Skipping invocation per configuration. If this is incorrect, ensure the skipInvocation parameter is not set to true. [INFO] [INFO] --- maven-failsafe-plugin:2.22.2:verify (default) @ maven-ear-plugin --- [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 05:13 min (Wall Clock) [INFO] Finished at: 2020-10-03T20:48:08+03:00 [INFO] ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (ARCHETYPE-612) Required property interactive prompt ordering incorrect when reassigning default for a "core" property
David Hutchison created ARCHETYPE-612:
-
Summary: Required property interactive prompt ordering incorrect
when reassigning default for a "core" property
Key: ARCHETYPE-612
URL: https://issues.apache.org/jira/browse/ARCHETYPE-612
Project: Maven Archetype
Issue Type: Bug
Components: Plugin
Affects Versions: 3.2.0
Reporter: David Hutchison
The interactive archetype project generation attempts to be smart in ordering
required properties so that when a default value for one property includes a
reference to another, they are asked for in the correct order. This also
however tries to ask the "core" properties (groupId, archetypeId, version, and
package) in a fixed order, and any others in alphabetical order, if they do not
have dependencies.
I was trying to setup an archetype with a couple of prompts which would be
referenced in the default values for groupId, archetypeId and package.
Basically attempting to standardise the setup for these based on the
"application" and "database" the repository was for, so we would have:
* groupId: `com.example.${application}.data`
* archetypeId: `${database}`
* package: `com.example.${application}.data.${database}`
When doing this however, the package is prompted for before the value it's
default depends on.
This snippet from archetype-metadata.xml will trigger the issue as a test
{code:java}
com.devwithimagination
test-${a-prop}
${groupId}.${artifactId}.${z-prop}
{code}
Running this archetype interactively will output something like this:
{code:java}
$ mvn archetype:generate -DarchetypeArtifactId=archetype-test
-DarchetypeGroupId=com.devwithimagination.archetypes
[INFO] Generating project in Interactive mode
[INFO] Archetype
[com.devwithimagination.archetypes:archetype-test:1.0-SNAPSHOT] found in
catalog local
[INFO] Using property: groupId = com.devwithimagination
Define value for property 'version' 1.0-SNAPSHOT: :
Define value for property 'package'
com.devwithimagination.archetypes.archetype-test.${z-prop}: :
Define value for property 'a-prop': 123
Define value for property 'artifactId' test-123: :
Define value for property 'z-prop':
{code}
So `package` was prompted for before `artifactId` and `z-prop` which it needed
for the default value. In typing this up I just noticed it used the
`archetypeArtifactId` in the default value instead.
I have got a failing test case for `RequiredPropertyComparatorTest` which shows
the comparator isn't performing the sort correctly.
A possible solution for this could be what ARCHETYPE-443 proposed, and respect
the property order defined in the archetype metadata file. Any "core" required
properties could still be prompted for in their default order, unless the
archetype author had also included them in `archetype-metadata.xml`. With that
change, it would be up to the archetype author to ensure that properties are
correctly ordered. ARCHETYPE-562 points to other issues with this sort.
I have been having a look at making the sort smarter, but so far I've not been
able to keep the name based ordering working while fixing the property
dependency based sort.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-ear-plugin] mabrarov commented on a change in pull request #17: [MEAR-287] Fixed failure when destination directory exists
mabrarov commented on a change in pull request #17:
URL: https://github.com/apache/maven-ear-plugin/pull/17#discussion_r499166379
##
File path: src/test/java/org/apache/maven/plugins/ear/it/EarMojoIT.java
##
@@ -993,4 +993,24 @@ public void testProject087()
{
doTestProject( "project-087", new String[] {
"eartest-ejb-sample-one-1.0.jar", "eartest-ejb-sample-two-1.0.jar" } );
}
+
+/**
+ * Builds WAR and EAR as part of multi-module project twice so that the
2nd build is guaranteed to be performed when
+ * target directories and files exist.
+ * @throws Exception in case of an error.
Review comment:
Well, do you find it appropriate if I remove this useless JavaDoc from
all tests in this file?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (ARCHETYPE-476) Decide what to do with the Archetypes List wiki page
[ https://issues.apache.org/jira/browse/ARCHETYPE-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206795#comment-17206795 ] Herve Boutemy commented on ARCHETYPE-476: - yes, IIRC, MAVENUSER was never migrated given content was not really maintained then nobody took time to organise cleanup and migration > Decide what to do with the Archetypes List wiki page > > > Key: ARCHETYPE-476 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-476 > Project: Maven Archetype > Issue Type: Task > Components: Documentation > Environment: n/a >Reporter: Anders Hammar >Priority: Major > > On the wiki there is an "Archetypes List" page, suggesting that it "holds the > complete list of archetypes (even not hosted at apache)". This is not true > and I don't think it is feasible to keep it updated, not desirable to keep > such a list. In the central repository there is an archetype catalog that > lists all archetypes there which should be, and is, used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-ear-plugin] elharo commented on a change in pull request #17: [MEAR-287] Fixed failure when destination directory exists
elharo commented on a change in pull request #17:
URL: https://github.com/apache/maven-ear-plugin/pull/17#discussion_r499159371
##
File path: src/test/java/org/apache/maven/plugins/ear/it/EarMojoIT.java
##
@@ -993,4 +993,24 @@ public void testProject087()
{
doTestProject( "project-087", new String[] {
"eartest-ejb-sample-one-1.0.jar", "eartest-ejb-sample-two-1.0.jar" } );
}
+
+/**
+ * Builds WAR and EAR as part of multi-module project twice so that the
2nd build is guaranteed to be performed when
+ * target directories and files exist.
+ * @throws Exception in case of an error.
Review comment:
We don't need to be consistent with mistakes.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-6985) Incorrect value for maven.multiModuleProjectDirectory in integration tests
[
https://issues.apache.org/jira/browse/MNG-6985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206732#comment-17206732
]
Hudson commented on MNG-6985:
-
Build unstable in Jenkins: Maven » Maven TLP » maven » MNG-6965 #12
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-6965/12/
> Incorrect value for maven.multiModuleProjectDirectory in integration tests
> --
>
> Key: MNG-6985
> URL: https://issues.apache.org/jira/browse/MNG-6985
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Maarten Mulders
>Priority: Major
> Fix For: 3.7.0
>
>
> The {{newVerifier()}} method in {{AbstractMavenIntegrationTestCase}} creates
> a System Property {{maven.multiModuleProjectDirectory}} and assigns the value
> of the _basedir_. That argument is passed in from the integration test and
> refers to the directory where the Maven invocation takes place (in _Forked_
> mode) or where it is simulated to take place (in _Embedded_ mode).
> For the majority of the cases, this is a valid assumption. However, if the
> test is supposed to run in a child module of a multi-module project, this
> assumption does not hold. Instead, the value of this System Property should
> be determined in the same way as the {{mvn}} / {{mvn.cmd}} scripts do: by
> traversing up the file system until a *.mvn* directory is located.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] pzygielo commented on a change in pull request #367: [MNG-6965] Drop Maven 2 support - stop injecting old plexus-utils
pzygielo commented on a change in pull request #367:
URL: https://github.com/apache/maven/pull/367#discussion_r499156521
##
File path:
maven-core/src/main/java/org/apache/maven/plugin/internal/DefaultPluginDependenciesResolver.java
##
@@ -145,20 +143,19 @@ public DependencyNode resolveCoreExtension( Plugin
plugin, DependencyFilter depe
List
repositories, RepositorySystemSession session )
throws PluginResolutionException
{
-return resolveInternal( plugin, null /* pluginArtifact */,
dependencyFilter, null /* transformer */,
-repositories, session );
+return resolveInternal( plugin, null /* pluginArtifact */,
dependencyFilter, /* transformer */
Review comment:
```suggestion
return resolveInternal( plugin, null /* pluginArtifact */,
dependencyFilter,
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-ear-plugin] mabrarov commented on pull request #17: [MEAR-287] Fixed failure when destination directory exists
mabrarov commented on pull request #17: URL: https://github.com/apache/maven-ear-plugin/pull/17#issuecomment-703117231 @elharo and @hboutemy, I assume MEAR-287 is a major bug making 3.1.0 release of Maven EAR Plugin breaking existing workflows. Could we speedup / force review of this pull request and release Maven EAR Plugin 3.1.1 ASAP? Thank you for your work and efforts. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6965) archetype-packaging.jar:3.1.2 requires org.codehaus.plexus:plexus-utils:jar:1.1
[
https://issues.apache.org/jira/browse/MNG-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206721#comment-17206721
]
Michael Osipov commented on MNG-6965:
-
Pushed an IT branch, down to:
{noformat}
[ERROR] Failures:
[ERROR]
MavenITmng2749ExtensionAvailableToPluginTest>AbstractMavenIntegrationTestCase.runTest:255->testitMNG2749:62
[ERROR] Errors:
[ERROR]
MavenITmng6772NestedImportScopeRepositoryOverride>AbstractMavenIntegrationTestCase.runTest:255->testitInDependency:74
» Verification
[ERROR]
MavenITmng6772NestedImportScopeRepositoryOverride>AbstractMavenIntegrationTestCase.runTest:255->testitInProject:57
» Verification
[INFO]
[ERROR] Tests run: 849, Failures: 1, Errors: 2, Skipped: 0
{noformat}
> archetype-packaging.jar:3.1.2 requires
> org.codehaus.plexus:plexus-utils:jar:1.1
> ---
>
> Key: MNG-6965
> URL: https://issues.apache.org/jira/browse/MNG-6965
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 3.6.0, 3.6.3
> Environment: Win7, Win10, at least one variant of Linux (not sure
> which)
>Reporter: Mark Nolan
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Labels: archetype
> Fix For: 3.7.0
>
> Attachments: pom.xml
>
>
> A simple minimal archetype pom following the manual pages downloads
> plexus-utils 1.1, even though it is not (apparently) declared anywhere. This
> version is banned at my organization (edited to add: due to vulnerabilities),
> meaning such a pom always fails.
>
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> test
> test
> 0.0.1-SNAPSHOT
> maven-archetype
> test
>
>
>
> org.apache.maven.archetype
> archetype-packaging
> 3.1.2
>
>
>
>
>
> org.apache.maven.plugins
> maven-archetype-plugin
> 3.1.2
>
>
>
>
>
> {code}
> Running any goal, such as mvn -X clean, produces the following before the
> goal is executed:
> {code}
> [DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=952800,
> ConflictMarker.markTime=586900, ConflictMarker.nodeCount=1,
> ConflictIdSorter.graphTime=549200, ConflictIdSorter.topsortTime=586700,
> ConflictIdSorter.conflictIdCount=1, ConflictIdSorter.conflictIdCycleCount=0,
> ConflictResolver.totalTime=3313100, ConflictResolver.conflictItemCount=1,
> DefaultDependencyCollector.collectTime=66890900,
> DefaultDependencyCollector.transformTime=8523500}
> [DEBUG] org.apache.maven.archetype:archetype-packaging:jar:3.1.2:
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:1.1:runtime
> {code}
>
> As far as I can see, there is no declared dependency on plexus-utils:1.1.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-476) Decide what to do with the Archetypes List wiki page
[ https://issues.apache.org/jira/browse/ARCHETYPE-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206715#comment-17206715 ] Michael Boyles commented on ARCHETYPE-476: -- It used to be [http://docs.codehaus.org/display/MAVENUSER/Archetypes+List] but it's dead now. According to [this|https://cwiki.apache.org/confluence/display/MAVEN/Wiki+migration] the main "MAVEN" wiki was migrated, but MAVENUSER remained on Codehaus. It's gone now though. Maybe [~hboutemy] knows what happened to MAVENUSER? If it's been lost, we should close this ticket > Decide what to do with the Archetypes List wiki page > > > Key: ARCHETYPE-476 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-476 > Project: Maven Archetype > Issue Type: Task > Components: Documentation > Environment: n/a >Reporter: Anders Hammar >Priority: Major > > On the wiki there is an "Archetypes List" page, suggesting that it "holds the > complete list of archetypes (even not hosted at apache)". This is not true > and I don't think it is feasible to keep it updated, not desirable to keep > such a list. In the central repository there is an archetype catalog that > lists all archetypes there which should be, and is, used instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MCHECKSTYLE-334) "mvn install site" works differently than "mvn install" or "mvn site"
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206710#comment-17206710
]
Michael Boyles edited comment on MCHECKSTYLE-334 at 10/3/20, 2:20 PM:
--
Seems like this should be closed.
# Exclusion ant pattern is wrong
# There is no reason to call mvn install site. Just call mvn site
# better way to exclude generated source is set to
${project.build.sourceDirectory}
was (Author: michaelboyles):
Seems like this should be closed.
# Exclusion ant pattern is wrong
# There is no reason to call mvn install site. Just call mvn site
# target dir where generated sources exist is not included without some funky
> "mvn install site" works differently than "mvn install" or "mvn site"
> -
>
> Key: MCHECKSTYLE-334
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-334
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:checkstyle
>Affects Versions: 2.17
> Environment: both windows/linux
>Reporter: Frank Luo
>Priority: Major
> Labels: maven
>
> I am trying to ignore files in the dir of "target/generated-sources". So I
> have "**/generated-sources/**/*" in configure.
> When I do "mvn install" or "mvn site", checkstyle has no complains.
> But when I run "mvn install site", I got a ton of complains from
> "generated-sources" dir.
> Here is a sample:
> C:\work\project\atlas\trunk\atlas_reformat_engine\target\generated-sources\config\com\merkleinc\atlas\reformat\config\Rule.java:157:
> error: Do not use Windows line endings
> Please help
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MCHECKSTYLE-334) "mvn install site" works differently than "mvn install" or "mvn site"
[ https://issues.apache.org/jira/browse/MCHECKSTYLE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206710#comment-17206710 ] Michael Boyles commented on MCHECKSTYLE-334: Seems like this should be closed. # Exclusion ant pattern is wrong # There is no reason to call mvn install site. Just call mvn site # target dir where generated sources exist is not included without some funky > "mvn install site" works differently than "mvn install" or "mvn site" > - > > Key: MCHECKSTYLE-334 > URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-334 > Project: Maven Checkstyle Plugin > Issue Type: Bug > Components: checkstyle:checkstyle >Affects Versions: 2.17 > Environment: both windows/linux >Reporter: Frank Luo >Priority: Major > Labels: maven > > I am trying to ignore files in the dir of "target/generated-sources". So I > have "**/generated-sources/**/*" in configure. > When I do "mvn install" or "mvn site", checkstyle has no complains. > But when I run "mvn install site", I got a ton of complains from > "generated-sources" dir. > Here is a sample: > C:\work\project\atlas\trunk\atlas_reformat_engine\target\generated-sources\config\com\merkleinc\atlas\reformat\config\Rule.java:157: > error: Do not use Windows line endings > Please help -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6983) Plugin key can get out of sync with artifactId and groupId
[
https://issues.apache.org/jira/browse/MNG-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206709#comment-17206709
]
Hudson commented on MNG-6983:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » master #29
See
https://ci-builds.apache.org/job/Maven/job/maven-box/job/maven/job/master/29/
> Plugin key can get out of sync with artifactId and groupId
> --
>
> Key: MNG-6983
> URL: https://issues.apache.org/jira/browse/MNG-6983
> Project: Maven
> Issue Type: Bug
> Components: core, Plugins and Lifecycle
>Affects Versions: 3.6.3
>Reporter: Paul Pazderski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: pluginNotExecuted.zip
>
>
> I have a project build with maven where some maven plugins are not executed
> without any warning or error shown in output. I was able to reproduce the
> issue with a minimal example. (see attachment)
> The expected result of this example is to get the one source file compiled if
> you invoke {{mvn compile}}.
> If I run this example using Maven 3.6.3 the following output appears:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:child
> >--
> [INFO] Building child 0.0.1-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ child
> ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> [...]\pluginNotExecuted\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child ---
> [INFO] No sources to compile
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.644 s
> [INFO] Finished at: [...]
> [INFO]
>
> {noformat}
> Notice that there is no execution of the build-helper-maven-plugin (and as
> consequence no source compiled) and no indication why it is missing.
> From what I've found the problem seem to be the usage of variable in the
> plugins groupId. If you replace either the variable in parent- or child-pom
> with the actual value the build shows a warning
> {noformat}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.example:child:jar:0.0.1-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 16, column 21
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {noformat}
> If you replace both variables with the actual value everything works as
> expected.
>
> I investigated the problem further and will provide more details with a pull
> request for a possible fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6983) Plugin key can get out of sync with artifactId and groupId
[
https://issues.apache.org/jira/browse/MNG-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6983.
---
Fix Version/s: (was: 3.7.0-candidate)
3.7.0
Resolution: Fixed
Fixed with
[39641ac803e17360df40288aaeb40ea0c5ccd77d|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=39641ac803e17360df40288aaeb40ea0c5ccd77d].
> Plugin key can get out of sync with artifactId and groupId
> --
>
> Key: MNG-6983
> URL: https://issues.apache.org/jira/browse/MNG-6983
> Project: Maven
> Issue Type: Bug
> Components: core, Plugins and Lifecycle
>Affects Versions: 3.6.3
>Reporter: Paul Pazderski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: pluginNotExecuted.zip
>
>
> I have a project build with maven where some maven plugins are not executed
> without any warning or error shown in output. I was able to reproduce the
> issue with a minimal example. (see attachment)
> The expected result of this example is to get the one source file compiled if
> you invoke {{mvn compile}}.
> If I run this example using Maven 3.6.3 the following output appears:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:child
> >--
> [INFO] Building child 0.0.1-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ child
> ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> [...]\pluginNotExecuted\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child ---
> [INFO] No sources to compile
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.644 s
> [INFO] Finished at: [...]
> [INFO]
>
> {noformat}
> Notice that there is no execution of the build-helper-maven-plugin (and as
> consequence no source compiled) and no indication why it is missing.
> From what I've found the problem seem to be the usage of variable in the
> plugins groupId. If you replace either the variable in parent- or child-pom
> with the actual value the build shows a warning
> {noformat}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.example:child:jar:0.0.1-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 16, column 21
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {noformat}
> If you replace both variables with the actual value everything works as
> expected.
>
> I investigated the problem further and will provide more details with a pull
> request for a possible fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] asfgit closed pull request #372: [MNG-6983] Plugin key can get out of sync with artifactId and groupId
asfgit closed pull request #372: URL: https://github.com/apache/maven/pull/372 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michaelboyles opened a new pull request #73: [MRESOLVER-104] - maven-resolver-demo-maven-plugin uses reserved artifactId
michaelboyles opened a new pull request #73: URL: https://github.com/apache/maven-resolver/pull/73 https://issues.apache.org/jira/browse/MRESOLVER-104 ``` [INFO] — maven-plugin-plugin:3.5.2:descriptor (default-descriptor) @ maven-resolver-demo-maven-plugin — [ERROR] Artifact Ids of the format maven-___-plugin are reserved for plugins in the Group Id org.apache.maven.plugins Please change your artifactId to the format ___-maven-plugin In the future this error will break the build. ``` Removed `maven-` prefix, because it's reserved by specific group ids This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-6983) Plugin key can get out of sync with artifactId and groupId
[
https://issues.apache.org/jira/browse/MNG-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6983:
Summary: Plugin key can get out of sync with artifactId and groupId (was:
Plugin not executed when using pluginManagement and variable in groupId)
> Plugin key can get out of sync with artifactId and groupId
> --
>
> Key: MNG-6983
> URL: https://issues.apache.org/jira/browse/MNG-6983
> Project: Maven
> Issue Type: Bug
> Components: core, Plugins and Lifecycle
>Affects Versions: 3.6.3
>Reporter: Paul Pazderski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: pluginNotExecuted.zip
>
>
> I have a project build with maven where some maven plugins are not executed
> without any warning or error shown in output. I was able to reproduce the
> issue with a minimal example. (see attachment)
> The expected result of this example is to get the one source file compiled if
> you invoke {{mvn compile}}.
> If I run this example using Maven 3.6.3 the following output appears:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:child
> >--
> [INFO] Building child 0.0.1-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ child
> ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> [...]\pluginNotExecuted\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child ---
> [INFO] No sources to compile
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.644 s
> [INFO] Finished at: [...]
> [INFO]
>
> {noformat}
> Notice that there is no execution of the build-helper-maven-plugin (and as
> consequence no source compiled) and no indication why it is missing.
> From what I've found the problem seem to be the usage of variable in the
> plugins groupId. If you replace either the variable in parent- or child-pom
> with the actual value the build shows a warning
> {noformat}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.example:child:jar:0.0.1-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 16, column 21
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {noformat}
> If you replace both variables with the actual value everything works as
> expected.
>
> I investigated the problem further and will provide more details with a pull
> request for a possible fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-6983) Plugin not executed when using pluginManagement and variable in groupId
[
https://issues.apache.org/jira/browse/MNG-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6983:
---
Assignee: Michael Osipov
> Plugin not executed when using pluginManagement and variable in groupId
> ---
>
> Key: MNG-6983
> URL: https://issues.apache.org/jira/browse/MNG-6983
> Project: Maven
> Issue Type: Bug
> Components: core, Plugins and Lifecycle
>Affects Versions: 3.6.3
>Reporter: Paul Pazderski
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
> Attachments: pluginNotExecuted.zip
>
>
> I have a project build with maven where some maven plugins are not executed
> without any warning or error shown in output. I was able to reproduce the
> issue with a minimal example. (see attachment)
> The expected result of this example is to get the one source file compiled if
> you invoke {{mvn compile}}.
> If I run this example using Maven 3.6.3 the following output appears:
> {noformat}
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:child
> >--
> [INFO] Building child 0.0.1-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ child
> ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> [...]\pluginNotExecuted\src\main\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child ---
> [INFO] No sources to compile
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.644 s
> [INFO] Finished at: [...]
> [INFO]
>
> {noformat}
> Notice that there is no execution of the build-helper-maven-plugin (and as
> consequence no source compiled) and no indication why it is missing.
> From what I've found the problem seem to be the usage of variable in the
> plugins groupId. If you replace either the variable in parent- or child-pom
> with the actual value the build shows a warning
> {noformat}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for org.example:child:jar:0.0.1-SNAPSHOT
> [WARNING] 'build.plugins.plugin.version' for
> org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 16, column 21
> [WARNING]
> [WARNING] It is highly recommended to fix these problems because they
> threaten the stability of your build.
> [WARNING]
> [WARNING] For this reason, future Maven versions might no longer support
> building such malformed projects.
> [WARNING]
> {noformat}
> If you replace both variables with the actual value everything works as
> expected.
>
> I investigated the problem further and will provide more details with a pull
> request for a possible fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6983) Plugin not executed when using pluginManagement and variable in groupId
[
https://issues.apache.org/jira/browse/MNG-6983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6983:
Description:
I have a project build with maven where some maven plugins are not executed
without any warning or error shown in output. I was able to reproduce the issue
with a minimal example. (see attachment)
The expected result of this example is to get the one source file compiled if
you invoke {{mvn compile}}.
If I run this example using Maven 3.6.3 the following output appears:
{noformat}
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.example:child >--
[INFO] Building child 0.0.1-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ child ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
[...]\pluginNotExecuted\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child ---
[INFO] No sources to compile
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.644 s
[INFO] Finished at: [...]
[INFO]
{noformat}
Notice that there is no execution of the build-helper-maven-plugin (and as
consequence no source compiled) and no indication why it is missing.
>From what I've found the problem seem to be the usage of variable in the
>plugins groupId. If you replace either the variable in parent- or child-pom
>with the actual value the build shows a warning
{noformat}
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.example:child:jar:0.0.1-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 16, column 21
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
{noformat}
If you replace both variables with the actual value everything works as
expected.
I investigated the problem further and will provide more details with a pull
request for a possible fix.
was:
I have a project build with maven where some maven plugins are not executed
without any warning or error shown in output.
I was could reproduce the issue with a minimal example. (see attachment)
The expected result of this example is to get the one source file compiled if
you invoke {{mvn compile}}.
If I run this example using Maven 3.6.3 the following output appears:
{noformat}
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.example:child >--
[INFO] Building child 0.0.1-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ child ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
[...]\pluginNotExecuted\src\main\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child ---
[INFO] No sources to compile
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.644 s
[INFO] Finished at: [...]
[INFO]
{noformat}
Notice that there is no execution of the build-helper-maven-plugin (and as
consequence no source compiled) and no indication why it is missing.
>From what I've found the problem seem to be the usage of variable in the
>plugins groupId. If you replace either the variable in parent- or child-pom
>with the actual value the build shows a warning
{noformat}
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
org.example:child:jar:0.0.1-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for
org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 16, column 21
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
{noformat}
If you replace both variables with the actual value everything works as
expected.
I investigated the problem further and will provide more details with a pull
request for a possible fix.
> Plugin not executed when using pluginManagement and variable in grou
[jira] [Comment Edited] (MNG-6784) Create correct SHA512 content
[
https://issues.apache.org/jira/browse/MNG-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206649#comment-17206649
]
Michael Osipov edited comment on MNG-6784 at 10/3/20, 9:11 AM:
---
Can we close this? There is no canonical checksum output format.
was (Author: michael-o):
Can we close this?
> Create correct SHA512 content
> -
>
> Key: MNG-6784
> URL: https://issues.apache.org/jira/browse/MNG-6784
> Project: Maven
> Issue Type: Improvement
> Components: Deployment
>Affects Versions: 3.6.2
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.7.0-candidate, wontfix-candidate
>
>
> Currently the created SHA512 which is used for the distribution area contains
> only the checksum but not the filename which results in bad output if the
> checksums being checked via command line tool:
> {code}
> $ shasum -c apache-maven-3.2.5-bin.tar.gz.sha512
> $ shasum: apache-maven-3.2.5-bin.tar.gz.sha512: no properly formatted SHA
> checksum lines found
> {code}
> The checksum should be enhanced to support that correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6994) Clarify remote repository resolution order
[
https://issues.apache.org/jira/browse/MNG-6994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206650#comment-17206650
]
Konrad Windszus commented on MNG-6994:
--
The order of the profiles is determined by
{{org.apache.maven.model.profile.ProfileModelMerger}} which calls
{{mergeModelBase}} with the third argument being {{true}}. Profiles are
therefore processed in declaration order, but their elements are always added
first ({{sourceDominant = true}}). Therefore later profiles will
overwrite/prepend elements of earlier profiles.
> Clarify remote repository resolution order
> --
>
> Key: MNG-6994
> URL: https://issues.apache.org/jira/browse/MNG-6994
> Project: Maven
> Issue Type: Improvement
> Components: Documentation: General
>Reporter: Konrad Windszus
>Priority: Major
>
> It is possible to declare remote repositories in {{settings.xml}} and
> {{pom.xml}}. While for the {{settings.xml}} it has to be given in a profile,
> for {{pom.xml}} it can be given in the top-level {{repositories}} element as
> well as in profiles. The order in which an artifact is tried to be resolved
> from the different remote repo is sometimes crucial to know (e.g. to speed up
> build times by first checking against remote repos having most of the
> artifacts like Maven Central)
> It would be nice to document this in
> https://maven.apache.org/guides/introduction/introduction-to-repositories.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6784) Create correct SHA512 content
[
https://issues.apache.org/jira/browse/MNG-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6784:
Fix Version/s: wontfix-candidate
> Create correct SHA512 content
> -
>
> Key: MNG-6784
> URL: https://issues.apache.org/jira/browse/MNG-6784
> Project: Maven
> Issue Type: Improvement
> Components: Deployment
>Affects Versions: 3.6.2
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.7.0-candidate, wontfix-candidate
>
>
> Currently the created SHA512 which is used for the distribution area contains
> only the checksum but not the filename which results in bad output if the
> checksums being checked via command line tool:
> {code}
> $ shasum -c apache-maven-3.2.5-bin.tar.gz.sha512
> $ shasum: apache-maven-3.2.5-bin.tar.gz.sha512: no properly formatted SHA
> checksum lines found
> {code}
> The checksum should be enhanced to support that correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6784) Create correct SHA512 content
[
https://issues.apache.org/jira/browse/MNG-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206649#comment-17206649
]
Michael Osipov commented on MNG-6784:
-
Can we close this?
> Create correct SHA512 content
> -
>
> Key: MNG-6784
> URL: https://issues.apache.org/jira/browse/MNG-6784
> Project: Maven
> Issue Type: Improvement
> Components: Deployment
>Affects Versions: 3.6.2
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.7.0-candidate, wontfix-candidate
>
>
> Currently the created SHA512 which is used for the distribution area contains
> only the checksum but not the filename which results in bad output if the
> checksums being checked via command line tool:
> {code}
> $ shasum -c apache-maven-3.2.5-bin.tar.gz.sha512
> $ shasum: apache-maven-3.2.5-bin.tar.gz.sha512: no properly formatted SHA
> checksum lines found
> {code}
> The checksum should be enhanced to support that correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
