[GitHub] [maven] timboudreau closed pull request #750: Allow Maven to resolve a parent it is about to build
timboudreau closed pull request #750: Allow Maven to resolve a parent it is about to build URL: https://github.com/apache/maven/pull/750 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] timboudreau commented on pull request #750: Allow Maven to resolve a parent it is about to build
timboudreau commented on PR #750: URL: https://github.com/apache/maven/pull/750#issuecomment-1148177204 This may have been addressed in another way in the 4.x branch. Going to close this and open a patch for 3.9.x. -- 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-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550783#comment-17550783
]
Olivier Lamy commented on SUREFIRE-1426:
[~br0nstein]please open another issue. thanks
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-1426) Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
[
https://issues.apache.org/jira/browse/SUREFIRE-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550762#comment-17550762
]
Aaron Braunstein commented on SUREFIRE-1426:
[~tibordigana] I have a fix for the above. Should we re-open this issue, or I
file a new issue to track the fix for Maven Failsafe Plugin (and this get
updated to indicate this issue does not track/fix that issue).
> Fork crash doesn't fail build with -Dmaven.test.failure.ignore=true
> ---
>
> Key: SUREFIRE-1426
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1426
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Dan Berindei
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 2.22.3, 3.0.0-M6
>
> Attachments: surefire-1426-test.tar.gz
>
>
> We have a reactor with many modules, and also a few random test failures. We
> want to run the tests of all the modules even if a test failed in the core
> module, so we use {{mvn -Dmaven.test.failure.ignore=true}}. {{mvn
> --fail-at-end}} only builds the modules that do not depend on the module with
> a failed test.
> The problem is that fork crashes like this one are written to the surefire
> reports, so Jenkins ignores them:
> {noformat}
> org.apache.maven.surefire.booter.SurefireBooterForkException: There was an
> error in the forked process
> Unable to load category: stress
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:665)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:533)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:279)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:243)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1077)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:907)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:785)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356){noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-fluido-skin] olamy commented on pull request #34: Mskins 191 dynamic library retrieval
olamy commented on PR #34: URL: https://github.com/apache/maven-fluido-skin/pull/34#issuecomment-1148033740 @stevecrox I agree this skin has very dated.. but you might face some conservative reactions here. If you are interested there is this "new one" as well https://olamy.github.io/reflow-maven-skin/ and I will be happy to accept your contribution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] olamy commented on a diff in pull request #34: Mskins 191 dynamic library retrieval
olamy commented on code in PR #34:
URL: https://github.com/apache/maven-fluido-skin/pull/34#discussion_r890642306
##
pom.xml:
##
@@ -184,6 +186,93 @@ under the License.
false
+
+
+copy-anchor-js-into-build-output
+process-resources
+
+ copy-resources
+
+
+
+
+
${project.build.directory}/node_modules/anchor-js
+ false
+
+
+
${minifiyResourcesDirectory}/js
+
+
+
+copy-async-js-into-build-output
+process-resources
+
+ copy-resources
+
+
+
+
+
${project.build.directory}/node_modules/jquery/dist
+ false
+
+
+
${minifiyResourcesDirectory}/js
+
+
+
+copy-bootstrap-into-build-output
+process-resources
+
+ copy-resources
+
+
+
+
+
${project.build.directory}/node_modules/bootstrap/dist
+ false
+
+
+ ${minifiyResourcesDirectory}
+
+
+
+copy-resources-into-build-output
+process-resources
+
+ copy-resources
+
+
+
+
+ ${basedir}/src/main/resources
+ false
+
+
+ ${minifiyResourcesDirectory}
+
+
+
+
+
+
+com.github.eirslett
+frontend-maven-plugin
Review Comment:
does this work on windows?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-fluido-skin] slawekjaranowski commented on a diff in pull request #33: rework ITs to better integrate into skin documentation
slawekjaranowski commented on code in PR #33:
URL: https://github.com/apache/maven-fluido-skin/pull/33#discussion_r890615352
##
src/site/site.xml:
##
@@ -27,9 +27,7 @@ under the License.
org.apache.maven.skins
maven-fluido-skin
-
-
-1.10.0
+${project.version}
Review Comment:
We have IT test which use current build skins.
IMHO project should used latest release version - even more we have the same
definition in parent and we needn't here it.
all project should be build by the same standard command
##
src/site/site.xml:
##
@@ -27,9 +27,7 @@ under the License.
org.apache.maven.skins
maven-fluido-skin
-
-
-1.10.0
+${project.version}
Review Comment:
We have IT test which use current build skins.
IMHO project should used latest release version - even more we have the same
definition in parent and we needn't here it.
all project should be build by the same standard command
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-fluido-skin] stevecrox commented on a diff in pull request #34: Mskins 191 dynamic library retrieval
stevecrox commented on code in PR #34: URL: https://github.com/apache/maven-fluido-skin/pull/34#discussion_r890611319 ## pom.xml: ## @@ -98,12 +98,14 @@ under the License. -2.3.2 +3.1.1 Review Comment: Yes I've deciphered from one of the comments that to test this I need to run the run-its profile and then I can look at various configurations. the site.xml is for some reason referencing the previous release rather than the current version, which hid various changes. I believe the latest update to the branch should resolve the big issues. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] stevecrox commented on pull request #34: Mskins 191 dynamic library retrieval
stevecrox commented on PR #34: URL: https://github.com/apache/maven-fluido-skin/pull/34#issuecomment-1147985599 Micheal-o the PR was simply closed I assume this was done in error since it appeared some discussion started and then before I could even raise questions or make adjustments it was closed with no meaningful feedback provided to myself. Which I explained in the first paragraph comment on the PR as you can see. -- 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] (MNGSITE-485) Expired signature in provided KEYS file on the download page
[
https://issues.apache.org/jira/browse/MNGSITE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550679#comment-17550679
]
Baiyang Li commented on MNGSITE-485:
I tried again. I get another error even before running gpg --verify ...
Get an error when running gpg --import KEYS
{code:java}
gpg: invalid armor header: ...
gpg: CRC error; 4E1FE5 - EA41D5
gpg: invalid marker packet
gpg: read_block: read error: Invalid packet
gpg: import from '/KEYS' failed: Invalid keyring{code}
> Expired signature in provided KEYS file on the download page
>
>
> Key: MNGSITE-485
> URL: https://issues.apache.org/jira/browse/MNGSITE-485
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Baiyang Li
>Assignee: Michael Osipov
>Priority: Major
>
> Hey,
> I met the same expired signature issue described in this close
> [issue|https://issues.apache.org/jira/browse/MNGSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17410236#comment-17410236].
> When i follow the procedure to verify the signature using the KEYS file, both
> provided on the maven's download page::
> * KEYS file import: gpg --import KEYS
> * signature verification; gpg --verify .\apache-maven-3.8.2-bin.tar.gz.asc
> .\apache-maven-3.8.2-bin.tar.gz
> I've got the following message at the second step:
> gpg: Good signature from "Michael Osipov (Java developer)
> <1983-01...@gmx.net>" [expired]
> gpg: aka "Michael Osipov " [expired]
> gpg: Note: This key has expired!
> According to the same procedure: "A signature is valid, if gpg verifies the
> .asc as a good signature, and doesn't complain about expired or revoked
> keys", so, technically, the signature is not valid.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MWRAPPER-68) MVNW_REPOURL improperly formed distributionUrl
[ https://issues.apache.org/jira/browse/MWRAPPER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] HumanFund updated MWRAPPER-68: -- Description: In Maven Wrapper v3.1.1, Installer::createDist(), file maven-wrapper/src/main/java/org/apache/maven/wrapper/Installer.java, was updated on line 74 to be: distributionUrl = new URI( mvnwRepoUrl ).resolve( "/" ).resolve( mvnPath ); The above update is causing the distributionUrl to be improperly formed based on the MVNW_REPOURL environment variable and the mvnPath which is extracted from the distributionUrl in maven-wrapper.properties, specifically the substring starting with "org/apache/maven". The update was introduced in the following commit: [https://github.com/apache/maven-wrapper/commit/22a3268def96e5e648aa97a49d9e146e529b7c87#diff-193f3775e6efb0b6ed01219b21272f9eb3861965ce3af3586a0ce8eb153359c0] An example of the results are shown below. Note the "Downloading" URI does not include the entire repo url, only the scheme, host, and port, then the maven path is appended. The repo url is getting truncated by the call to resolve( "/" ) on line 74. I do not currently see a purpose for having this call in place. I made the following update to line 74 and it works fine: distributionUrl = new URI( mvnwRepoUrl ).resolve( mvnPath ); Note that in Maven Wrapper v3.1.0, the distributionUrl was formed simply by appending the maven path to the MVNW_REPOURL: distributionUrl = new URI( mvnwRepoUrl + "/" + mvnPath ); Example output demonstrating issue: [exec] [INFO] Apache Maven Wrapper 3.1.1 [exec] [INFO] Detected MVNW_REPOURL environment variable [http://localhost:8081/repository/repo-maven-apache-org-maven2/] [exec] [INFO] Installing Maven distribution /home/myexamplehome/maven/wrapper/dists/apache-maven-3.6.3-bin/cf3cf814 [exec] [INFO] Downloading [http://localhost:8081/org/apache/maven/apache-maven/3.6.3/apache-maven-3.6.3-bin.zip] was: In Maven Wrapper v3.1.1, Installer::createDist(), file maven-wrapper/src/main/java/org/apache/maven/wrapper/Installer.java, was updated on line 74 to be: distributionUrl = new URI( mvnwRepoUrl ).resolve( "/" ).resolve( mvnPath ); The above update is causing the distributionUrl to be improperly formed based on the MVNW_REPOURL environment variable and the mvnPath which is extracted from the distributionUrl in maven-wrapper.properties, specifically the substring starting with "org/apache/maven". The update was introduced in the following commit: https://github.com/apache/maven-wrapper/commit/22a3268def96e5e648aa97a49d9e146e529b7c87#diff-193f3775e6efb0b6ed01219b21272f9eb3861965ce3af3586a0ce8eb153359c0 An example of the results are shown below. Note the "Downloading" URI does not include the entire repo url, only the scheme, host, and port, then the maven path is appended. The repo url is getting truncated by the call to resolve( "/" ) on line 74. I do not currently see a purpose for having this call in place. I made the following update to line 74 and it works fine: distributionUrl = new URI( mvnwRepoUrl ).resolve( mvnPath ); Note that in Maven Wrapper v3.1.0, the distributionUrl was formed simply by appending the maven path to the MVNW_REPOURL: distributionUrl = new URI( mvnwRepoUrl + "/" + mvnPath ); Example output: [exec] [INFO] Apache Maven Wrapper 3.1.1 [exec] [INFO] Detected MVNW_REPOURL environment variable [http://localhost:8081/repository/repo-maven-apache-org-maven2/] [exec] [INFO] Installing Maven distribution /home/myexamplehome/maven/wrapper/dists/apache-maven-3.6.3-bin/cf3cf814 [exec] [INFO] Downloading [http://localhost:8081/org/apache/maven/apache-maven/3.6.3/apache-maven-3.6.3-bin.zip] > MVNW_REPOURL improperly formed distributionUrl > -- > > Key: MWRAPPER-68 > URL: https://issues.apache.org/jira/browse/MWRAPPER-68 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Jar >Affects Versions: 3.1.1 >Reporter: HumanFund >Priority: Major > > In Maven Wrapper v3.1.1, Installer::createDist(), file > maven-wrapper/src/main/java/org/apache/maven/wrapper/Installer.java, was > updated on line 74 to be: > distributionUrl = new URI( mvnwRepoUrl ).resolve( "/" ).resolve( mvnPath ); > The above update is causing the distributionUrl to be improperly formed based > on the MVNW_REPOURL environment variable and the mvnPath which is extracted > from the distributionUrl in maven-wrapper.properties, specifically the > substring starting with "org/apache/maven". > The update was introduced in the following commit: > [https://github.com/apache/maven-wrapper/commit/22a3268def96e5e648aa97a49d9e146e529b7c87#diff-193f3775e6efb0b6ed01219b21272f9eb3861965ce3af3586a0ce8eb153359c0] > An example of the results are shown below. Note the "Downloading" URI does > not
[GitHub] [maven-fluido-skin] michael-o commented on a diff in pull request #34: Mskins 191 dynamic library retrieval
michael-o commented on code in PR #34: URL: https://github.com/apache/maven-fluido-skin/pull/34#discussion_r890578218 ## pom.xml: ## @@ -98,12 +98,14 @@ under the License. -2.3.2 +3.1.1 Review Comment: Correct and this is wrong... -- 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] (MASSEMBLY-955) dependencySet includes filter with classifier breaks include of artifacts without classifier
[
https://issues.apache.org/jira/browse/MASSEMBLY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550662#comment-17550662
]
Michael Osipov commented on MASSEMBLY-955:
--
I have tried your IT against current master and even when I fix the filter it
is still not included. [~gnodet], can you clarify why this limitation was added?
> dependencySet includes filter with classifier breaks include of artifacts
> without classifier
>
>
> Key: MASSEMBLY-955
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-955
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet, filtering
>Affects Versions: 3.0.0, 3.1.0, 3.1.1, 3.2.0, 3.3.0
>Reporter: Václav Haisman
>Priority: Major
> Labels: pull-request-available
>
> I have created a demonstration repo for this issue at
> [https://github.com/wilx/maven-assembly-includes-test-case]. As demonstrated
> by the test projects in the repository, the filtering breaks with version
> 3.0.0 of Maven Assembly plugin but at least it finishes building something.
> If I try to update maven-common-artifact-filters to 3.2.0, it breaks the
> build completely because it does not like 5 components include pattern.
> Following is cut of my email to dev mailing list:
> Hi.
> I think I found a defect in the latest currently available Maven Assembly
> plugin version 3.3.0. The Assembly plugin uses Common Artifact Filters's
> class `PatternIncludesArtifactFilter`. This class, in its method
> `matchAgainst()` loops over include patterns. If one of the include patterns
> contains 4+ components, 4th being the classifier (according to the source
> code, documentation does not mention classifier), it immediately rejects the
> artifact being checked for inclusion without testing the other patterns. My
> inclusion patterns are
> {code:java}
> com.XYZ:some-artifact:*:service:*
> org.python:jython-standalone
> {code}
> The jython pattern is not even tested against the jython dependency because
> it returns from the function early instead of continuing the loop. This is
> code, the return statement should be continue statement instead for this to
> work as I think was intended:
> {code:java}
> private boolean matchAgainst( final String value, final List
> patterns, final boolean regionMatch )
> {
> final String[] tokens = value.split( ":" );
> for ( String pattern : patterns )
> {
> String[] patternTokens = pattern.split( ":" );
>
> if ( patternTokens.length == 5 && tokens.length < 5 )
> {
> // 4th element is the classifier
> if ( !"*".equals( patternTokens[3] ) )
> {
> // classifier required, cannot be a match
> return false;
> }
> {code}
> But this is not all. I tried running the 3.3.0 Assembly plugin with
> maven-common-artifact-filters artifact version 3.2.0 which seems to have been
> significantly rewritten. However, that rejects my 5 components pattern
> entirely. The comment in the code says "we only accept 5 tokens if the
> classifier = '*'", which seems to be a departure from what the previous
> version tried to support.
> {code:java}
> // we only accept 5 tokens if the classifier = '*'
> if ( tokens.length == 5 )
> {
> if ( tokens[3] != ANY )
> {
> throw new IllegalArgumentException( "Invalid pattern: " + pattern );
> }
> tokens = new char[][] { tokens[0], tokens[1], tokens[2], tokens[4] };
> }
> {code}
> Was it intentional that the rewrite of the artifact filters stopped
> supporting previously supported patterns?
> Can we release Common Artifact Filters version 3.1.1 or such with the return
> statement changed to continue statement and at the same time release Assembly
> plugin 3.3.1 which would use this fixed Common Artifact Filters version to
> unbreak this?
> Can we fix the Common Artifact Filters version 3.2.0 to accept the inclusion
> filter with the classifier as do the previous versions?
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNGSITE-485) Expired signature in provided KEYS file on the download page
[ https://issues.apache.org/jira/browse/MNGSITE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550661#comment-17550661 ] Michael Osipov commented on MNGSITE-485: Please try again. > Expired signature in provided KEYS file on the download page > > > Key: MNGSITE-485 > URL: https://issues.apache.org/jira/browse/MNGSITE-485 > Project: Maven Project Web Site > Issue Type: Bug >Reporter: Baiyang Li >Assignee: Michael Osipov >Priority: Major > > Hey, > I met the same expired signature issue described in this close > [issue|https://issues.apache.org/jira/browse/MNGSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17410236#comment-17410236]. > When i follow the procedure to verify the signature using the KEYS file, both > provided on the maven's download page:: > * KEYS file import: gpg --import KEYS > * signature verification; gpg --verify .\apache-maven-3.8.2-bin.tar.gz.asc > .\apache-maven-3.8.2-bin.tar.gz > I've got the following message at the second step: > gpg: Good signature from "Michael Osipov (Java developer) > <1983-01...@gmx.net>" [expired] > gpg: aka "Michael Osipov " [expired] > gpg: Note: This key has expired! > According to the same procedure: "A signature is valid, if gpg verifies the > .asc as a good signature, and doesn't complain about expired or revoked > keys", so, technically, the signature is not valid. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (MWRAPPER-68) MVNW_REPOURL improperly formed distributionUrl
HumanFund created MWRAPPER-68: - Summary: MVNW_REPOURL improperly formed distributionUrl Key: MWRAPPER-68 URL: https://issues.apache.org/jira/browse/MWRAPPER-68 Project: Maven Wrapper Issue Type: Bug Components: Maven Wrapper Jar Affects Versions: 3.1.1 Reporter: HumanFund In Maven Wrapper v3.1.1, Installer::createDist(), file maven-wrapper/src/main/java/org/apache/maven/wrapper/Installer.java, was updated on line 74 to be: distributionUrl = new URI( mvnwRepoUrl ).resolve( "/" ).resolve( mvnPath ); The above update is causing the distributionUrl to be improperly formed based on the MVNW_REPOURL environment variable and the mvnPath which is extracted from the distributionUrl in maven-wrapper.properties, specifically the substring starting with "org/apache/maven". The update was introduced in the following commit: https://github.com/apache/maven-wrapper/commit/22a3268def96e5e648aa97a49d9e146e529b7c87#diff-193f3775e6efb0b6ed01219b21272f9eb3861965ce3af3586a0ce8eb153359c0 An example of the results are shown below. Note the "Downloading" URI does not include the entire repo url, only the scheme, host, and port, then the maven path is appended. The repo url is getting truncated by the call to resolve( "/" ) on line 74. I do not currently see a purpose for having this call in place. I made the following update to line 74 and it works fine: distributionUrl = new URI( mvnwRepoUrl ).resolve( mvnPath ); Note that in Maven Wrapper v3.1.0, the distributionUrl was formed simply by appending the maven path to the MVNW_REPOURL: distributionUrl = new URI( mvnwRepoUrl + "/" + mvnPath ); Example output: [exec] [INFO] Apache Maven Wrapper 3.1.1 [exec] [INFO] Detected MVNW_REPOURL environment variable [http://localhost:8081/repository/repo-maven-apache-org-maven2/] [exec] [INFO] Installing Maven distribution /home/myexamplehome/maven/wrapper/dists/apache-maven-3.6.3-bin/cf3cf814 [exec] [INFO] Downloading [http://localhost:8081/org/apache/maven/apache-maven/3.6.3/apache-maven-3.6.3-bin.zip] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-fluido-skin] slachiewicz commented on a diff in pull request #34: Mskins 191 dynamic library retrieval
slachiewicz commented on code in PR #34: URL: https://github.com/apache/maven-fluido-skin/pull/34#discussion_r890568061 ## pom.xml: ## @@ -98,12 +98,14 @@ under the License. -2.3.2 +3.1.1 Review Comment: so only version change and no need to adjust any macros? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] michael-o commented on pull request #35: Mskins 97 redefine macro layout
michael-o commented on PR #35: URL: https://github.com/apache/maven-fluido-skin/pull/35#issuecomment-1147925038 Logical change. Will take a look next couple of days. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] slachiewicz commented on a diff in pull request #34: Mskins 191 dynamic library retrieval
slachiewicz commented on code in PR #34: URL: https://github.com/apache/maven-fluido-skin/pull/34#discussion_r890566562 ## pom.xml: ## @@ -98,12 +98,14 @@ under the License. -2.3.2 +3.1.1 1.11.2 3.12.0 3.3.0 2022-05-14T18:16:12Z 4.2.2 Review Comment: looks not used -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] stevecrox opened a new pull request, #35: Mskins 97 redefine macro layout
stevecrox opened a new pull request, #35: URL: https://github.com/apache/maven-fluido-skin/pull/35 This change is about breaking out the velocity macros, so when I modify sections (to work with Bootstrap 5) it is clearer what I am changing and why -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] michael-o commented on pull request #34: Mskins 191 dynamic library retrieval
michael-o commented on PR #34: URL: https://github.com/apache/maven-fluido-skin/pull/34#issuecomment-1147917259 What is the difference between this and the other 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
[GitHub] [maven-shared-utils] wilx commented on pull request #54: rework directory scanner to ensure it can enforce exclusions and it uses path
wilx commented on PR #54: URL: https://github.com/apache/maven-shared-utils/pull/54#issuecomment-1147914189 Any progress? -- 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] (MNGSITE-485) Expired signature in provided KEYS file on the download page
[
https://issues.apache.org/jira/browse/MNGSITE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550658#comment-17550658
]
Baiyang Li commented on MNGSITE-485:
Hey [~michael-o] ,
Thanks for your update. I try to import keys today but still get this error.
{code:java}
gpg: Good signature from "Michael Osipov (Java developer) <1983-01...@gmx.net>"
[expired]
gpg: aka "Michael Osipov " [expired]
gpg: Note: This key has expired!{code}
Steps I ran on the computer
gpg --import "/${key_file}"
gpg --verify "$/${signature_file}" "${artifact_file_name}"
May I know is there something wrong with steps I run?
Thanks.
> Expired signature in provided KEYS file on the download page
>
>
> Key: MNGSITE-485
> URL: https://issues.apache.org/jira/browse/MNGSITE-485
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Baiyang Li
>Assignee: Michael Osipov
>Priority: Major
>
> Hey,
> I met the same expired signature issue described in this close
> [issue|https://issues.apache.org/jira/browse/MNGSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17410236#comment-17410236].
> When i follow the procedure to verify the signature using the KEYS file, both
> provided on the maven's download page::
> * KEYS file import: gpg --import KEYS
> * signature verification; gpg --verify .\apache-maven-3.8.2-bin.tar.gz.asc
> .\apache-maven-3.8.2-bin.tar.gz
> I've got the following message at the second step:
> gpg: Good signature from "Michael Osipov (Java developer)
> <1983-01...@gmx.net>" [expired]
> gpg: aka "Michael Osipov " [expired]
> gpg: Note: This key has expired!
> According to the same procedure: "A signature is valid, if gpg verifies the
> .asc as a good signature, and doesn't complain about expired or revoked
> keys", so, technically, the signature is not valid.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNGSITE-485) Expired signature in provided KEYS file on the download page
[
https://issues.apache.org/jira/browse/MNGSITE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550658#comment-17550658
]
Baiyang Li edited comment on MNGSITE-485 at 6/6/22 8:51 PM:
Hey [~michael-o] ,
Thanks for your update. I try to import keys today but still get this error.
{code:java}
gpg: Good signature from "Michael Osipov (Java developer) <1983-01...@gmx.net>"
[expired]
gpg: aka "Michael Osipov " [expired]
gpg: Note: This key has expired!{code}
Steps I ran on the computer
{code:java}
gpg --import "/${key_file}"
gpg --verify "$/${signature_file}" "${artifact_file_name}"{code}
May I know is there something wrong with steps I run?
Thanks.
was (Author: JIRAUSER290479):
Hey [~michael-o] ,
Thanks for your update. I try to import keys today but still get this error.
{code:java}
gpg: Good signature from "Michael Osipov (Java developer) <1983-01...@gmx.net>"
[expired]
gpg: aka "Michael Osipov " [expired]
gpg: Note: This key has expired!{code}
Steps I ran on the computer
gpg --import "/${key_file}"
gpg --verify "$/${signature_file}" "${artifact_file_name}"
May I know is there something wrong with steps I run?
Thanks.
> Expired signature in provided KEYS file on the download page
>
>
> Key: MNGSITE-485
> URL: https://issues.apache.org/jira/browse/MNGSITE-485
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Baiyang Li
>Assignee: Michael Osipov
>Priority: Major
>
> Hey,
> I met the same expired signature issue described in this close
> [issue|https://issues.apache.org/jira/browse/MNGSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17410236#comment-17410236].
> When i follow the procedure to verify the signature using the KEYS file, both
> provided on the maven's download page::
> * KEYS file import: gpg --import KEYS
> * signature verification; gpg --verify .\apache-maven-3.8.2-bin.tar.gz.asc
> .\apache-maven-3.8.2-bin.tar.gz
> I've got the following message at the second step:
> gpg: Good signature from "Michael Osipov (Java developer)
> <1983-01...@gmx.net>" [expired]
> gpg: aka "Michael Osipov " [expired]
> gpg: Note: This key has expired!
> According to the same procedure: "A signature is valid, if gpg verifies the
> .asc as a good signature, and doesn't complain about expired or revoked
> keys", so, technically, the signature is not valid.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (MNGSITE-485) Expired signature in provided KEYS file on the download page
[
https://issues.apache.org/jira/browse/MNGSITE-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550658#comment-17550658
]
Baiyang Li edited comment on MNGSITE-485 at 6/6/22 8:51 PM:
Hey [~michael-o] ,
Thanks for your update. I try to import keys today but still get this error.
{code:java}
gpg: Good signature from "Michael Osipov (Java developer) <1983-01...@gmx.net>"
[expired]
gpg: aka "Michael Osipov " [expired]
gpg: Note: This key has expired!{code}
Steps I ran on the computer
{code:java}
gpg --import "/${key_file}"
gpg --verify "/${signature_file}" "/${artifact_file_name}"{code}
May I know is there something wrong with steps I run?
Thanks.
was (Author: JIRAUSER290479):
Hey [~michael-o] ,
Thanks for your update. I try to import keys today but still get this error.
{code:java}
gpg: Good signature from "Michael Osipov (Java developer) <1983-01...@gmx.net>"
[expired]
gpg: aka "Michael Osipov " [expired]
gpg: Note: This key has expired!{code}
Steps I ran on the computer
{code:java}
gpg --import "/${key_file}"
gpg --verify "$/${signature_file}" "${artifact_file_name}"{code}
May I know is there something wrong with steps I run?
Thanks.
> Expired signature in provided KEYS file on the download page
>
>
> Key: MNGSITE-485
> URL: https://issues.apache.org/jira/browse/MNGSITE-485
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Baiyang Li
>Assignee: Michael Osipov
>Priority: Major
>
> Hey,
> I met the same expired signature issue described in this close
> [issue|https://issues.apache.org/jira/browse/MNGSITE-458?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel=17410236#comment-17410236].
> When i follow the procedure to verify the signature using the KEYS file, both
> provided on the maven's download page::
> * KEYS file import: gpg --import KEYS
> * signature verification; gpg --verify .\apache-maven-3.8.2-bin.tar.gz.asc
> .\apache-maven-3.8.2-bin.tar.gz
> I've got the following message at the second step:
> gpg: Good signature from "Michael Osipov (Java developer)
> <1983-01...@gmx.net>" [expired]
> gpg: aka "Michael Osipov " [expired]
> gpg: Note: This key has expired!
> According to the same procedure: "A signature is valid, if gpg verifies the
> .asc as a good signature, and doesn't complain about expired or revoked
> keys", so, technically, the signature is not valid.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-fluido-skin] stevecrox opened a new pull request, #34: Mskins 191 dynamic library retrieval
stevecrox opened a new pull request, #34: URL: https://github.com/apache/maven-fluido-skin/pull/34 I assume there was some kind of glitch, there appeared to be the start of a discussion on the PR and then it was simply closed before I could explain some of the issues or receive actionable feedback. I appreciate this is a 'skin', while Maven Sites looked modern when first updated in ~2011 they now look dated and personally I'm having to answer why would I use maven-site over mkdocs since the later is pretty (love Product owners). This skin uses the Bootstrap v2.8 library which is extremely old and the velocity template does not follow the standard bootstrap layouts. In my own time I have taken apart this skin and completely rewritten to follow bootstrap 5, rather than open source that I am hoping this PR is the first in what I hope is a sequence to rework and upstream that effort for everyone to use. The primary comment seem to be around the use of the frontend-maven-plugin, I would like to take you through my reasoning for choosing such a plug-in and what this plug-in does and why in the hopes of meaningful discussion/feedback. The root issue is front end Web Developers use Node.JS and release libraries as NPM Artefacts and there isn't a nice way for either build system to 'share' artefacts. I've been developing for a while I'll take you through the options I am aware of.. ### Option 1 - Bundling Originally with frontend development we would copy JS files into a WAR's resources folder and then start the front end. This was terrible, from a technical debt perspective reverse engineering libraries was a pain (for example it took ~45 minutes to identify the anchor-js library in this skin) and it was slow to compile. I think to paint why this is horrible I would ask "why use Maven lets just dump the Jar files in a folder?". ### Option 2 - Javascript Maven Plugin Codehaus produced a Maven extension it added the 'js' packaging type and you could stand up a webserver, it was awesome. But saw nearly zero adoption in the web community, I spent some time taking open source libraries and wrapping them but no one cared, it became a huge manual effort to create libraries to wrap them so you could use them within a Maven project. ### Option 3 - Webjars See option 2. ### Option 4 - Node.JS create a Maven artifact Within NPM you have a package.json file and 'scripts' section, this is kind of like the Maven build lifecycle. If I call npm publish I can expect the system to also call the script linked to 'postpublish' if defined. So you can write a script to call maven-deploy-plug-in and create a M2 artefact. This is bad for 2 reasons firstly you have to include a mvn wrapper to retrieve MVN and it ends up as 2 files and secondly because it relies on all the open source JS projects 'accepting' a Maven dependency. ### Option 5 - Use CDN reference. I have always worked for defence companies, the INFOSEC department in everyone has pushed for development to be in an effectively Air Gapped environment. I have spent hundreds of hours designing, building and lobbying for approaches that allow such environments to be able to mirror things like Maven Central. One of Maven's unique strengths is with a bit of thought you can easily redirect everything to internal mirrors (also much love to Sonatype Nexus). Even the frontend-maven-plugin defined here lets me change where Node.JS is mirrored. Moving to a CDN makes the skin useless in that environment (see Space, Banks, etc..). You can achieve a similar result with NPM and even with its conflicting documentation setuptools. A sensible way forward might be to allow people to configure use of CDN or local instance (perhaps even a means to override). ### Option 6 - Self contained JS Frontend One of the more common patterns we see (e.g. react does this) is to have the front end code hosted by an express instance as static content ad redirect to the backend API. This doesn't match our problem maven-site-plugin uses Apache Velocity to build pages and we want to include resources for the constructed pages to use. ### Option 7 - frontend-maven-plugin This option uses Maven information to go to the Node.JS website (or mirror) and retrieve a tarball of the specificy Node.JS instance. In the current configuration I have this retrieved tarball extracted into the build directory (e.g. target). This ensures the Node.JS instance does not become part of the build artefacts. Then in the generate-resources phase we call 'npm install boostrap@version anchor-js@version' . The frontend-maven-plugin translates this to a call of "target/node/bin/npm install boostrap@version anchor-js@version". The working directory remains the build directory and so you get dependencies installed under target/node_modules/bootstrap and target/node_modules/anchor-js.
[GitHub] [maven-common-artifact-filters] michael-o closed pull request #24: [MASSEMBLY-955] Keep iterating over patterns.
michael-o closed pull request #24: [MASSEMBLY-955] Keep iterating over patterns. URL: https://github.com/apache/maven-common-artifact-filters/pull/24 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-common-artifact-filters] michael-o commented on pull request #24: [MASSEMBLY-955] Keep iterating over patterns.
michael-o commented on PR #24: URL: https://github.com/apache/maven-common-artifact-filters/pull/24#issuecomment-1147876623 I am closing this PR because it cannot be applied. The entire class has changed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] jglick commented on pull request #750: Allow Maven to resolve a parent it is about to build
jglick commented on PR #750: URL: https://github.com/apache/maven/pull/750#issuecomment-1147841396 > I have no idea _why_ it was never implemented For M2Eclipse perhaps? https://github.com/apache/maven-integration-testing would be the place to write a test AFAIK. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1076) [REGRESSION] 1b5d50b390c4548d16d0c7d507c38240c6f49b07 prematurely breaks loop
Michael Osipov created MSHARED-1076: --- Summary: [REGRESSION] 1b5d50b390c4548d16d0c7d507c38240c6f49b07 prematurely breaks loop Key: MSHARED-1076 URL: https://issues.apache.org/jira/browse/MSHARED-1076 Project: Maven Shared Components Issue Type: Bug Components: maven-common-artifact-filters Reporter: Michael Osipov Assignee: Michael Osipov Fix For: maven-common-artifact-filters-3.2.1 As documented in https://github.com/apache/maven-common-artifact-filters/commit/1b5d50b390c4548d16d0c7d507c38240c6f49b07 and MASSEMBLY-955 the loop must continue to find all matches. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (SUREFIRE-2094) Leaked file descriptors
Michael Keppler created SUREFIRE-2094:
-
Summary: Leaked file descriptors
Key: SUREFIRE-2094
URL: https://issues.apache.org/jira/browse/SUREFIRE-2094
Project: Maven Surefire
Issue Type: Bug
Reporter: Michael Keppler
Issue https://issues.apache.org/jira/browse/SUREFIRE-1845 with change
[https://github.com/apache/maven-surefire/commit/32bd56b4ea908147592ef92c71c4e7936e070993#diff-c634b539151b4b76bde50d93d5a6cd2b0f51aa411281398cc295cc721bdfa1d5]
removed
{code:java}
utf8RecodingDeferredFileOutputStream.close();{code}
from StatelessXmlReporter.java. That change seems reasonable, since that exact
stream is still used 2 lines deeper. However, this seems to cause leaked file
descriptors, one per test, see
[https://github.com/eclipse/tycho/issues/965|https://github.com/eclipse/tycho/issues/965.]
Might it be useful to NOT remove the close() call, but just to move it down
some lines instead?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (MASSEMBLY-957) Deprecate the repository element in assembly decriptor
[
https://issues.apache.org/jira/browse/MASSEMBLY-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MASSEMBLY-957:
--
Fix Version/s: 3.3.1
> Deprecate the repository element in assembly decriptor
> --
>
> Key: MASSEMBLY-957
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-957
> Project: Maven Assembly Plugin
> Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.3.1
>
>
> The {{repository}} element in assembly descriptor is present since 1.0 of
> m-assembly-p, so it comes from Maven 2.0 times. The intent of this element is
> aligned with Maven 2.0 in a way, that Maven "local repository" and "remote
> repository" were same (plus some metadata needed for remote). This is NOT
> true since Maven 3.0, local repository is NOT transportable (this is since
> "enhanced" local repository implementation in Aether/Maven-Resolver). Simply
> put, "transporting" local repository from workstation to workstation is NOT
> JUST tarring up your local repository and un-tarring on target computer (this
> WAS like it with Maven2).
> As mentioned, this element documentation is vague and unclear what it does:
> creates "local" repository? Creates "remote" repository? Both? Also, since
> 3.0.0 of m-assembly-p it introduces bug and wrong behaviour: it (mis) uses
> Aether local repository to create something that may be assumed is a remote
> repository, and while doing that, introduces issues like MASSEMBLY-870 and
> MASSEMBLY-874 and alike (as in a moment local repo is redefined to that _tmp
> directory, Aether MUST re-download everything, despite all is present in your
> "real" local repository).
> We MAY introduce new element that buys out this deprecated element, like
> {{remoteRepository}} that would be clearly documented it creates Maven 3
> remote repository, while adding element like {{localRepository}} may be just
> overkill, as explained above, Maven 3 local repositories are NOT
> transportable.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-filtering] dependabot[bot] closed pull request #36: Bump mockito-core from 2.28.2 to 4.6.0
dependabot[bot] closed pull request #36: Bump mockito-core from 2.28.2 to 4.6.0 URL: https://github.com/apache/maven-filtering/pull/36 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-filtering] dependabot[bot] commented on pull request #36: Bump mockito-core from 2.28.2 to 4.6.0
dependabot[bot] commented on PR #36: URL: https://github.com/apache/maven-filtering/pull/36#issuecomment-1147698676 Superseded by #37. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-filtering] dependabot[bot] opened a new pull request, #37: Bump mockito-core from 2.28.2 to 4.6.1
dependabot[bot] opened a new pull request, #37: URL: https://github.com/apache/maven-filtering/pull/37 Bumps [mockito-core](https://github.com/mockito/mockito) from 2.28.2 to 4.6.1. Release notes Sourced from https://github.com/mockito/mockito/releases;>mockito-core's releases. v4.6.1 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 4.6.1 2022-06-02 - https://github.com/mockito/mockito/compare/v4.6.0...v4.6.1;>6 commit(s) by Andy Coates, Chen Ni, dependabot[bot] Bump material from 1.6.0 to 1.6.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2662;>#2662)](https://github-redirect.dependabot.com/mockito/mockito/pull/2662;>mockito/mockito#2662) Bump core-ktx from 1.7.0 to 1.8.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2661;>#2661)](https://github-redirect.dependabot.com/mockito/mockito/pull/2661;>mockito/mockito#2661) Bump groovy from 3.0.10 to 3.0.11 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2660;>#2660)](https://github-redirect.dependabot.com/mockito/mockito/pull/2660;>mockito/mockito#2660) Fix for Issue2656 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2659;>#2659)](https://github-redirect.dependabot.com/mockito/mockito/pull/2659;>mockito/mockito#2659) Bump assertj-core from 3.22.0 to 3.23.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2658;>#2658)](https://github-redirect.dependabot.com/mockito/mockito/pull/2658;>mockito/mockito#2658) Regression? Strictness set in @MockitoSettings ignored after upgrade from 4.5.1 to 4.6.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2656;>#2656)](https://github-redirect.dependabot.com/mockito/mockito/issues/2656;>mockito/mockito#2656) Fix typo [(https://github-redirect.dependabot.com/mockito/mockito/issues/2655;>#2655)](https://github-redirect.dependabot.com/mockito/mockito/pull/2655;>mockito/mockito#2655) v4.6.0 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 4.6.0 2022-05-27 - https://github.com/mockito/mockito/compare/v4.5.1...v4.6.0;>14 commit(s) by Hervé Boutemy, K. Siva Prasad Reddy, Rafael Winterhalter, dependabot[bot] Bump shipkit-changelog from 1.1.15 to 1.2.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2654;>#2654)](https://github-redirect.dependabot.com/mockito/mockito/pull/2654;>mockito/mockito#2654) Bump versions.errorprone from 2.13.1 to 2.14.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2653;>#2653)](https://github-redirect.dependabot.com/mockito/mockito/pull/2653;>mockito/mockito#2653) Bump shipkit-auto-version from 1.1.20 to 1.2.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2651;>#2651)](https://github-redirect.dependabot.com/mockito/mockito/pull/2651;>mockito/mockito#2651) Fixes https://github-redirect.dependabot.com/mockito/mockito/issues/2648;>#2648 : Add support for customising strictness via https://github.com/Mock;>@Mock annotation and MockSettings [(https://github-redirect.dependabot.com/mockito/mockito/issues/2650;>#2650)](https://github-redirect.dependabot.com/mockito/mockito/pull/2650;>mockito/mockito#2650) Any way to enable Strict Stubbing when using Mockito.mock() without using https://github.com/Mock;>@Mock? [(https://github-redirect.dependabot.com/mockito/mockito/issues/2648;>#2648)](https://github-redirect.dependabot.com/mockito/mockito/issues/2648;>mockito/mockito#2648) Reintroduce inheriting type annotations from interfaces if only one interface is mocked, including additional interfaces. [(https://github-redirect.dependabot.com/mockito/mockito/issues/2645;>#2645)](https://github-redirect.dependabot.com/mockito/mockito/pull/2645;>mockito/mockito#2645) Bump com.diffplug.spotless from 6.6.0 to 6.6.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2643;>#2643)](https://github-redirect.dependabot.com/mockito/mockito/pull/2643;>mockito/mockito#2643) fix Reproducible Build issue [(https://github-redirect.dependabot.com/mockito/mockito/issues/2642;>#2642)](https://github-redirect.dependabot.com/mockito/mockito/pull/2642;>mockito/mockito#2642) Bump com.diffplug.spotless from 6.5.2 to 6.6.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2641;>#2641)](https://github-redirect.dependabot.com/mockito/mockito/pull/2641;>mockito/mockito#2641) Mockito mock of interfaces lost annotation information [(https://github-redirect.dependabot.com/mockito/mockito/issues/2640;>#2640)](https://github-redirect.dependabot.com/mockito/mockito/issues/2640;>mockito/mockito#2640) Bump material from 1.5.0 to 1.6.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2637;>#2637)](https://github-redirect.dependabot.com/mockito/mockito/pull/2637;>mockito/mockito#2637) Bump com.diffplug.spotless from 6.5.1 to 6.5.2
[jira] [Commented] (MRESOLVER-7) Download dependency POMs in parallel
[ https://issues.apache.org/jira/browse/MRESOLVER-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550590#comment-17550590 ] ASF GitHub Bot commented on MRESOLVER-7: cstamas commented on PR #178: URL: https://github.com/apache/maven-resolver/pull/178#issuecomment-1147694146 Something is wrong here, unsure what. But, I tried to build maven master using maven-3.9.x + this PR + empty local repo and it fails: ``` [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile (default-testCompile) on project maven-model-builder: Compilation failure: Compilation failure: [ERROR] /home/cstamas/Worx/apache-maven/maven/maven-model-builder/src/test/java/org/apache/maven/model/interpolation/StringSearchModelInterpolatorTest.java:[36,27] package org.hamcrest does not exist [ERROR] /home/cstamas/Worx/apache-maven/maven/maven-model-builder/src/test/java/org/apache/maven/model/interpolation/StringSearchModelInterpolatorTest.java:[36,1] static import only from classes and interfaces [ERROR] /home/cstamas/Worx/apache-maven/maven/maven-model-builder/src/test/java/org/apache/maven/model/interpolation/StringSearchModelInterpolatorTest.java:[37,27] package org.hamcrest does not exist [ERROR] /home/cstamas/Worx/apache-maven/maven/maven-model-builder/src/test/java/org/apache/maven/model/interpolation/StringSearchModelInterpolatorTest.java:[37,1] static import only from classes and interfaces [ERROR] -> [Help 1] ``` The cmd used to test: ``` [cstamas@infinity maven (maven-3.9.x)]$ ~/bin/maven/apache-maven-3.9.0-SNAPSHOT/bin/mvn clean install -Dmaven.repo.local=local-repo -Drat.skip -DskipTests -Daether.collector.impl=bf ``` > Download dependency POMs in parallel > > > Key: MRESOLVER-7 > URL: https://issues.apache.org/jira/browse/MRESOLVER-7 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Affects Versions: Aether 1.0.2 >Reporter: Harald Wellmann >Priority: Major > Attachments: resolver.log > > Time Spent: 40m > Remaining Estimate: 0h > > h3. Background > When building a project with dependencies not yet available in the local > repository, I noticed that Maven 3.3.9/Aether 1.0.2 first downloads the > dependency POMs _sequentially_ and then proceeds downloading the dependency > JARs with up to 5 threads _in parallel_. > Due to this, when first building a project with a large number of > dependencies, downloading a large number of small POMs may take a lot longer > than downloading the much larger JARs, or even longer than building the > project itself, especially when a repository manager is used which increases > the download latency. > h3. Enhancement > Download POMs of (transitive) dependencies in parallel to significantly speed > up initial builds of large projects. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] cstamas commented on pull request #178: [MRESOLVER-7] download poms in parallel
cstamas commented on PR #178: URL: https://github.com/apache/maven-resolver/pull/178#issuecomment-1147694146 Something is wrong here, unsure what. But, I tried to build maven master using maven-3.9.x + this PR + empty local repo and it fails: ``` [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile (default-testCompile) on project maven-model-builder: Compilation failure: Compilation failure: [ERROR] /home/cstamas/Worx/apache-maven/maven/maven-model-builder/src/test/java/org/apache/maven/model/interpolation/StringSearchModelInterpolatorTest.java:[36,27] package org.hamcrest does not exist [ERROR] /home/cstamas/Worx/apache-maven/maven/maven-model-builder/src/test/java/org/apache/maven/model/interpolation/StringSearchModelInterpolatorTest.java:[36,1] static import only from classes and interfaces [ERROR] /home/cstamas/Worx/apache-maven/maven/maven-model-builder/src/test/java/org/apache/maven/model/interpolation/StringSearchModelInterpolatorTest.java:[37,27] package org.hamcrest does not exist [ERROR] /home/cstamas/Worx/apache-maven/maven/maven-model-builder/src/test/java/org/apache/maven/model/interpolation/StringSearchModelInterpolatorTest.java:[37,1] static import only from classes and interfaces [ERROR] -> [Help 1] ``` The cmd used to test: ``` [cstamas@infinity maven (maven-3.9.x)]$ ~/bin/maven/apache-maven-3.9.0-SNAPSHOT/bin/mvn clean install -Dmaven.repo.local=local-repo -Drat.skip -DskipTests -Daether.collector.impl=bf ``` -- 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-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550589#comment-17550589
]
Hudson commented on MNG-7468:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #31
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/31/
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550587#comment-17550587
]
Hudson commented on MNG-7468:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.8.x #32
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.8.x/32/
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550585#comment-17550585 ] ASF GitHub Bot commented on MRESOLVER-262: -- grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1147681955 I'll check tomorrow - thanks! > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] grgrzybek commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
grgrzybek commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1147681955 I'll check tomorrow - 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
[jira] [Commented] (MRESOLVER-262) Provide contextual data in trace data for collector invoked requests
[ https://issues.apache.org/jira/browse/MRESOLVER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550582#comment-17550582 ] ASF GitHub Bot commented on MRESOLVER-262: -- cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1147667658 @grgrzybek Please take a peek a compare the "demo snippet" output with what you need > Provide contextual data in trace data for collector invoked requests > > > Key: MRESOLVER-262 > URL: https://issues.apache.org/jira/browse/MRESOLVER-262 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > During collection several RepositoryEvents are fired, but they does not carry > any context related data regarding artifact collection. > Simplest solution would be to extend RequestTrace to provide: > * request context > * the artifact path (from root to leaf) > * leaf artifact being collected -- This message was sent by Atlassian Jira (v8.20.7#820007)
[GitHub] [maven-resolver] cstamas commented on pull request #182: [MRESOLVER-262] Provide contextual data in trace during collect
cstamas commented on PR #182: URL: https://github.com/apache/maven-resolver/pull/182#issuecomment-1147667658 @grgrzybek Please take a peek a compare the "demo snippet" output with what you need -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-gh-actions-shared] slawekjaranowski commented on pull request #46: Add more FF flags
slawekjaranowski commented on PR #46: URL: https://github.com/apache/maven-gh-actions-shared/pull/46#issuecomment-1147659197 I see one more issue, when ff is disabled and we create PR from branch in repo we have build matrix for both events push and pull-request, like in https://github.com/apache/maven-indexer/pull/207/checks https://user-images.githubusercontent.com/3578921/172206920-64d8d768-ce9e-4efc-92f2-c3fc9b76f84f.png;> -- 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] (SUREFIRE-2090) Xref link to source code with specified line number doesn't work. Missing "L" in anchor
[ https://issues.apache.org/jira/browse/SUREFIRE-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated SUREFIRE-2090: -- Labels: up-for-grabs (was: ) > Xref link to source code with specified line number doesn't work. Missing "L" > in anchor > --- > > Key: SUREFIRE-2090 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2090 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin >Affects Versions: 3.0.0-M6 >Reporter: Lau Brino >Priority: Minor > Labels: up-for-grabs > > Steps to reproduce: > # Have a Java Maven project setup > # In pom.xml, configure maven-surefire-report-plugin together with > maven-jxr-plugin:3.2.0 in section > # have a failed test in you project. > # generate html surefire report with xrefs to source code > # in that report locate failed test with link to test source code > Expected behavior: > Clicking on the link bring you to the exact line is test source where the > test failed. > Actual behavior: > The link works, but the line number is ignored. > > The link on surefire report looks like this > .../target/site/xref-test/com/soliteapay/portal/cloudterminal/CloudTerminalIT.html#121 > However correct URL looks like this > .../target/site/xref-test/com/soliteapay/portal/cloudterminal/CloudTerminalIT.html#L121 > (notice the "L" right after #) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MNG-7468.
Resolution: Fixed
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550543#comment-17550543
]
Hudson commented on MNG-7468:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » maven-3.9.x #42
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/maven-3.9.x/42/
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] timboudreau commented on pull request #750: Allow Maven to resolve a parent it is about to build
timboudreau commented on PR #750: URL: https://github.com/apache/maven/pull/750#issuecomment-1147596279 Example repositories I know of with the problem this solves: * [Mastfrog Parent](https://github.com/timboudreau/mastfrog-parent) * [Telenav Build](https://github.com/telenav/telenav-build) but given the number of questions about this exact behavior and how to solve the problem on StackOverflow, far from the only ones. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] slawekjaranowski merged pull request #161: Bump mockito.version from 4.6.0 to 4.6.1
slawekjaranowski merged PR #161: URL: https://github.com/apache/maven-enforcer/pull/161 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] timboudreau commented on pull request #750: Allow Maven to resolve a parent it is about to build
timboudreau commented on PR #750: URL: https://github.com/apache/maven/pull/750#issuecomment-1147589016 Working on a backport to the 3.9.x branch. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven] timboudreau opened a new pull request, #750: Allow Maven to resolve a parent it is about to build
timboudreau opened a new pull request, #750: URL: https://github.com/apache/maven/pull/750 Fixes a long-standing issue when using Maven with git submodules: * You have a library project in a git repository * That library is part of a larger set of projects, but should be buildable with just a checkout of the library (so contributors interested in that particular corner of the project don't need to check out a huge amount of stuff to contribute to that one area) * That library and its siblings share configuration via a shared superpom * That means the library _must not_ make assumptions about what is in the parent directory - it must use `` for its parent, so the parent will be resolved from the local repository or central * You have an aggregation project that builds the superpom and _all_ of the siblings together, for a number of reasons * So full time developers of the project can easily detect if they've broken compatibility with a sibling when they make changes * So continuous builds can obtain a consistent view of the entire set or projects and build them together So you wind up with an aggregation project that looks like: * `Aggregator/` * `pom.xml` - just a bill of materials, no parent * `superpom-project` - a git submodule * `pom.xml` - shared configuration, no parent * `project-1` - another git submodule, for a Java project * `pom.xml` - parents off of `superpom-project` with `` so an isolated checkout is always buildable * `project-2` - another git submodule for another Java project * `pom.xml` - same setup as `project-1/pom.xml` On a fresh checkout, with nothing locally built yet, building the aggregator will fail with _Non-resolvable parent POM_…and 'parent.relativePath' points at no local POM_ - if the superpom cannot yet be downloaded. *This is exactly the situation every time you bump the version of the superpom*. After `superpom-project/pom.xml` has been manually built at least once, building the `Aggregator/pom.xml` will succeed. This creates a number of problems: 1. Such projects always have to come with instructions or a "first time setup" script that explicitly builds the superpom to make the checkout usable for development * The entire promise of Maven is that builds are "batteries included" - you check it out, type `mvn install` and it Just Works™ 2. A "works for me" scenario, where the sources are the same, but those who have (sometimes accidentally) built the superpom have a build that works, and others do not, though the sources both have checked out are identical. This is yet another potent source of Maven hatred. 3. If it does work, you are actually building against a historical copy of `superpom/pom.xml` instead of the (possibly changed) copy in source, and won't know it unless something goes wrong 4. What you deploy may not be what you think it is. Say that I * Build `superpom/pom.xml` locally * Change the version of a library used by `project-1/pom.xml` from 1.0 to 1.1 _in the superpom source only_, build the aggregator and deploy to maven central * The tests for `project-1` will have passed, but they are ran against version 1.0 of that dependency, read from `~/.m2/repository` 5. Distrust of Maven in general - Maven _knows perfectly well_ that it is going to build `superpom/pom.xml` (the fact that this patch succeeds in fixing the behavior proves _that_), but it claims not to be able to find a file it has literally already read and built a model for This small patch solves that. The name of the interface `WorkspaceModelResolver` and its signature strongly suggest that it was created to solve this exact problem - but there are no implementations of the interface _at all_ within Maven's sources. I have no idea _why_ it was never implemented, but simply attempting to resolve the `Model` against the set of models already read is a sane and straightforward way to do it. This patch provides one that can resolve models against projects which have already been, themselves, resolved. * The patch is sensitive to the order of `` entries in the aggregator POM - if the superpom is not listed _before anything that depends on it_ the build will fail in the usual way * While that's less than ideal, it has far less severe consequences than the existing behavior * It could be made more robust by pre-sorting `` entries so that those modules which have packaging `pom` and no `` entries of their own are built first. That would probably require reading the `pom.xml` files of aggregator projects a little earlier than they currently are, in order to have enough information to perform that sort. * The version argument to `WorkspaceModelResolver`'s methods is named `versionConstraint`, suggesting it could be a version
[jira] [Commented] (MNG-7468) Unsupported plugins parameters in configuration should be verified
[
https://issues.apache.org/jira/browse/MNG-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550533#comment-17550533
]
ASF GitHub Bot commented on MNG-7468:
-
slawekjaranowski merged PR #749:
URL: https://github.com/apache/maven/pull/749
> Unsupported plugins parameters in configuration should be verified
> --
>
> Key: MNG-7468
> URL: https://issues.apache.org/jira/browse/MNG-7468
> Project: Maven
> Issue Type: New Feature
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> Currently we can provide any xml tags in plugin configuration even if plugin
> Mojo doesn't support specific parameters.
> eg we can have:
> {code:xml}
>
> example-maven-plugin
> 1.1.1
>
>
>
>
> {code}
> With example configuration Mojo is executed without any warning.
> Simply if parameters is not supported - build should break with some of
> invalid plugin configuration exception ...
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven] slawekjaranowski merged pull request #749: [MNG-7468] Check unsupported plugins parameters in configuration - 3.9
slawekjaranowski merged PR #749: URL: https://github.com/apache/maven/pull/749 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] slawekjaranowski merged pull request #171: [MNG-7468] Check unsupported plugins parameters in configuration - 3.9
slawekjaranowski merged PR #171: URL: https://github.com/apache/maven-integration-testing/pull/171 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] chalmagr commented on pull request #476: [SUREFIRE-2010] Parameterized Selection Does not Work
chalmagr commented on PR #476:
URL: https://github.com/apache/maven-surefire/pull/476#issuecomment-1147570883
> Thanks for the hints. I adapted the code, but is there any part of the
maven launcher which allows to pass something like `-Dtest=MySelector`, or do I
have to call it myself? Just adding it as goal ends in
>
> ```
> [ERROR] Unknown lifecycle phase "test -Dtest=ExampleTestJUnit4". You must
specify a valid lifecycle phase or a goal in the format :
or :[: >]:. Available lifecycle phases are: validate, initialize,
generate-sources, process-sources, generate-resources, process-resources,
compile, process-classes, generate-test-sources, process-test-sources, g
> enerate-test-resources, process-test-resources, test-compile,
process-test-classes, test, prepare-package, package, pre-integration-test,
integration-test, post-integration-test, verify, install, deploy, pre-cle
> an, clean, post-clean, pre-site, site, post-site, site-deploy. -> [Help 1]
> ```
>
> I can debug this with `-Dmaven.surefire.debug=true`, but that does not
help to create the process correctly.
Make sure to use
org.apache.maven.surefire.its.fixture.SurefireLauncher#sysProp to add the
option and not the execute method `execute("test -Dtest=...")`
--
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] (MENFORCER-401) DependencyConvergence ignores exclusions
[
https://issues.apache.org/jira/browse/MENFORCER-401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550530#comment-17550530
]
Slawomir Jaranowski commented on MENFORCER-401:
---
Without possibility to reproduce a bug, we can't fix it.
> DependencyConvergence ignores exclusions
>
>
> Key: MENFORCER-401
> URL: https://issues.apache.org/jira/browse/MENFORCER-401
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Plugin, Standard Rules
>Affects Versions: 3.0.0
>Reporter: T. Mohme
>Priority: Critical
> Fix For: waiting-for-feedback
>
>
> In my project there is a transitive dependency on an artifact ("idlj-idl")
> with scope=provided that cannot be resolved (this probably is a different
> problem) - so far, so good (bad).
> {noformat}
> ...
> Caused by: org.eclipse.aether.collection.DependencyCollectionException:
> Failed to collect dependencies at com.acme:my-project:jar:1.0.0 ->
> io.quarkus:quarkus-flyway:jar:2.2.3.Final ->
> io.quarkus:quarkus-agroal:jar:2.2.3.Final ->
> io.quarkus:quarkus-narayana-jta:jar:2.2.3.Final ->
> org.jboss.narayana.jts:narayana-jts-integration:jar:5.12.0.Final ->
> org.jboss.narayana.jts:idlj-idl:jar:5.12.0.Final
> ...{noformat}
> Interestingly, `./mvnw dependency:tree` doesn't show this dependency.
> The tree descends only down to "narayana-jts-integration".
> When I exclude the unresolvable dependency ("idle-idl") from an artifact
> before it in the chain shown by the exception cause, this has no impact:
> {noformat}
>
> io.quarkus
> quarkus-agroal
>
>
> org.jboss.narayana.jts
> idlj-idl
>
>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-fluido-skin] hboutemy commented on pull request #33: rework ITs to better integrate into skin documentation
hboutemy commented on PR #33: URL: https://github.com/apache/maven-fluido-skin/pull/33#issuecomment-1147563059 @slawekjaranowski IIRC, you're a GH expert, if you can please configure this branch to run "mvn package site" instead of "mvn site", that would fix the 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-2065) Test Reports Inconsistencies with Parameterized and junit4
[ https://issues.apache.org/jira/browse/SUREFIRE-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550524#comment-17550524 ] Christian Marquez Grabia commented on SUREFIRE-2065: When creating the reports it seems that the need is to have a unique way of identifying the test being executed. If the test executed does not have a unique identifier then other problems would come up (what caused the initial issue here). It would mistakenly consider multiple tests to be one leading to other problems. I am not 100% sure when this 'displayName' should be used (other than in your IDE when running the tests) ... maybe the log should show with proper display name, but I am still seeing the unique name instead, so this may still be a problem even after this fix > Test Reports Inconsistencies with Parameterized and junit4 > -- > > Key: SUREFIRE-2065 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2065 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 3.0.0-M5, 3.0.0-M6, 3.0.0-M7 >Reporter: Christian Marquez Grabia >Priority: Minor > > Running parameterized tests with the junit-platform provider causes tests to > be counted as single test (unlike using junit4 provider). This makes the > tests to be marked as 'Flaky' and marks the build as successful if the retry > failed count is greater than zero. Reports also show a single test run even > if there were multiple tests with different parameters. > For a sample project with the problem see > [surefire-flaky-issue|https://github.com/chalmagr/surefire-flaky-report] > This is also a possibly related to issue SUREFIRE-2010 and may help in the > resolution of it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Closed] (MNG-7485) Failed To Load JANSI Native Library
[
https://issues.apache.org/jira/browse/MNG-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7485.
---
Fix Version/s: (was: waiting-for-feedback)
(was: wontfix-candidate)
Resolution: Information Provided
> Failed To Load JANSI Native Library
> ---
>
> Key: MNG-7485
> URL: https://issues.apache.org/jira/browse/MNG-7485
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.8.5
>Reporter: Mark
>Priority: Minor
>
> Hi All
> Wondering if anyone else has experienced a similar issue. I have recently
> upgraded to JDK 8 and Maven 3.8.5 and when i try mvn --version i get an error
> as such:
> {color:#505f79}Failed to load native
> library:jansi-2.4.0-bbb285ac9ffab828-libjansi.so. The native library file at
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so is not executable, make sure
> that the directory is mounted on a partition without the noexec flag, or set
> the jansi.tmpdir system property to point to a proper location. osinfo:
> Linux/x86_64{color}
> {color:#505f79}java.lang.UnsatisfiedLinkError:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so: failed to map segment from
> shared object: Operation not permitted{color}
> {color:#505f79}Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0){color}
> {color:#505f79}Maven home: /opt/apache-maven-3.8.5{color}
> {color:#505f79}Java version: 1.8.0_251, vendor: Oracle Corporation, runtime:
> /opt/jdk1.8.0_251/jre{color}
> {color:#505f79}Default locale: en_US, platform encoding: UTF-8{color}
> {color:#505f79}OS name: "linux", version: "3.10.0-1160.49.1.el7.x86_64",
> arch: "amd64", family: "unix"{color}
> {color:#505f79}java version "1.8.0_251"{color}
> {color:#505f79}Java(TM) SE Runtime Environment (build 1.8.0_251-b08){color}
> {color:#505f79}Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed
> mode){color}
> I have also tried installing JANSI through yum and that does not seem to
> resolve it. sudo yum -y install jansi-native
> Any help or guidance on how to resolve this would be greatly appreciated.
> CentOS Linux release 7.9.2009 (Core)
> apache-maven-3.8.5
> jdk1.8.0_251
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MNG-7485) Failed To Load JANSI Native Library
[
https://issues.apache.org/jira/browse/MNG-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550470#comment-17550470
]
Mark commented on MNG-7485:
---
I can confirm that this has solved our issue.
> Failed To Load JANSI Native Library
> ---
>
> Key: MNG-7485
> URL: https://issues.apache.org/jira/browse/MNG-7485
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.8.5
>Reporter: Mark
>Priority: Minor
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> Hi All
> Wondering if anyone else has experienced a similar issue. I have recently
> upgraded to JDK 8 and Maven 3.8.5 and when i try mvn --version i get an error
> as such:
> {color:#505f79}Failed to load native
> library:jansi-2.4.0-bbb285ac9ffab828-libjansi.so. The native library file at
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so is not executable, make sure
> that the directory is mounted on a partition without the noexec flag, or set
> the jansi.tmpdir system property to point to a proper location. osinfo:
> Linux/x86_64{color}
> {color:#505f79}java.lang.UnsatisfiedLinkError:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so: failed to map segment from
> shared object: Operation not permitted{color}
> {color:#505f79}Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0){color}
> {color:#505f79}Maven home: /opt/apache-maven-3.8.5{color}
> {color:#505f79}Java version: 1.8.0_251, vendor: Oracle Corporation, runtime:
> /opt/jdk1.8.0_251/jre{color}
> {color:#505f79}Default locale: en_US, platform encoding: UTF-8{color}
> {color:#505f79}OS name: "linux", version: "3.10.0-1160.49.1.el7.x86_64",
> arch: "amd64", family: "unix"{color}
> {color:#505f79}java version "1.8.0_251"{color}
> {color:#505f79}Java(TM) SE Runtime Environment (build 1.8.0_251-b08){color}
> {color:#505f79}Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed
> mode){color}
> I have also tried installing JANSI through yum and that does not seem to
> resolve it. sudo yum -y install jansi-native
> Any help or guidance on how to resolve this would be greatly appreciated.
> CentOS Linux release 7.9.2009 (Core)
> apache-maven-3.8.5
> jdk1.8.0_251
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-surefire] chalmagr commented on a diff in pull request #516: [SUREFIRE-2065] Test Reports Inconsistencies with Parameterized and junit4
chalmagr commented on code in PR #516:
URL: https://github.com/apache/maven-surefire/pull/516#discussion_r890146141
##
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/TestSetRunListener.java:
##
@@ -312,7 +312,7 @@ private void addTestMethodStats()
for ( WrappedReportEntry reportEntry :
detailsForThis.getReportEntries() )
{
TestMethodStats methodStats =
-new TestMethodStats( reportEntry.getClassMethodName(),
reportEntry.getReportEntryType(),
+new TestMethodStats( reportEntry.getReportClassMethodName(),
reportEntry.getReportEntryType(),
Review Comment:
I've updated the PR with just changes to the adapter and additional ITs for
this jira
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-jxr] dependabot[bot] opened a new pull request, #58: Bump maven-pmd-plugin from 3.16.0 to 3.17.0
dependabot[bot] opened a new pull request, #58: URL: https://github.com/apache/maven-jxr/pull/58 Bumps [maven-pmd-plugin](https://github.com/apache/maven-pmd-plugin) from 3.16.0 to 3.17.0. Release notes Sourced from https://github.com/apache/maven-pmd-plugin/releases;>maven-pmd-plugin's releases. 3.17.0 New features and improvements https://issues.apache.org/jira/browse/MPMD-309;>MPMD-309 - Add configuration option to show suppressed violations (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/59;>#59) https://github.com/adangel;>@adangel https://issues.apache.org/jira/browse/MPMD-332;>MPMD-332 - Support Java 18 (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/63;>#63) https://github.com/adangel;>@adangel Bug Fixes https://issues.apache.org/jira/browse/MPMD-334;>MPMD-334 - Source Encoding parameter is ignored (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/64;>#64) https://github.com/laoseth;>@laoseth https://issues.apache.org/jira/browse/MPMD-342;>MPMD-342 - No debug log message issued when empty report shall be ski… (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/69;>#69) https://github.com/michael-o;>@michael-o Documentation updates https://issues.apache.org/jira/browse/MPMD-333;>MPMD-333 - Add release notes documentation (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/61;>#61) https://github.com/adangel;>@adangel Maintenance https://issues.apache.org/jira/browse/MPMD-336;>MPMD-336 - Replace deprecated calls to PMD (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/66;>#66) https://github.com/adangel;>@adangel Dependency updates https://issues.apache.org/jira/browse/MPMD-329;>MPMD-329 - Upgrade to PMD 6.45.0 https://issues.apache.org/jira/browse/MPMD-330;>MPMD-330 - Upgrade Maven Parent to 35 (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/60;>#60) https://github.com/adangel;>@adangel https://issues.apache.org/jira/browse/MPMD-331;>MPMD-331 - Require Maven 3.2.5+ (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/60;>#60) https://github.com/adangel;>@adangel https://issues.apache.org/jira/browse/MPMD-337;>MPMD-337 - Upgrade Maven Parent to 36 (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/67;>#67) https://github.com/adangel;>@adangel https://issues.apache.org/jira/browse/MPMD-338;>MPMD-338 - Upgrade to Doxia/Doxia Sitetools to 1.11.1 https://issues.apache.org/jira/browse/MPMD-339;>MPMD-339 - Upgrade plugins in ITs https://issues.apache.org/jira/browse/MPMD-340;>MPMD-340 - Upgrade Maven Reporting API/Impl to 3.1.0 https://issues.apache.org/jira/browse/MPMD-341;>MPMD-341 - Upgrade Maven Plugin Test Harness to 3.3.0 https://issues.apache.org/jira/browse/MPMD-343;>MPMD-343 - Upgrade to PMD 6.46.0 (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/71;>#71) https://github.com/adangel;>@adangel Bump release-drafter/release-drafter from 5.19.0 to 5.20.0 (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/68;>#68) https://github.com/dependabot;>@dependabot Bump release-drafter/release-drafter from 5.18.1 to 5.19.0 (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/58;>#58) https://github.com/dependabot;>@dependabot Bump commons-io from 2.6 to 2.7 in /src/it/MPMD-318-auxclasspath-includeTests/module-a (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/65;>#65) https://github.com/dependabot;>@dependabot Bump slf4jVersion from 1.7.25 to 1.7.36 (https://github-redirect.dependabot.com/apache/maven-pmd-plugin/issues/53;>#53) https://github.com/dependabot;>@dependabot Commits https://github.com/apache/maven-pmd-plugin/commit/a3add82e87bdeb3d0d99b0212452461db9986583;>a3add82 [maven-release-plugin] prepare release maven-pmd-plugin-3.17.0 https://github.com/apache/maven-pmd-plugin/commit/cf353c6b9cb14724ad677bcb60ac5e3c5ba6d92b;>cf353c6 (doc) Update release notes https://github.com/apache/maven-pmd-plugin/commit/027bf252a306a95b5ef2f42bd55430dfdd74ea0e;>027bf25 [MPMD-343] - Upgrade to PMD 6.46.0 https://github.com/apache/maven-pmd-plugin/commit/3585936ec00378cb4947947578c34eadb28e2b6a;>3585936 (doc) Update release notes https://github.com/apache/maven-pmd-plugin/commit/f26bec9283e0e0857f48deb8f2945bb807129407;>f26bec9 [MPMD-336] Replace deprecated calls to PMD https://github.com/apache/maven-pmd-plugin/commit/e82e92b3815fccf44ecd864c95518b5760b7436b;>e82e92b [MPMD-342] No debug log message issued when empty report shall be skipped and... https://github.com/apache/maven-pmd-plugin/commit/746779862fb4c4684dc275c382fcbac0b4a84b44;>7467798 [MPMD-337] Upgrade Maven Parent to 36
[GitHub] [maven-jar-plugin] jorsol opened a new pull request, #43: [MJAR-275] - Update maven-archiver to 3.6.0
jorsol opened a new pull request, #43: URL: https://github.com/apache/maven-jar-plugin/pull/43 This requires the release of plexus-archiver 4.3.0 and maven-archiver 3.6.0. Fixing the "MJAR-275 - outputTimestamp not applied to module-info; breaks reproducible builds" 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/MJAR) 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 `[MJAR-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MJAR-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [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 integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [X] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] stevecrox closed pull request #32: Mskins 191 dynamic library retrieval
stevecrox closed pull request #32: Mskins 191 dynamic library retrieval URL: https://github.com/apache/maven-fluido-skin/pull/32 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] stevecrox commented on pull request #32: Mskins 191 dynamic library retrieval
stevecrox commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147355223 I am interested in this skin, because maven allows me to incorporate documentation and analysis into a site. The problem is the current site style has dated. Historically full stack development has JS/HTML/CSS stored in an appropriate resources directory of a java project. This made developing frontends painful. Node.js/NPM appeared 10 years ago and you could build a mini webserver fairly easy with express and iterate there was much joy. We hit the problem I am addressing in this PR. The format NPM releases a project is different to Maven. There are several common approaches to integrate the UI with the backend 1) write a release time script which calls Maven and generates a JAR when the NPM project releases. 2) Use the latest java wrapper for JS 3) Write the front end so its hosted statically in its own webserver and the UI calls to the backend 4) Use the front end plugin to pull down the dependecies The problem with 1 is what we see here and requires bootstrap to make a change to support you. The problem with 2 (e.g. webjars) is Web Development is happy in its ecosystem. So adoption always fails (Personally I loved the maven extension that let me package js). Approach 3 isn't valid here, fundamentally what this skin offers are some resources and a template file to apache velocity. The last approach is what I have chosen, we use the frontend plugin to retrieve node/npm which are stored in a temporary directory. We use NPM to retrieve the releases and then the minify plugin to generate the JS artifacts. The result is no additional dependencies for users of the skin, there should be zero change from their perspective. I saw the comment on CDN, I have always worked in defense companies. Defense company infosec departments are not reasonable (and iften non technical) meaning this sort of stuff is developed in effectively air gapped environments and I have spent way to much of my life designing and pushing for mirrors of real world infrastructure. One of the reasons I love Maven is as a toolit makes redirecting to local mirrors really easy. As for why this change? I have a bootstrap 5 skin supporting a fixed navbar top but its a complete rewrite. Bootstrap has its examples and then there are HTML layouts -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] rmannibucau commented on pull request #32: Mskins 191 dynamic library retrieval
rmannibucau commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147350603 Not sure, using node today is not rocket science (at least no more than using velocity to create a template) but overall it would benefit end users (either using CDN or node to build the bundle). Can avoid the build postprocessing to rewrite the resources in site deployment which care - but I can also hear it is less and less used outside apache so maybe not worth it if we don't care for ourselves. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] michael-o commented on pull request #32: Mskins 191 dynamic library retrieval
michael-o commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147325263 I don't want this skin to be rocket science, but this makes it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] slachiewicz commented on pull request #32: Mskins 191 dynamic library retrieval
slachiewicz commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147321586 Main challenge is how to cut template, adjust macros. including 2 css and .js files doesn't have to be problem here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] rmannibucau commented on pull request #32: Mskins 191 dynamic library retrieval
rmannibucau commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147312549 @hboutemy exploding webjars and copying resources would work but would still rely on outdated plugins for the resources build, this is where using nodejs ecosystem would be a big plus for the theme until we go with CDN as mentionned which would make the game pretty different then. So, IMHO, to summarize it is not only about fetching but more about having a proper front build where node helps. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] hboutemy commented on pull request #32: Mskins 191 dynamic library retrieval
hboutemy commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147290751 notice: given updates to the skin requires to check the rendering, I had a look at how easy currently and I found: 1. it's easy to see the result of many edge cases: https://maven.apache.org/skins/maven-fluido-skin/ITs.html 2. but it's not so easy to see result for the sample page, given it uses previous skin version: https://maven.apache.org/skins/maven-fluido-skin/sample.html perhaps we should inject the sample page content into the 3 main layouts tests https://maven.apache.org/skins/maven-fluido-skin/sidebar/index.html we never had much contribution to skins, this is time to learn together how to improve that aspect -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] hboutemy commented on pull request #32: Mskins 191 dynamic library retrieval
hboutemy commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147281228 I love the idea of making updates of the 3 used js libraries easier, even if the hard work when upgrading is to check that the template still works as expected: at least, it eases having a quick look like Michael, I feel that introducing npm for that looks too heavy Could an approach like webjars do the same job? see https://github.com/webjars/bootstrap/blob/master/pom.xml -- 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-7485) Failed To Load JANSI Native Library
[
https://issues.apache.org/jira/browse/MNG-7485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550358#comment-17550358
]
Mark commented on MNG-7485:
---
Hi Michael - apologies for the late response, been on leave for the last week.
Thanks for the feedback, I will reach out to our DevOps team today and see if
that is the case.
> Failed To Load JANSI Native Library
> ---
>
> Key: MNG-7485
> URL: https://issues.apache.org/jira/browse/MNG-7485
> Project: Maven
> Issue Type: Bug
> Components: Errors
>Affects Versions: 3.8.5
>Reporter: Mark
>Priority: Minor
> Fix For: waiting-for-feedback, wontfix-candidate
>
>
> Hi All
> Wondering if anyone else has experienced a similar issue. I have recently
> upgraded to JDK 8 and Maven 3.8.5 and when i try mvn --version i get an error
> as such:
> {color:#505f79}Failed to load native
> library:jansi-2.4.0-bbb285ac9ffab828-libjansi.so. The native library file at
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so is not executable, make sure
> that the directory is mounted on a partition without the noexec flag, or set
> the jansi.tmpdir system property to point to a proper location. osinfo:
> Linux/x86_64{color}
> {color:#505f79}java.lang.UnsatisfiedLinkError:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so:
> /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so: failed to map segment from
> shared object: Operation not permitted{color}
> {color:#505f79}Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0){color}
> {color:#505f79}Maven home: /opt/apache-maven-3.8.5{color}
> {color:#505f79}Java version: 1.8.0_251, vendor: Oracle Corporation, runtime:
> /opt/jdk1.8.0_251/jre{color}
> {color:#505f79}Default locale: en_US, platform encoding: UTF-8{color}
> {color:#505f79}OS name: "linux", version: "3.10.0-1160.49.1.el7.x86_64",
> arch: "amd64", family: "unix"{color}
> {color:#505f79}java version "1.8.0_251"{color}
> {color:#505f79}Java(TM) SE Runtime Environment (build 1.8.0_251-b08){color}
> {color:#505f79}Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed
> mode){color}
> I have also tried installing JANSI through yum and that does not seem to
> resolve it. sudo yum -y install jansi-native
> Any help or guidance on how to resolve this would be greatly appreciated.
> CentOS Linux release 7.9.2009 (Core)
> apache-maven-3.8.5
> jdk1.8.0_251
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[GitHub] [maven-fluido-skin] michael-o commented on pull request #32: Mskins 191 dynamic library retrieval
michael-o commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147172114 The need for an upgrade does not relate to using npm or packaging. Maven sites are supposed to be self-contained because they can be archived, see site:jar. Using CDNs would completely break this. What is the real world benefit of this smart-ass minification? Does it really matter for this simple skin? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] rmannibucau commented on pull request #32: Mskins 191 dynamic library retrieval
rmannibucau commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147111762 Some comments because I think the issue is legitimate and we are very 'back' on the frontend deliveries for now. Maybe using download maven plugin or equivalent to grab the resources from a CDN can be sufficient for now but I think we should consider: 1. NOT packagng the resources in the jar, in particular because we don't own them and we should and will need to upgrade for various reasons (starting by the fact these versions are no more supported and have vulnerabilities) 2. use node to handle the minification instead of a plugin which does not handle some optimizations of modern web (using browserify at least) sounds like a very good choice for the final delivery so can be worth keeping frontend plugin 3. (optional) enable to use CDN in the theme which would be probably the best option for most people anyway -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-fluido-skin] michael-o commented on pull request #32: Mskins 191 dynamic library retrieval
michael-o commented on PR #32: URL: https://github.com/apache/maven-fluido-skin/pull/32#issuecomment-1147105353 I am rejecting this PR for the following reasons: * npm/nodejs bring a huge dependency chain for a simple problem * we don't want to rely on external tools * we rarely change those dependencies I see very little benefit in doing this for us. -- 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
