Re: [PR] [MPOM-429] Support develop with JDK 21 (palantirJavaFormat update) [maven-parent]
tisonkun commented on PR #135: URL: https://github.com/apache/maven-parent/pull/135#issuecomment-1746462514 @slawekjaranowski I encountered it again and remembered. I met this issue from Apache Curator who inherited this pom. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6661) Override project.build.directory via user property
[
https://issues.apache.org/jira/browse/MNG-6661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771778#comment-17771778
]
Björn Michael commented on MNG-6661:
A user property to set {{project.build.directory}} would be very useful.
The existing workarounds via custom profile and self-defined property are
described at SO [Maven: How to change path to target directory from command
line?|https://stackoverflow.com/a/3908061]
but it requires touching the POM of each project.
On the other hand, a similar user property to override the local maven
repository path exists {{-Dmaven.repo.local=/tmp/build-from-scratch}} so why
not for the build directory?
h3. Usage examples
* Build tools can specify a different build directory via CLI e.g. Jenkins
* Troubleshooting - create a fresh build in a different directory and compare
the outputs of both builds
* User properties can be set via settings.xml i.e. project POM files aren't
modified. See below
This should work after introducing the user propery: use a different build
directory for Eclipse IDE defined in *settings.xml* (inspired by
[jetcd|https://github.com/etcd-io/jetcd/commit/450c0dd9afd154b80db7f37e00c1ff462eb2fdb9#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8])
{noformat}
eclipse-ide
m2e.version
${project.basedir}/target-eclipse
{noformat}
> Override project.build.directory via user property
> --
>
> Key: MNG-6661
> URL: https://issues.apache.org/jira/browse/MNG-6661
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Sergey Ponomarev
>Assignee: Robert Scholte
>Priority: Minor
>
> I would like to improve a build speed of a big project. The project uses a
> lot of IO operation during a build. So I decided to put all /target
> directories into RAM disk while keeping sources on a hard drive.
> I mounted a RAM disk to /mnt/ramdisk and created a profile:
> {code:xml}
>
>
> true
>
> ramDisk
>
>
> /mnt/ramdisk/${project.groupId}/${project.artifactId}/target
>
>
> {code}
> In fact this is an equivalent of specifying -Dproject.build.directory
> But unfortunately this doesn't work because the property here (i.e. "user
> property") is ignored.
> To make it working I should add into pom.xml this:
> {code}
>
> ${project.build.directory}
> {code}
> I.e. explicitly reuse the user property project.build.directory as
> configuration.
> Don't be confused, we can call the user property anyhow e.g. ${ram_dir} but I
> just wan't to reuse existing property.
> I found a ticket that looks similar
> https://issues.apache.org/jira/browse/MNG-2598 but this is another story.
> So could we implement this?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSKINS-237] Rework skin for new site model [maven-fluido-skin]
michael-o commented on code in PR #56:
URL: https://github.com/apache/maven-fluido-skin/pull/56#discussion_r1345620984
##
src/it/mskins-28/src/site/site.xml:
##
@@ -1,56 +1,58 @@
-
-
-
-
-http://maven.apache.org/DECORATION/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xsi:schemaLocation="http://maven.apache.org/DECORATION/1.1.0
http://maven.apache.org/xsd/decoration-1.1.0.xsd";
- name="${skinName}">
-
-
-${skinGroupId}
-${skinArtifactId}
-${skinVersion}
-
-
-
-
- https://maven.apache.org/skins/maven-fluido-skin/index.html"; />
- https://maven.apache.org/skins/maven-fluido-skin/ITs.html"; />
-
-
-
-
-
-
-
-
-http://maven.apache.org/"/>
-
-http://maven.apache.org/"/>
-
-http://maven.apache.org/"/>
-http://maven.apache.org/"/>
-http://maven.apache.org/"/>
-
-
-
-
+
+
+
+
+http://maven.apache.org/DECORATION/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/DECORATION/1.1.0
http://maven.apache.org/xsd/decoration-1.1.0.xsd";
+ name="${skinName}">
+
+
+${skinGroupId}
+${skinArtifactId}
+${skinVersion}
+
+
+
+
+ https://maven.apache.org/skins/maven-fluido-skin/index.html"; />
+ https://maven.apache.org/skins/maven-fluido-skin/ITs.html"; />
+
+
+
+
+
+
+
+
+http://maven.apache.org/"/>
+
+http://maven.apache.org/"/>
+
+http://maven.apache.org/"/>
+http://maven.apache.org/"/>
+http://maven.apache.org/"/>
+
+
+
+
+
+
Review Comment:
This affects only this single file, do you still want me to try to "fix"
previos LS?
##
src/it/mskins-28/src/site/site.xml:
##
@@ -1,56 +1,58 @@
-
-
-
-
-http://maven.apache.org/DECORATION/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xsi:schemaLocation="http://maven.apache.org/DECORATION/1.1.0
http://maven.apache.org/xsd/decoration-1.1.0.xsd";
- name="${skinName}">
-
-
-${skinGroupId}
-${skinArtifactId}
-${skinVersion}
-
-
-
-
- https://maven.apache.org/skins/maven-fluido-skin/index.html"; />
- https://maven.apache.org/skins/maven-fluido-skin/ITs.html"; />
-
-
-
-
-
-
-
-
-http://maven.apache.org/"/>
-
-http://maven.apache.org/"/>
-
-http://maven.apache.org/"/>
-http://maven.apache.org/"/>
-http://maven.apache.org/"/>
-
-
-
-
+
+
+
+
+http://maven.apache.org/DECORATION/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xsi:schemaLocation="http://maven.apache.org/DECORATION/1.1.0
http://maven.apache.org/xsd/decoration-1.1.0.xsd";
+ name="${skinName}">
+
+
+${skinGroupId}
+${skinArtifactId}
+${skinVersion}
+
+
+
+
+ https://maven.apache.org/skins/maven-fluido-skin/index.html"; />
+ https://maven.apache.org/skins/maven-fluido-skin/ITs.html"; />
+
+
+
+
+
+
+
+
+http://maven.apache.org/"/>
+
+http://maven.apache.org/"/>
+
+http://maven.apache.org/"/>
+http://maven.apache.org/"/>
+http://maven.apache.org/"/>
+
+
+
+
+
+
Review Comment:
This affects only this single file, do you still want me to try to "fix"
previous LS?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSKINS-237) Rework skin for new site model
[
https://issues.apache.org/jira/browse/MSKINS-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771820#comment-17771820
]
ASF GitHub Bot commented on MSKINS-237:
---
michael-o commented on code in PR #56:
URL: https://github.com/apache/maven-fluido-skin/pull/56#discussion_r1345620984
##
src/it/mskins-28/src/site/site.xml:
##
@@ -1,56 +1,58 @@
-
-
-
-
-http://maven.apache.org/DECORATION/1.1.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xsi:schemaLocation="http://maven.apache.org/DECORATION/1.1.0
http://maven.apache.org/xsd/decoration-1.1.0.xsd";
- name="${skinName}">
-
-
-${skinGroupId}
-${skinArtifactId}
-${skinVersion}
-
-
-
-
- https://maven.apache.org/skins/maven-fluido-skin/index.html"; />
- https://maven.apache.org/skins/maven-fluido-skin/ITs.html"; />
-
-
-
-
-
-
- Rework skin for new site model
> --
>
> Key: MSKINS-237
> URL: https://issues.apache.org/jira/browse/MSKINS-237
> Project: Maven Skins
> Issue Type: Task
> Components: Fluido Skin
>Affects Versions: fluido-2.0.0-M7
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: fluido-2.0.0-M8
>
>
> With DOXIASITETOOLS-311 a new, streamlined site model will be introduced. The
> skin needs to adapt to the new changes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MDEP-808] restrict dependency analysis by group [maven-dependency-plugin]
elharo commented on code in PR #218: URL: https://github.com/apache/maven-dependency-plugin/pull/218#discussion_r1345651208 ## src/site/apt/examples/control-dependencies-under-dependency-analysis.apt.vm: ## @@ -57,6 +62,11 @@ Exclude dependencies from dependency analysis true + + + +com.google.code.findbugs Review Comment: includeDependency --> groupId ## src/site/apt/examples/control-dependencies-under-dependency-analysis.apt.vm: ## @@ -37,6 +37,11 @@ Exclude dependencies from dependency analysis The plugin can then be configured to ignore dependencies that are "declared but unused", "undeclared but used", and "non-test scoped" in selected list or in all simultaneously. + + Another case is when mature projects have accumulated superfluous dependencies or + relied upon transitivity for their dependencies. Where fixing all the dependency + problems up-front is not viable the plugin can be configured to only raise Review Comment: comma after viable ## src/site/apt/examples/control-dependencies-under-dependency-analysis.apt.vm: ## @@ -37,6 +37,11 @@ Exclude dependencies from dependency analysis The plugin can then be configured to ignore dependencies that are "declared but unused", "undeclared but used", and "non-test scoped" in selected list or in all simultaneously. + + Another case is when mature projects have accumulated superfluous dependencies or + relied upon transitivity for their dependencies. Where fixing all the dependency + problems up-front is not viable the plugin can be configured to only raise + warnings for dependencies meeting "include" criteria. Review Comment: This needs to be expanded. Based solely on this text — that is, without reading the code or the JIRA — I do not know which dependencies are and are not checked. ## src/site/apt/examples/control-dependencies-under-dependency-analysis.apt.vm: ## @@ -37,6 +37,11 @@ Exclude dependencies from dependency analysis The plugin can then be configured to ignore dependencies that are "declared but unused", "undeclared but used", and "non-test scoped" in selected list or in all simultaneously. + + Another case is when mature projects have accumulated superfluous dependencies or + relied upon transitivity for their dependencies. Where fixing all the dependency + problems up-front is not viable the plugin can be configured to only raise + warnings for dependencies meeting "include" criteria. Review Comment: This needs to be expanded. Based solely on this text — that is, without reading the code or the JIRA — I do not know which dependencies are and are not checked. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771828#comment-17771828
]
ASF GitHub Bot commented on MDEP-808:
-
elharo commented on code in PR #218:
URL:
https://github.com/apache/maven-dependency-plugin/pull/218#discussion_r1345651208
##
src/site/apt/examples/control-dependencies-under-dependency-analysis.apt.vm:
##
@@ -57,6 +62,11 @@ Exclude dependencies from dependency analysis
true
+
+ Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MDEP-808] restrict dependency analysis by group [maven-dependency-plugin]
elharo commented on code in PR #218: URL: https://github.com/apache/maven-dependency-plugin/pull/218#discussion_r1345651208 ## src/site/apt/examples/control-dependencies-under-dependency-analysis.apt.vm: ## @@ -57,6 +62,11 @@ Exclude dependencies from dependency analysis true + + + +com.google.code.findbugs Review Comment: includeDependency --> groupId Instead of a pattern here,= separate groupId and artifactId elements are simpler. Maybe includeDependencies --> analyze or check. I'm not sure. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771829#comment-17771829
]
ASF GitHub Bot commented on MDEP-808:
-
elharo commented on code in PR #218:
URL:
https://github.com/apache/maven-dependency-plugin/pull/218#discussion_r1345651208
##
src/site/apt/examples/control-dependencies-under-dependency-analysis.apt.vm:
##
@@ -57,6 +62,11 @@ Exclude dependencies from dependency analysis
true
+
+ Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Remove dependency on plexus [maven-jar-plugin]
elharo merged PR #63: URL: https://github.com/apache/maven-jar-plugin/pull/63 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771831#comment-17771831
]
Elliotte Rusty Harold commented on MDEP-808:
There are some cases where this feature might help with dependencies that the
analyzer does not correctly analyze, e.g. because they're loaded via reflection
or something like that. SLF4J comes to mind. OTOH when these are just bugs in
the analyzer, maybe that's where things should be fixed.
> Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Major
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] skip packaging [maven-jar-plugin]
elharo commented on code in PR #62:
URL: https://github.com/apache/maven-jar-plugin/pull/62#discussion_r1345667634
##
src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java:
##
@@ -286,6 +292,10 @@ public void execute() throws MojoExecutionException {
+ "Please see the >>Major Version Upgrade to version
3.0.0<< on the plugin site.");
}
+if (skipJar) {
+ getLog().info("Skipping packaging ");
Review Comment:
This doesn't seem to skip anything
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Updated] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold updated MDEP-808:
---
Priority: Minor (was: Major)
> Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Minor
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771839#comment-17771839
]
Elliotte Rusty Harold commented on MDEP-808:
Looking at this again, I'm seeing that everything you want to do is already
possible. You simply want a switch to change from analyze by default to ignore
by default. That's pretty small beans. I'm very tempted to close this as won't
fix to avoid adding complexity to the code and docs unless there's a real need
I'm not seeing.
> Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Minor
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis updated MDEP-808:
-
Attachment: pluginManagementPreMDEP-808.txt
> Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Attachments: pluginManagementPreMDEP-808.txt
>
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis updated MDEP-808:
-
Attachment: pluginManagementPostMDEP-808.txt
> Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Attachments: pluginManagementPostMDEP-808.txt,
> pluginManagementPreMDEP-808.txt
>
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SCM-1013) Add skip parameter to all goals
Richard Eckart de Castilho created SCM-1013: --- Summary: Add skip parameter to all goals Key: SCM-1013 URL: https://issues.apache.org/jira/browse/SCM-1013 Project: Maven SCM Issue Type: New Feature Components: maven-plugin Reporter: Richard Eckart de Castilho Currently, the only way to conditionally execute this plugin is by either putting it into a profile or by putting it into a conditionally included submodule. But profile-based activation may not be flexible enough and putting it into a conditionally included submodule is quite inconvenient. Most Maven goals have a "skip" parameter that can be used to control them. It would be good if the Maven SVM goals would follow that approach as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771907#comment-17771907
]
Francis commented on MDEP-808:
--
[~elharo]
{quote}
Looking at this again, I'm seeing that everything you want to do is already
possible. You simply want a switch to change from analyze by default to ignore
by default. That's pretty small beans. I'm very tempted to close this as won't
fix to avoid adding complexity to the code and docs unless there's a real need
I'm not seeing.
{quote}
I think the best I can do is to elaborate the need that arose in our
organisation and provide a bit more context over that already stated in the
description.
We have a monobuild that builds over a large monorepo and we want to ensure the
dependency graph is as small as possible. This maximises the throughput in the
monobuild and also ensures that the various tools that developers use to
analyse the dependency graph don't present any superfluous information. We run
analyse upon ~800 artifacts within that monobuild (which is a subset of the
total artifacts, we have an initiative scheduled to further expand the usage).
Currently the pluginManagement block in the parent pom that sits of the
monobuild looks something like this (lightly edited for public consumption):
[^pluginManagementPreMDEP-808.txt]
With the code under this issue, it simplifies to:
[^pluginManagementPostMDEP-808.txt]
So yes, we are already able to achieve the desired functional result, but it
leaves an ugly mess in the pom. Why don't we simply expand the scope of analyze
to run over all dependencies at our organisation and be done with it?
Introducing analyze to the extent that it has been now took ~50 days of
developer effort, and we don't think we'll get the same benefits from expanding
it further to include all dependencies.
[Lifting from the
PR|https://github.com/apache/maven-dependency-plugin/pull/218#pullrequestreview-1657317011]:
{quote}
I'm still skeptical of this feature. What is the problem solved by not warning
on all unused dependencies? Unused dependencies don't break the build. If
someone can't fix them all right now, so what?
{quote}
We *_do_* want unused dependencies to break the build so we *_do_* warn on
them. We've found that is the only really effective way to ensure that unused
dependencies are cleared up, preventing eventual drift such that over time our
monobuild slows down and our graphing tools start lying to our developers about
the actual state of the dependencies.
That's the best case I can make for this. That MDEP-885 has been logged
demonstrates that our use-case isn't the only use-case (but admittedly only
proves there's at least two use-cases).
There are still some outstanding review comments on the PR, but I think it best
if I stop noodling on the PR until the maintainers are sold on the case for
this change, otherwise that's more effort on something that isn't long for this
world.
> Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Attachments: pluginManagementPostMDEP-808.txt,
> pluginManagementPreMDEP-808.txt
>
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> spec
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771909#comment-17771909 ] ASF GitHub Bot commented on MNG-7848: - elharo commented on PR #1266: URL: https://github.com/apache/maven/pull/1266#issuecomment-1747235075 I clicked the button to rerun the failed jobs > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap & Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-7848] Add Jenkinsfile.s390x for Jenkins CI on s390x [maven]
elharo commented on PR #1266: URL: https://github.com/apache/maven/pull/1266#issuecomment-1747235075 I clicked the button to rerun the failed jobs -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis updated MDEP-808:
-
Attachment: (was: pluginManagementPreMDEP-808.txt)
> Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Attachments: pluginManagementPostMDEP-808.txt,
> pluginManagementPreMDEP-808.txt
>
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis updated MDEP-808:
-
Attachment: pluginManagementPreMDEP-808.txt
> Restrict dependency analysis by group id
>
>
> Key: MDEP-808
> URL: https://issues.apache.org/jira/browse/MDEP-808
> Project: Maven Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Affects Versions: 3.3.0
>Reporter: Francis
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Attachments: pluginManagementPostMDEP-808.txt,
> pluginManagementPreMDEP-808.txt
>
>
> On our project we have elected to run the dependency analysis only over our
> inhouse authored dependencies. We want to run it for our groupId only.
> Unfortunately the project is too mature and the poms would become too bloated
> to run dependency analysis over all the dependencies. Even if this were
> feasible, the real value in our project is having minimally declared
> dependencies over the dependencies we author.
> In order to achieve running the dependency analysis over our {{groupId}}
> only,
> we've excluded third party dependencies by generous use of
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}}, effectively only building a path to
> our groupId. If the {{groupId}} is {{com.artic}} then we've got a long list
> of exclusions, for example:
> {noformat}
> ...
>
>
> a*:*:*
> b*:*:*
>
>
>
> d*:*:*
> ...
>
> cm*:*:*
>
> cn*:*:*
>
>
> cp*:*:*
>
> cq*:*:*
> {noformat}
> While this works, it's pretty ugly, and because it sits high up on our pom
> hierarchy it makes it harder to re-use the
> {{ignoredUsedUndeclaredDependencies}} and
> {{ignoredUnusedDeclaredDependencies}} for having to restate all the third
> party dependencies.
> Ideally it would be possible to specify running the dependency analyze for a
> specific groupId only.
> Suggestion is to introduce a new allow list whereby the dependency analysis
> is only run for the groupIds listed. Could also include the artifactId as
> well.
> Suggested name for new parameter is:
> {noformat}
> analyzeDependencies, String[], List of dependencies that will be analysed.
> The filter syntax is:
> [groupId]:[artifactId]
> where each pattern segment is optional and supports full and partial *
> wildcards. An empty pattern segment is treated as an implicit wildcard.
> Omitting this parameter will result in the analysis being run for all
> dependencies.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MDEP-808) Restrict dependency analysis by group id
[
https://issues.apache.org/jira/browse/MDEP-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771907#comment-17771907
]
Francis edited comment on MDEP-808 at 10/4/23 4:30 PM:
---
[~elharo]
{quote}
Looking at this again, I'm seeing that everything you want to do is already
possible. You simply want a switch to change from analyze by default to ignore
by default. That's pretty small beans. I'm very tempted to close this as won't
fix to avoid adding complexity to the code and docs unless there's a real need
I'm not seeing.
{quote}
I think the best I can do is to elaborate the need that arose in our
organisation and provide a bit more context over that already stated in the
description.
We have a monobuild that builds over a large monorepo and we want to ensure the
dependency graph is as small as possible. This maximises the throughput in the
monobuild and also ensures that the various tools that developers use to
analyse the dependency graph don't present any superfluous information. We run
analyse upon ~800 artifacts within that monobuild (which is a subset of the
total artifacts, we have an initiative scheduled to further expand the usage).
Currently the pluginManagement block in the parent pom of the monobuild looks
something like this (lightly edited for public consumption):
[^pluginManagementPreMDEP-808.txt]
With the code under this issue, it simplifies to:
[^pluginManagementPostMDEP-808.txt]
So yes, we are already able to achieve the desired functional result, but it
leaves an ugly mess in the pom. Why don't we simply expand the scope of analyze
to run over all dependencies at our organisation and be done with it?
Introducing analyze to the extent that it has been now took ~50 days of
developer effort, and we don't think we'll get the same benefits from expanding
it further to include all dependencies.
[Lifting from the
PR|https://github.com/apache/maven-dependency-plugin/pull/218#pullrequestreview-1657317011]:
{quote}
I'm still skeptical of this feature. What is the problem solved by not warning
on all unused dependencies? Unused dependencies don't break the build. If
someone can't fix them all right now, so what?
{quote}
We *_do_* want unused dependencies to break the build so we *_do_* warn on
them. We've found that is the only really effective way to ensure that unused
dependencies are cleared up, preventing eventual drift such that over time our
monobuild slows down and our graphing tools start lying to our developers about
the actual state of the dependencies.
That's the best case I can make for this. That MDEP-885 has been logged
demonstrates that our use-case isn't the only use-case (but admittedly only
proves there's at least two use-cases).
There are still some outstanding review comments on the PR, but I think it best
if I stop noodling on the PR until the maintainers are sold on the case for
this change, otherwise that's more effort on something that isn't long for this
world.
was (Author: JIRAUSER289535):
[~elharo]
{quote}
Looking at this again, I'm seeing that everything you want to do is already
possible. You simply want a switch to change from analyze by default to ignore
by default. That's pretty small beans. I'm very tempted to close this as won't
fix to avoid adding complexity to the code and docs unless there's a real need
I'm not seeing.
{quote}
I think the best I can do is to elaborate the need that arose in our
organisation and provide a bit more context over that already stated in the
description.
We have a monobuild that builds over a large monorepo and we want to ensure the
dependency graph is as small as possible. This maximises the throughput in the
monobuild and also ensures that the various tools that developers use to
analyse the dependency graph don't present any superfluous information. We run
analyse upon ~800 artifacts within that monobuild (which is a subset of the
total artifacts, we have an initiative scheduled to further expand the usage).
Currently the pluginManagement block in the parent pom that sits of the
monobuild looks something like this (lightly edited for public consumption):
[^pluginManagementPreMDEP-808.txt]
With the code under this issue, it simplifies to:
[^pluginManagementPostMDEP-808.txt]
So yes, we are already able to achieve the desired functional result, but it
leaves an ugly mess in the pom. Why don't we simply expand the scope of analyze
to run over all dependencies at our organisation and be done with it?
Introducing analyze to the extent that it has been now took ~50 days of
developer effort, and we don't think we'll get the same benefits from expanding
it further to include all dependencies.
[Lifting from the
PR|https://github.com/apache/maven-dependency-plugin/pull/218#pullrequestreview-1657317011]:
{quote}
I'm still skeptical of this feature. What is the p
Re: [PR] [MNG-7848] Add Jenkinsfile.s390x for Jenkins CI on s390x [maven]
vivkong commented on PR #1266: URL: https://github.com/apache/maven/pull/1266#issuecomment-1747320601 Thanks @elharo! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771934#comment-17771934 ] ASF GitHub Bot commented on MNG-7848: - vivkong commented on PR #1266: URL: https://github.com/apache/maven/pull/1266#issuecomment-1747320601 Thanks @elharo! > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap & Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] fix style [maven-site]
slawekjaranowski commented on PR #459: URL: https://github.com/apache/maven-site/pull/459#issuecomment-1747328285 Changed page: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] fix style [maven-site]
slawekjaranowski merged PR #459: URL: https://github.com/apache/maven-site/pull/459 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] fix style [maven-site]
slawekjaranowski commented on PR #459: URL: https://github.com/apache/maven-site/pull/459#issuecomment-1747332519 @imba-tjd thanks -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Rename basedir to project.basedir [maven-site]
slawekjaranowski merged PR #457: URL: https://github.com/apache/maven-site/pull/457 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Try to fix MavenITmng7836AlternativePomSyntaxTest [maven-integration-testing]
slawekjaranowski commented on code in PR #307:
URL:
https://github.com/apache/maven-integration-testing/pull/307#discussion_r1346231226
##
core-it-suite/src/test/java/org/apache/maven/it/MavenITmng7836AlternativePomSyntaxTest.java:
##
@@ -64,8 +66,11 @@ void testAlternativeSyntax() throws Exception {
assertTrue(Files.isRegularFile(consumerPom));
List consumerPomLines = Files.readAllLines(consumerPom,
StandardCharsets.UTF_8);
-assertFalse(consumerPomLines.stream().anyMatch(l ->
l.contains("Apache-2.0")));
-assertTrue(consumerPomLines.stream().anyMatch(l ->
l.contains("")));
+
+// looks like consumerPom is an effective pom
+// both assertions will fail
+// assertFalse(consumerPomLines.stream().anyMatch(l ->
l.contains("Apache-2.0")));
+// assertTrue(consumerPomLines.stream().anyMatch(l ->
l.contains("")));
Review Comment:
rebased
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Try to fix MavenITmng7836AlternativePomSyntaxTest [maven-integration-testing]
slawekjaranowski commented on PR #307: URL: https://github.com/apache/maven-integration-testing/pull/307#issuecomment-1747371308 Master build is still suffer from it ... do we have any other idea - how to fix After release alpha-8 we will can remove access to remote repo and move needed artifacts to bootstrap. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Remove methods used for JUnit 3/4 [maven-integration-testing]
slawekjaranowski merged PR #300: URL: https://github.com/apache/maven-integration-testing/pull/300 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 4.0.2 [maven-remote-resources-plugin]
slawekjaranowski commented on PR #45: URL: https://github.com/apache/maven-remote-resources-plugin/pull/45#issuecomment-1747466491 @dependabot ignore this major version -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 4.0.2 [maven-remote-resources-plugin]
dependabot[bot] closed pull request #45: Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 4.0.2 URL: https://github.com/apache/maven-remote-resources-plugin/pull/45 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.codehaus.plexus:plexus-xml from 3.0.0 to 4.0.2 [maven-remote-resources-plugin]
dependabot[bot] commented on PR #45: URL: https://github.com/apache/maven-remote-resources-plugin/pull/45#issuecomment-1747466552 OK, I won't notify you about version 4.x.x again, unless you re-open this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (ARCHETYPE-649) "[WARNING] CP Don't override file" when generating archetype with 3.2.1
Wolfgang Knauf created ARCHETYPE-649:
Summary: "[WARNING] CP Don't override file" when generating
archetype with 3.2.1
Key: ARCHETYPE-649
URL: https://issues.apache.org/jira/browse/ARCHETYPE-649
Project: Maven Archetype
Issue Type: Bug
Components: Creator
Affects Versions: 3.2.1
Reporter: Wolfgang Knauf
Attachments: archetype-metadata.xml,
wildfly-jakartaee-ear-archetype-30.0.0.Final-SNAPSHOT_312.jar,
wildfly-jakartaee-ear-archetype-30.0.0.Final-SNAPSHOT_321.jar
I do some maintenance work on the "wildfly-jakartaee-ear-archetype". After
updating "maven-archetype-plugin" to 3.2.1, there are two warnings printed when
creating a project from the archetype.
{quote}{{[WARNING] Don't override file
...\multi\project\multi\web\src\test\java\foo\bar\multi}}
{{[WARNING] CP Don't override file
...\multi\project\multi\web\src\main\webapp}}{quote}
I think the problem depends on the archetype-plugin version that creates the
archetype JAR. Attached are the jar files from my local repository. One is
created with archetype-plugin 3.1.2, the other with 3.2.1.
[^wildfly-jakartaee-ear-archetype-30.0.0.Final-SNAPSHOT_321.jar]
[^wildfly-jakartaee-ear-archetype-30.0.0.Final-SNAPSHOT_312.jar]
Note the size difference of the two jar files.
When creating a project from the archetype, the message appears with both 3.1.2
and 3.2.1, if the archetype jar was created with 3.2.1. It does not appear when
the archetype jar was created with the 3.1.2 plugin.
Debug logging during generating of the project from the archetype seems to
point me to the reason: with 3.2.1, the jar file contains a lot of entries for
the directories. With 3.1.2, there are only entries for "real" files.
This seems to cause duplicates with the fileSets in "archetype-metadata.xml"
Here is the log when the archetype jar was created with 3.1.2:
{{[DEBUG] getFilesetArchetypeResources(
"C:\Users\USERNAME\.m2\repository\org\wildfly\archetype\wildfly-jakartaee-ear-archetype\30.0.0.Final-SNAPSHOT\wildfly-jakartaee-ear-archetype-30.0.0.Final-SNAPSHOT.jar"
)}}
{{[DEBUG] - found resource (archetype-resources/)ear/pom.xml}}
{{[DEBUG] - found resource (archetype-resources/)ejb/pom.xml}}
{{[DEBUG] - found resource
(archetype-resources/)ejb/src/main/resources/META-INF/persistence.xml}}
{{[DEBUG] - found resource
(archetype-resources/)ejb/src/test/resources/arquillian.xml}}
{{[DEBUG] - found resource (archetype-resources/)pom.xml}}
{{[DEBUG] - found resource (archetype-resources/)README.txt}}
{{[DEBUG] - found resource (archetype-resources/)web/pom.xml}}
{{[DEBUG] - found resource
(archetype-resources/)web/src/main/webapp/WEB-INF/beans.xml}}
{{[DEBUG] - found resource
(archetype-resources/)web/src/main/webapp/WEB-INF/faces-config.xml}}
{{[DEBUG] - found resource
(archetype-resources/)web/src/test/java/test/SampleIT.java}}
{{[DEBUG] - found resource
(archetype-resources/)web/src/test/resources/arquillian.xml}}
{{[DEBUG] - ignored resource META-INF/maven/archetype-metadata.xml}}
{{[DEBUG] Processing complete archetype wildfly-jakartaee-webapp-ear-archetype}}
And this is the output for an archetype created with 3.2.1:
{{[DEBUG] getFilesetArchetypeResources(
"C:\Users\USERNAME\.m2\repository\org\wildfly\archetype\wildfly-jakartaee-ear-archetype\30.0.0.Final-SNAPSHOT\wildfly-jakartaee-ear-archetype-30.0.0.Final-SNAPSHOT.jar"
)}}
{{[DEBUG] - ignored resource META-INF/MANIFEST.MF}}
{{[DEBUG] - ignored resource META-INF/}}
{{[DEBUG] - found resource (archetype-resources/)}}
{{[DEBUG] - found resource (archetype-resources/)ear/}}
{{[DEBUG] - found resource (archetype-resources/)ejb/}}
{{[DEBUG] - found resource (archetype-resources/)ejb/src/}}
{{[DEBUG] - found resource (archetype-resources/)ejb/src/main/}}
{{[DEBUG] - found resource (archetype-resources/)ejb/src/main/resources/}}
{{[DEBUG] - found resource
(archetype-resources/)ejb/src/main/resources/META-INF/}}
{{[DEBUG] - found resource (archetype-resources/)ejb/src/test/}}
{{[DEBUG] - found resource (archetype-resources/)ejb/src/test/resources/}}
{{[DEBUG] - found resource (archetype-resources/)web/}}
{{[DEBUG] - found resource (archetype-resources/)web/src/}}
{{[DEBUG] - found resource (archetype-resources/)web/src/main/}}
{{[DEBUG] - found resource (archetype-resources/)web/src/main/webapp/}}
{{[DEBUG] - found resource
(archetype-resources/)web/src/main/webapp/WEB-INF/}}
{{[DEBUG] - found resource (archetype-resources/)web/src/test/}}
{{[DEBUG] - found resource (archetype-resources/)web/src/test/java/}}
{{[DEBUG] - found resource (archetype-resources/)web/src/test/java/test/}}
{{[DEBUG] - found resource (archetype-resources/)web/src/test/resources/}}
{{[DEBUG] - ignored resource META-INF/maven/}}
{{[DEBUG] - ignored resource META-INF/maven/org.wildfly.archetype/}}
{{[DEBUG
Re: [PR] Maven 3.9.5 release notes [maven-site]
cstamas merged PR #458: URL: https://github.com/apache/maven-site/pull/458 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SCM-1013) Add skip parameter to all goals
[ https://issues.apache.org/jira/browse/SCM-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771997#comment-17771997 ] Michael Osipov commented on SCM-1013: - What is the use case here? > Add skip parameter to all goals > --- > > Key: SCM-1013 > URL: https://issues.apache.org/jira/browse/SCM-1013 > Project: Maven SCM > Issue Type: New Feature > Components: maven-plugin >Reporter: Richard Eckart de Castilho >Priority: Major > > Currently, the only way to conditionally execute this plugin is by either > putting it into a profile or by putting it into a conditionally included > submodule. But profile-based activation may not be flexible enough and > putting it into a conditionally included submodule is quite inconvenient. > Most Maven goals have a "skip" parameter that can be used to control them. It > would be good if the Maven SVM goals would follow that approach as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Try to fix MavenITmng7836AlternativePomSyntaxTest [maven-integration-testing]
gnodet commented on PR #307: URL: https://github.com/apache/maven-integration-testing/pull/307#issuecomment-1747644960 > Master build is still suffer from it ... do we have any other idea - how to fix After release alpha-8 we will can remove access to remote repo and move needed artifacts to bootstrap. I still think we should run the integration tests on a locally build distribution, else there's no way we can test something depending on new code in maven. So for the time being, I would either disable the test until alpha-8 is released or build Maven snapshot locally (or disable Jenkins jobs which are the only one failing). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Update: Maven 3.9.5 + Resolver 1.9.16 [maven-mvnd]
cstamas opened a new pull request, #887: URL: https://github.com/apache/maven-mvnd/pull/887 Changes: * update to Maven 3.9,5 * update to Resolver 1.9.16 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MNG-7900) wrapper lifecycle in multi module project should be executed only in root module
Slawomir Jaranowski created MNG-7900:
Summary: wrapper lifecycle in multi module project should be
executed only in root module
Key: MNG-7900
URL: https://issues.apache.org/jira/browse/MNG-7900
Project: Maven
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 4.0.0-alpha-7
Reporter: Slawomir Jaranowski
Execute
{code:java}
mvn wrapper
{code}
should have the same result as goal:
{code:java}
mvn wrapper:wrapper
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MNG-7898] Missing .mvn directory should not be reported in quiet mode [maven-integration-testing]
slawekjaranowski opened a new pull request, #309: URL: https://github.com/apache/maven-integration-testing/pull/309 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7898) Missing .mvn directory should not be reported in quiet mode
[
https://issues.apache.org/jira/browse/MNG-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772002#comment-17772002
]
ASF GitHub Bot commented on MNG-7898:
-
slawekjaranowski opened a new pull request, #1273:
URL: https://github.com/apache/maven/pull/1273
ITs fix: https://github.com/apache/maven-integration-testing/pull/309
---
Following this checklist to help us incorporate your
contribution quickly and easily:
- [x] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MNG) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [x] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MNG-XXX] SUMMARY`,
where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA
issue.
- [x] Also format the first line of the commit message like `[MNG-XXX]
SUMMARY`.
Best practice is to use the JIRA issue title in both the pull request
title and in the first line of the commit message.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [x] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [x] You have run the [Core IT][core-its] successfully.
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [x] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [x] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
[core-its]: https://maven.apache.org/core-its/core-it-suite/
> Missing .mvn directory should not be reported in quiet mode
> ---
>
> Key: MNG-7898
> URL: https://issues.apache.org/jira/browse/MNG-7898
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-7
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 4.0.0-alpha-8
>
>
> To reproduce
> {code}
> mvn help:evaluate -q -DforceStdout -Dexpression=project.version
> {code}
> output is:
> {code}
> Unable to find the root directory. Create a .mvn directory in the root
> directory or add the root="true" attribute on the root project's model to
> identify it.
> 211-SNAPSHOT
> {code}
> should be only:
> {code}
> 211-SNAPSHOT
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MNG-7898] Missing .mvn directory should not be reported in quiet mode [maven]
slawekjaranowski opened a new pull request, #1273: URL: https://github.com/apache/maven/pull/1273 ITs fix: https://github.com/apache/maven-integration-testing/pull/309 --- Following this checklist to help us incorporate your contribution quickly and easily: - [x] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [x] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [x] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Use the same branch name for ITs on Jenkins [maven]
slawekjaranowski commented on code in PR #1263:
URL: https://github.com/apache/maven/pull/1263#discussion_r1346508489
##
Jenkinsfile:
##
@@ -84,10 +84,21 @@ for (String os in runITsOses) {
// will not trample each other plus workaround for
JENKINS-52657
dir(isUnix() ? 'test' :
"c:\\mvn-it-${EXECUTOR_NUMBER}.tmp") {
def WORK_DIR=pwd()
-checkout([$class: 'GitSCM',
-branches: [[name: "*/master"]],
-extensions: [[$class: 'CloneOption', depth: 1,
noTags: true, shallow: true]],
-userRemoteConfigs: [[url:
'https://github.com/apache/maven-integration-testing.git']]])
+def ITS_BRANCH = env.CHANGE_BRANCH != null ?
env.CHANGE_BRANCH : env.BRANCH_NAME;
+try {
+ echo "Checkout ITs from branch: ${ITS_BRANCH}"
+ checkout([$class: 'GitSCM',
+ branches: [[name: ITS_BRANCH]],
+ extensions: [[$class: 'CloneOption', depth:
1, noTags: true, shallow: true]],
+ userRemoteConfigs: [[url:
'https://github.com/apache/maven-integration-testing.git']]])
Review Comment:
@gnodet, @olamy I still think that change is good enough
build for #1273 pass on GH but fail on Jenkins
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] Use Maven 3.9.4 on GitHub [maven-integration-testing]
slawekjaranowski merged PR #242: URL: https://github.com/apache/maven-integration-testing/pull/242 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Try to fix MavenITmng7836AlternativePomSyntaxTest [maven-integration-testing]
slawekjaranowski commented on PR #307: URL: https://github.com/apache/maven-integration-testing/pull/307#issuecomment-1747724177 > > Master build is still suffer from it ... do we have any other idea - how to fix After release alpha-8 we will can remove access to remote repo and move needed artifacts to bootstrap. > > I still think we should run the integration tests on a locally build distribution, else there's no way we can test something depending on new code in maven. So for the time being, I would either disable the test until alpha-8 is released or build Maven snapshot locally (or disable Jenkins jobs which are the only one failing). We run test on current build distribution: ``` Running integration tests for Maven 4.0.0-alpha-8-SNAPSHOT using Maven executable: /home/jenkins/jenkins-home/workspace/Maven_maven-box_maven_MNG-7898/test/core-it-suite/target/apache-maven/bin/mvn with verifier.forkMode: auto ``` We only don't have populated local repo used by test by Maven build -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1563) NoClassDefFoundError for JPMS modules with "require static"
[
https://issues.apache.org/jira/browse/SUREFIRE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772013#comment-17772013
]
Jörg Hohwiller commented on SUREFIRE-1563:
--
Any update on this? I also get this {{NoClassDefFoundError}} because of
{{requite static}} and stuck with surefire-plugin 2.22.2 while latest is
already 3.1.2 with various other good improvements.
> NoClassDefFoundError for JPMS modules with "require static"
> ---
>
> Key: SUREFIRE-1563
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1563
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.22.0
>Reporter: Simone Bordet
>Assignee: Olivier Lamy
>Priority: Major
> Attachments: maven-jpms.tgz
>
>
> When a Maven module has a {{module-info.java}} that contains a {{requires
> static}}, Surefire throws {{NoClassDefFoundError}} when running the tests for
> that Maven module.
> If the dependency is declared only as {{required}} (no {{static}}), then the
> tests run fine.
> Attached a reproducible project.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Use the same branch name for ITs on Jenkins [maven]
olamy merged PR #1263: URL: https://github.com/apache/maven/pull/1263 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MNG-7848] Add Jenkinsfile.s390x for Jenkins CI on s390x [maven]
olamy merged PR #1266: URL: https://github.com/apache/maven/pull/1266 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7848) Add s390x pipeline to Jenkins CI
[ https://issues.apache.org/jira/browse/MNG-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772043#comment-17772043 ] ASF GitHub Bot commented on MNG-7848: - olamy merged PR #1266: URL: https://github.com/apache/maven/pull/1266 > Add s390x pipeline to Jenkins CI > > > Key: MNG-7848 > URL: https://issues.apache.org/jira/browse/MNG-7848 > Project: Maven > Issue Type: New Feature > Components: Bootstrap & Build, Integration Tests >Reporter: Kun Lu >Priority: Major > Labels: pull-request-available > > Apache INFRA team has installed necessary JDK flavours on all s390x nodes > (Please check issue > [https://issues.apache.org/jira/projects/INFRA/issues/INFRA-24781]). We’d > like to add the s390x pipeline to Jenkins CI by raising a PR to add ` > Jenkinsfile.s390x` to the Maven code base. > Can anyone from Maven team help us review the PR and create the s390x > pipeline on Jenkins? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MCOMPILER-548] JDK 21 throws annotations processing warning that can not be turned off [maven-compiler-plugin]
hgschmie commented on PR #200: URL: https://github.com/apache/maven-compiler-plugin/pull/200#issuecomment-1748004949 Turns out that this might not be sufficient. JDK < 21 does *not* support "full" as a value, so we may want to check whether the value is "full" and omit it when the JDK is < 21. Requires more thought. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-548) JDK 21 throws annotations processing warning that can not be turned off
[
https://issues.apache.org/jira/browse/MCOMPILER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772066#comment-17772066
]
ASF GitHub Bot commented on MCOMPILER-548:
--
hgschmie commented on PR #200:
URL:
https://github.com/apache/maven-compiler-plugin/pull/200#issuecomment-1748004949
Turns out that this might not be sufficient. JDK < 21 does *not* support
"full" as a value, so we may want to check whether the value is "full" and omit
it when the JDK is < 21.
Requires more thought.
> JDK 21 throws annotations processing warning that can not be turned off
> ---
>
> Key: MCOMPILER-548
> URL: https://issues.apache.org/jira/browse/MCOMPILER-548
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.11.0
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> maven compiler plugin 3.11 on Java 21 reports
> {quote}
> [INFO] Annotation processing is enabled because one or more processors were
> found
> on the class path. A future release of javac may disable annotation
> processing
> unless at least one processor is specified by name (-processor), or a search
> path is specified (--processor-path, --processor-module-path), or annotation
> processing is enabled explicitly (-proc:only, -proc:full).
> Use -Xlint:-options to suppress this message.
> Use -proc:none to disable annotation processing.
> {quote}
> However, the {{}} option only supports "none" and "proc", not "full"
> (which is the implicit default).
> Adding this through a compiler option:
> {quote}
>
>
> -proc:full
>
>
> {quote}
> fixes this warning. Adding "full" as a value for the compiler plugin would
> fix it, too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SCM-1013) Add skip parameter to all goals
[
https://issues.apache.org/jira/browse/SCM-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772070#comment-17772070
]
Richard Eckart de Castilho commented on SCM-1013:
-
In my particular use-case, I am using the SCM plugin to automatically stage a
release candidate during a release build.
Currently, I am working around the missing skip parameter by using a property
in the {{phase}} element of the execution and setting this property to {{none}}
when not in a release build. It works, but it is a hack.
Related issues:
* https://github.com/apache/uima-parent-pom/issues/37
* https://github.com/apache/uima-parent-pom/pull/62
> Add skip parameter to all goals
> ---
>
> Key: SCM-1013
> URL: https://issues.apache.org/jira/browse/SCM-1013
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-plugin
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> Currently, the only way to conditionally execute this plugin is by either
> putting it into a profile or by putting it into a conditionally included
> submodule. But profile-based activation may not be flexible enough and
> putting it into a conditionally included submodule is quite inconvenient.
> Most Maven goals have a "skip" parameter that can be used to control them. It
> would be good if the Maven SVM goals would follow that approach as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MSHARED-1314) mark execute() final to avoid users extending reporting-impl implementation
Herve Boutemy created MSHARED-1314: -- Summary: mark execute() final to avoid users extending reporting-impl implementation Key: MSHARED-1314 URL: https://issues.apache.org/jira/browse/MSHARED-1314 Project: Maven Shared Components Issue Type: Improvement Components: maven-reporting-impl Affects Versions: maven-reporting-impl-4.0.0-M10 Reporter: Herve Boutemy see https://lists.apache.org/thread/mcbh55967j79dpv72tqnoqgowxhgvoj6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MSHARED-1314] mark execute() final and improve documentation [maven-reporting-impl]
hboutemy opened a new pull request, #24: URL: https://github.com/apache/maven-reporting-impl/pull/24 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1314) mark execute() final to avoid users extending reporting-impl implementation
[ https://issues.apache.org/jira/browse/MSHARED-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772100#comment-17772100 ] ASF GitHub Bot commented on MSHARED-1314: - hboutemy opened a new pull request, #24: URL: https://github.com/apache/maven-reporting-impl/pull/24 (no comment) > mark execute() final to avoid users extending reporting-impl implementation > --- > > Key: MSHARED-1314 > URL: https://issues.apache.org/jira/browse/MSHARED-1314 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-reporting-impl >Affects Versions: maven-reporting-impl-4.0.0-M10 >Reporter: Herve Boutemy >Priority: Major > > see https://lists.apache.org/thread/mcbh55967j79dpv72tqnoqgowxhgvoj6 -- This message was sent by Atlassian Jira (v8.20.10#820010)
