[GitHub] [maven-mvnd] kameshsampath commented on issue #337: Add Apple M1 build.
kameshsampath commented on issue #337: URL: https://github.com/apache/maven-mvnd/issues/337#issuecomment-1229076906 I am still waiting for this on M1, doing a build from source on M1 will help or I need to wait for official release? -- 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-7156) Parallel build can cause issues between clean and forked goals
[
https://issues.apache.org/jira/browse/MNG-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585642#comment-17585642
]
David Elliott commented on MNG-7156:
The added locking that allegedly fixed this issue seems to be causing my
existing plugin code to deadlock.
My plugin code running as an ordinary mojo in one project creates MojoExecution
for goals in other projects that have finished building. I'm sure they've
finished building because all of the projects are direct dependencies of the
project running my mojo.
I then execute those executions in a ThreadPoolExecutor as part of some other
work. Without this change it worked, with this change I'm getting reports that
it's deadlocked and the aggregator lock is somehow involved.
I have not had the chance to reproduce myself, and I will update this ticket
with additional information when I am able.
Having code work just fine with Maven 3.8.4 and earlier, but deadlock in Maven
3.8.5 and 3.8.6 is not ideal.
> Parallel build can cause issues between clean and forked goals
> --
>
> Key: MNG-7156
> URL: https://issues.apache.org/jira/browse/MNG-7156
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.8.5, 4.0.0-alpha-1, 4.0.0
>
>
> Running {{mvn -T12 clean verify -Papache-release}} From
> [https://github.com/apache/jackrabbit-filevault] leads to various exceptions
> caused by the invocation of the {{clean}} goal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-419) Allow @Parameter on setters methods
[
https://issues.apache.org/jira/browse/MPLUGIN-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585620#comment-17585620
]
Michael Osipov commented on MPLUGIN-419:
When is such a case? Do you have a use case for this?
> Allow @Parameter on setters methods
> ---
>
> Key: MPLUGIN-419
> URL: https://issues.apache.org/jira/browse/MPLUGIN-419
> Project: Maven Plugin Tools
> Issue Type: New Feature
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> We needn't filed for Mojo parameters.
> When setters method exist it is called first by Maven.
> We can declare Mojo as:
> {code:java}
> @Mojo( name = "my-mojo" )
> public class MyMojo extends AbstractMojo
> {
> @Parameter
> private String param;
> public void execute()
> {
> }
> }
> {code}
> In some case will be useful to have possibility to declare as:
> {code:java}
> @Mojo( name = "my-mojo" )
> public class MyMojo extends AbstractMojo
> {
> @Parameter
> public void setParam(String param)
> {
> // do something with param
> }
> public void execute()
> {
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MDEP-821) Bump mockito-core from 4.3.1 to 4.7.0
[ https://issues.apache.org/jira/browse/MDEP-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MDEP-821. Resolution: Fixed > Bump mockito-core from 4.3.1 to 4.7.0 > - > > Key: MDEP-821 > URL: https://issues.apache.org/jira/browse/MDEP-821 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-821) Bump mockito-core from 4.3.1 to 4.7.0
Slawomir Jaranowski created MDEP-821: Summary: Bump mockito-core from 4.3.1 to 4.7.0 Key: MDEP-821 URL: https://issues.apache.org/jira/browse/MDEP-821 Project: Maven Dependency Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: next-release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] dependabot[bot] opened a new pull request, #238: Bump jettyVersion from 9.4.45.v20220203 to 9.4.48.v20220622
dependabot[bot] opened a new pull request, #238: URL: https://github.com/apache/maven-dependency-plugin/pull/238 Bumps `jettyVersion` from 9.4.45.v20220203 to 9.4.48.v20220622. Updates `jetty-server` from 9.4.45.v20220203 to 9.4.48.v20220622 Release notes Sourced from https://github.com/eclipse/jetty.project/releases;>jetty-server's releases. 9.4.48.v20220622 End of Life Notice https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7958;>eclipse/jetty.project#7958 - Jetty 9.4.x is now at End of Community Support. (See issue for details) Critical Fix https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8184;>#8184 - All suffix globs except first fail to match if path has . character in prefix section 9.4.47.v20220610 Fixed Security Advisories (CVE-2022-2047) - https://github.com/eclipse/jetty.project/security/advisories/GHSA-cj7v-27pg-wf7q;>https://github.com/eclipse/jetty.project/security/advisories/GHSA-cj7v-27pg-wf7q - Invalid URI parsing may produce invalid HttpURI.authority (CVE-2022-2048) - https://github.com/eclipse/jetty.project/security/advisories/GHSA-wgmr-mf83-7x4j;>https://github.com/eclipse/jetty.project/security/advisories/GHSA-wgmr-mf83-7x4j - Invalid HTTP/2 requests can lead to denial of service Important https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7958;>eclipse/jetty.project#7958 - Jetty 9.4.x is now at End of Community Support. (See issue for details) Changelog https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8145;>#8145 - RegexPathSpec backport of optional group name/info lookup if regex fails https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8088;>#8088 - Add option to configure exitVm on ShutdownMonitor from System properties https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8067;>#8067 - Wall time usage in DoSFilter RateTracker results in false positive alert https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8014;>#8014 - Review HttpRequest URI construction (Resolves CVE-2022-2047) https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7976;>#7976 - Add TRANSFER_ENCODING violation for MultiPart RFC7578 parser. https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7947;>#7947 - Improved PathSpec handling for servletName pathInfo https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7935;>#7935 - Review HTTP/2 error handling (Resolves CVE-2022-2048) https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7918;>#7918 - PathMappings.asPathSpec does not allow root ServletPathSpec https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7863;>#7863 - Default servlet drops first accept-encoding header if there is more than one. https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7858;>#7858 - GZipHandler does not play nice with other handlers in HandlerCollection https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7837;>#7837 - Fix StatisticsHandler in the case a Handler throws exception. https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7809;>#7809 - Jetty 9.4.x 7801 duplicate set session cookies https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7748;>#7748 - Allow overriding of url-pattern mapping in ServletContextHandler to allow for regex or uri-template matching Dependencies https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8076;>#8076 - Bump asciidoctorj-diagram to 2.2.3 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7840;>#7840 - Bump asm.version to 9.3 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8143;>#8143 - Bump biz.aQute.bndlib to 6.3.1 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8055;>#8055 - Bump error_prone_annotations to 2.14.0 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8110;>#8110 - Bump google-cloud-datastore to 2.7.0 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8098;>#8098 - Bump grpc-core to 1.47.0 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7988;>#7988 - Bump hawtio-default to 2.15.0 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7999;>#7999 - Bump jackson-annotations to 2.13.3 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8000;>#8000 - Bump jackson-core to 2.13.3 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/8002;>#8002 - Bump jackson-databind to 2.13.3 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7846;>#7846 - Bump jacoco-maven-plugin to 0.8.8 https://github-redirect.dependabot.com/eclipse/jetty.project/issues/7816;>#7816 - Bump jnr-ffi to 2.2.12
[GitHub] [maven-dependency-plugin] slawekjaranowski merged pull request #234: Bump mockito-core from 4.3.1 to 4.7.0
slawekjaranowski merged PR #234: URL: https://github.com/apache/maven-dependency-plugin/pull/234 -- 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] (MPLUGIN-419) Allow @Parameter on setters methods
[
https://issues.apache.org/jira/browse/MPLUGIN-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MPLUGIN-419:
Description:
We needn't filed for Mojo parameters.
When setters method exist it is called first by Maven.
We can declare Mojo as:
{code:java}
@Mojo( name = "my-mojo" )
public class MyMojo extends AbstractMojo
{
@Parameter
private String param;
public void execute()
{
}
}
{code}
In some case will be useful to have possibility to declare as:
{code:java}
@Mojo( name = "my-mojo" )
public class MyMojo extends AbstractMojo
{
@Parameter
public void setParam(String param)
{
// do something with param
}
public void execute()
{
}
}
{code}
was:
We needn't filed for Mojo parameters.
When setters method exist it is called first by Maven.
> Allow @Parameter on setters methods
> ---
>
> Key: MPLUGIN-419
> URL: https://issues.apache.org/jira/browse/MPLUGIN-419
> Project: Maven Plugin Tools
> Issue Type: New Feature
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> We needn't filed for Mojo parameters.
> When setters method exist it is called first by Maven.
> We can declare Mojo as:
> {code:java}
> @Mojo( name = "my-mojo" )
> public class MyMojo extends AbstractMojo
> {
> @Parameter
> private String param;
> public void execute()
> {
> }
> }
> {code}
> In some case will be useful to have possibility to declare as:
> {code:java}
> @Mojo( name = "my-mojo" )
> public class MyMojo extends AbstractMojo
> {
> @Parameter
> public void setParam(String param)
> {
> // do something with param
> }
> public void execute()
> {
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MDEP-819) Unable to delete with purge-local-repository
[
https://issues.apache.org/jira/browse/MDEP-819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MDEP-819:
Fix Version/s: waiting-for-feedback
> Unable to delete with purge-local-repository
>
>
> Key: MDEP-819
> URL: https://issues.apache.org/jira/browse/MDEP-819
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 3.3.0
> Environment: This is happening on Windows Server 2016 running Jenkins
> as a service. Maven is 3.8.6 running on JDK11
>Reporter: Delany
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> I cant use this goal. Resolve works fine.
> {noformat}
> 15:11:36 java.io.IOException: File
> C:\Windows\system32\config\systemprofile\.m2\repository\aopalliance\aopalliance\1.0\aopalliance-1.0.jar
> unable to be deleted.
> 15:11:36 at org.codehaus.plexus.util.FileUtils.forceDelete
> (FileUtils.java:1403)
> 15:11:36 at org.codehaus.plexus.util.FileUtils.cleanDirectory
> (FileUtils.java:1658)
> 15:11:36 at org.codehaus.plexus.util.FileUtils.deleteDirectory
> (FileUtils.java:1604)
> 15:11:36 at
> org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.purgeArtifacts
> (PurgeLocalRepositoryMojo.java:649)
> 15:11:36 at
> org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.purgeLocalRepository
> (PurgeLocalRepositoryMojo.java:384)
> 15:11:36 at
> org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.execute
> (PurgeLocalRepositoryMojo.java:345)
> 15:11:36 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:370)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> 15:11:36 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> 15:11:36 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> 15:11:36 at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> 15:11:36 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> 15:11:36 at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:294)
> 15:11:36 at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:192)
> 15:11:36 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> 15:11:36 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> 15:11:36 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> 15:11:36 at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> 15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0
> (Native Method)
> 15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> 15:11:36 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> 15:11:36 at java.lang.reflect.Method.invoke (Method.java:566)
> 15:11:36 at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> 15:11:36 at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> 15:11:36 at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> 15:11:36 at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> 15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0
> (Native Method)
> 15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> 15:11:36 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> 15:11:36 at java.lang.reflect.Method.invoke (Method.java:566)
> 15:11:36 at org.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:53)
> 15:11:36 at org.apache.maven.wrapper.WrapperExecutor.execute
> (WrapperExecutor.java:152)
> 15:11:36 at org.apache.maven.wrapper.MavenWrapperMain.main
> (MavenWrapperMain.java:76){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-419) Allow @Parameter on setters methods
[ https://issues.apache.org/jira/browse/MPLUGIN-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585612#comment-17585612 ] Michael Osipov commented on MPLUGIN-419: I don't understand the description. I think you need to elaborate. > Allow @Parameter on setters methods > --- > > Key: MPLUGIN-419 > URL: https://issues.apache.org/jira/browse/MPLUGIN-419 > Project: Maven Plugin Tools > Issue Type: New Feature >Reporter: Slawomir Jaranowski >Priority: Major > > We needn't filed for Mojo parameters. > When setters method exist it is called first by Maven. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-419) Allow @Parameter on setters methods
Slawomir Jaranowski created MPLUGIN-419: --- Summary: Allow @Parameter on setters methods Key: MPLUGIN-419 URL: https://issues.apache.org/jira/browse/MPLUGIN-419 Project: Maven Plugin Tools Issue Type: New Feature Reporter: Slawomir Jaranowski We needn't filed for Mojo parameters. When setters method exist it is called first by Maven. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585611#comment-17585611
]
ASF GitHub Bot commented on MPLUGIN-417:
slawekjaranowski commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956426452
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -43,12 +42,6 @@
@Parameter( defaultValue = "${project}", readonly = true )
protected MavenProject project;
-/**
- * The goal prefix that will appear before the ":".
- */
-@Parameter
-protected String goalPrefix;
Review Comment:
It is need:
https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/resources/help-class-source.vm#L44
Without it HelpMojo.java will have unresolved value
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates three different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
> ## one with plain text and additional attributes for {{helpmojo}}
> ## another temporary one to be used from {{report}} containing HTML values
> # goal {{helpmojo}} evaluates the deserialized descriptor from 2 at
> execution time of the resulting "help" mojo
> # goal {{report}} evaluates the deserialized enhanced descriptor from 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-plugin-tools] slawekjaranowski commented on a diff in pull request #139: MPLUGIN-417 Descriptor with plain text by default
slawekjaranowski commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956426452
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -43,12 +42,6 @@
@Parameter( defaultValue = "${project}", readonly = true )
protected MavenProject project;
-/**
- * The goal prefix that will appear before the ":".
- */
-@Parameter
-protected String goalPrefix;
Review Comment:
It is need:
https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/resources/help-class-source.vm#L44
Without it HelpMojo.java will have unresolved value
--
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] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585608#comment-17585608
]
ASF GitHub Bot commented on MPLUGIN-417:
slawekjaranowski commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956423748
##
maven-plugin-tools-java/src/main/java/org/apache/maven/tools/plugin/extractor/javadoc/JavaJavadocMojoDescriptorExtractor.java:
##
@@ -56,11 +56,13 @@
/**
*
Review Comment:
I would not touch legacy extractors
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates three different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
> ## one with plain text and additional attributes for {{helpmojo}}
> ## another temporary one to be used from {{report}} containing HTML values
> # goal {{helpmojo}} evaluates the deserialized descriptor from 2 at
> execution time of the resulting "help" mojo
> # goal {{report}} evaluates the deserialized enhanced descriptor from 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-plugin-tools] slawekjaranowski commented on a diff in pull request #139: MPLUGIN-417 Descriptor with plain text by default
slawekjaranowski commented on code in PR #139: URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956423748 ## maven-plugin-tools-java/src/main/java/org/apache/maven/tools/plugin/extractor/javadoc/JavaJavadocMojoDescriptorExtractor.java: ## @@ -56,11 +56,13 @@ /** * Review Comment: I would not touch legacy extractors -- 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] hboutemy commented on pull request #190: [MNG-7353] Add missing dependencies to bootstrap.txt
hboutemy commented on PR #190: URL: https://github.com/apache/maven-integration-testing/pull/190#issuecomment-1228880820 The ITs don't at all use the fact that any version is LATEST, then using 2.7 and 2.8 instead of 3.0.0 and 3.1.1 is strictly the same result (I know, I wrote initial IT) in general, adapting ITs to already available content is just a good practice: I just forgot to disable my local proxy before testing locally, then did not see it early of course, downloading more content also work: but why download more when existing content can be sufficient? I know my comment comes too late, there is no need to revert, because there is no strong consequence -- 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] (MDEP-820) dependency:go-offline does not download plugin dependencies
Benjamin Asbach created MDEP-820:
Summary: dependency:go-offline does not download plugin
dependencies
Key: MDEP-820
URL: https://issues.apache.org/jira/browse/MDEP-820
Project: Maven Dependency Plugin
Issue Type: Bug
Components: go-offline
Affects Versions: 3.3.0
Environment: Linux, NixOS unstable
Reporter: Benjamin Asbach
It seems that `go-offline` goal does not download dependencies which are
declared as plugin dependency:
e.g
{code:xml}
org.codehaus.gmaven
groovy-maven-plugin
${groovy-maven-plugin.version}
org.codehaus.groovy
groovy-all
3.0.9
pom
org.codehaus.groovy
groovy-testng
{code}
After {{org.apache.maven.plugins:maven-dependency-plugin:3.3.0:go-offline}} I
still get:
{code}
[ERROR] Failed to execute goal
org.codehaus.gmaven:groovy-maven-plugin:2.1.1:execute (set-platform-properties)
on project mvnd: Execution set-platform-properties of goal
org.codehaus.gmaven:groovy-maven-plugin:2.1.1:execute failed: Plugin
org.codehaus.gmaven:groovy-maven-plugin:2.1.1 or one of its dependencies could
not be resolved: The following artifacts could not be resolved:
org.codehaus.groovy:groovy-all:pom:3.0.9,
org.codehaus.plexus:plexus-utils:jar:1.1: Cannot access central
([https://repo.maven.apache.org/maven2]) in offline mode and the artifact
org.codehaus.groovy:groovy-all:pom:3.0.9 has not been downloaded from it
before. -> [Help 1]
{code}
h3. How to reproduce
{code}
git clone https://github.com/apache/maven-mvnd.git
git checkout 0.8.0
mvn org.apache.maven.plugins:maven-dependency-plugin:3.3.0:go-offline -Pnative
-Dmaven.repo.local=/tmp/m2
mvn -o verify -Pnative -Dmaven.repo.local=/tmp/m2
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585599#comment-17585599
]
Henning Schmiedehausen commented on MRESOLVER-270:
--
BTW, here is an example of a maven-metadata file that contains both release and
snapshot versions:
{{}}
{{}}
{{ org.apache.logging.log4j}}
{{ log4j-api}}
{{ }}
{{ 3.0.0-SNAPSHOT}}
{{ 2.18.0}}
{{ }}
{{ 2.0-alpha1}}
{{ 2.0-alpha2}}
{{ 2.0-beta1}}
{{ 2.0-beta2}}
{{ 2.0-beta3}}
{{ 2.0-beta4}}
{{ 2.0-beta5}}
{{ 2.0-beta6}}
{{ 2.0-beta7}}
{{ 2.0-beta8}}
{{ 2.0-beta9}}
{{ 2.0-rc1}}
{{ 2.0-rc2}}
{{ 2.0}}
{{ 2.0.1}}
{{ 2.0.2}}
{{ 2.1}}
{{ 2.2}}
{{ 2.3}}
{{ 2.3.1}}
{{ 2.3.2}}
{{ 2.4}}
{{ 2.4.1}}
{{ 2.5}}
{{ 2.6}}
{{ 2.6.1}}
{{ 2.6.2}}
{{ 2.7}}
{{ 2.8}}
{{ 2.8.1}}
{{ 2.8.2}}
{{ 2.9.0}}
{{ 2.9.1}}
{{ 2.10.0}}
{{ 2.11.0}}
{{ 2.11.1}}
{{ 2.11.2}}
{{ 2.12.0}}
{{ 2.12.1}}
{{ 2.12.2}}
{{ 2.12.3}}
{{ 2.12.4}}
{{ 2.13.0}}
{{ 2.13.1}}
{{ 2.13.2}}
{{ 2.13.3}}
{{ 2.14.0}}
{{ 2.14.1}}
{{ 2.15.0}}
{{ 2.15.1-SNAPSHOT}}
{{ 2.16.0}}
{{ 2.17.0}}
{{ 2.17.1}}
{{ 2.17.2}}
{{ 2.17.3-SNAPSHOT}}
{{ 2.18.0}}
{{ 2.18.1-SNAPSHOT}}
{{ 3.0.0-SNAPSHOT}}
{{ }}
{{ 20220804201608}}
{{ }}
{{}}
And for these type of metadata files, the fix works fine.
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following
[jira] [Commented] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585596#comment-17585596
]
Henning Schmiedehausen commented on MRESOLVER-270:
--
The problem is that when the metadata is downloaded and stored in the local XML
file, it does not filter out snapshot versions for a repo where snapshots
disabled and does not filter out release versions for a repo where releases are
disabled. So my local "maven-metadata-snapshots.xml" for the "snapshot only
repo" for e.g. com.google.code.findbugs.jsr305 looks like this:
{{}}
{{ com.google.code.findbugs}}
{{ jsr305}}
{{ }}
{{ 3.0.2}}
{{ 3.0.2}}
{{ }}
{{ 2.0.2}}
{{ 2.0.3}}
{{ 3.0.0}}
{{ 3.0.1}}
{{ 3.0.2}}
{{ }}
{{ 20170331045618}}
{{ }}
{{}}
So the remote repo, which is configured to be snapshot only, no releases serves
its local metadata file, because I use the same repo in a different context as
"releases only, no snapshots". In fact, I have a local
"maven-metadata-releases.xml" file, which is identical (because it was served
from the same remote repository URL).
The version range resolver simply loads these files from disk (because it
trusts them) and then tries to resolve. So a local release artifact
(com.google.code.findbugs:jsr305:3.0.1) gets mapped by the range resolver to
the "snapshot" repository because that happened to be configured first. {*}And
that is wrong{*}. Because the locally stored metadata for that repository says
"hey, use this".
should these files be different or have different content? e.g. should the
"maven-metadata-snapshots.xml" not contain any versions? *probably.*
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could
[jira] [Updated] (MNG-7533) jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with maven v3.8.6
[ https://issues.apache.org/jira/browse/MNG-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7533: Fix Version/s: waiting-for-feedback > jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with > maven v3.8.6 > -- > > Key: MNG-7533 > URL: https://issues.apache.org/jira/browse/MNG-7533 > Project: Maven > Issue Type: Bug > Environment: Production >Reporter: John Roddy >Priority: Major > Fix For: waiting-for-feedback > > Attachments: MicrosoftTeams-image (5).png > > > jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with > maven v3.8.6. We're using the latest for maven which is v3.8.6. Please > upgrade jar to the latest to remediate the Prisma vulnerability associated > with maven v3.8.6. Thank you! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585591#comment-17585591
]
Tamás Cservenák commented on MRESOLVER-270:
---
I agree here, but IMHO:
* the commit
[https://github.com/apache/maven/commit/ce4579108d653be2ab7eab43be7d5951151dae5b]
feels wrong (as IMHO it fixes the issue that is in bullet below)
* the proper fix IMHO is to fix this method:
[https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java#L214-L243]
In short: maven "trusts" too much to remote metadata, that versions contained
in it are "okay" (they may be not, as this issue shows). This method also have
a handle on remote repository too, hence IMHO it could filter the versions,
based on remote repository policy. As in that case, the IT
maven-core-it-snapshots would return NO versions (as none of 1.0 and 1.1 are
snapshot versions) and none of this would happen (nor commit above would be
needed).
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot
[jira] [Commented] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585589#comment-17585589
]
Henning Schmiedehausen commented on MRESOLVER-270:
--
first wins is a reasonable strategy as long as you make sure that for snapshots
the first snapshot enabled repository wins and for releases the first release
enabled repository wins.
The current version range resolver ignores that and maps (that is the bug)
release versions onto repositories that are snapshot enabled/release disabled
and vice versa.
I am somewhat at a loss why this whole discussion is even happening. It is a
bug, it is reproducible, the change is a bug fix. End of story. Nothing to see
here.
You may be philosophically opposed to setting up remote repositories as shown
in
[https://github.com/apache/maven-integration-testing/blob/master/core-it-suite/src/test/resources/mng-7529/settings-template.xml;]
honestly I don't care. There is nothing in maven that flags such as setup as
"wrong" or "illegal" and while we can have disagreements on whether this makes
sense or not, unless maven fails right away with a big error message, it should
function as expected. It did not. Now it does.
Yes, it is possible to work around the bug by using only a single remote
repository reference (that is how we worked around locally). It is a
workaround. Maven should do the right thing, no matter whether you consider
that configuration reasonable or not. Hyrum's law applies here as well.
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be
[jira] [Comment Edited] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585586#comment-17585586
]
Tamás Cservenák edited comment on MRESOLVER-270 at 8/26/22 6:33 PM:
The more I think about this more is wrong:
* user defines two remote repositories with different policies for same URL
* the URL is a MRM group endpoint (and all modern MRMs merge metadata and they
are usually "mixed"!)
* consequence is that two remote repositories _metadata_ will report _same
versions_ for GA
* a release and a snapshot repository cannot (should not, best practice, etc)
have _overlapping versions_ per definitionem. A version cannot be "release" and
"snapshot" both at same time.
* the "first wins" branch is hit, due overlapping versions (so same version
will be attempted to put into map once for first and once for 2nd repo, where
2nd repository "looses").
was (Author: cstamas):
The more I think about this more is wrong:
* user defines two remote repositories with different policies for same URL
* the URL is a MRM group endpoint (and all modern MRMs merge metadata)
* consequence is that two remote repositories _metadata_ will report _same
versions_ for GA
* a release and a snapshot repository cannot (should not, best practice, etc)
have _overlapping versions_ per definitionem. A version cannot be "release" and
"snapshot" both at same time.
* the "first wins" branch is hit, due overlapping versions (so same version
will be attempted to put into map once for first and once for 2nd repo, where
2nd repository "looses").
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
>
[jira] [Commented] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585586#comment-17585586
]
Tamás Cservenák commented on MRESOLVER-270:
---
The more I think about this more is wrong:
* user defines two remote repositories with different policies for same URL
* the URL is a MRM group endpoint (and all modern MRMs merge metadata)
* consequence is that two remote repositories _metadata_ will report _same
versions_ for GA
* a release and a snapshot repository cannot (should not, best practice, etc)
have _overlapping versions_ per definitionem. A version is cannot be "release"
and "snapshot" both at same time.
* the "first wins" branch is hit, due overlapping versions (so same version
will be attempted to put into map once for first and once for 2nd repo, where
2nd repository "looses").
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot only repository) and that repository
> rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the snapshot
> repository from the
[jira] [Comment Edited] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585586#comment-17585586
]
Tamás Cservenák edited comment on MRESOLVER-270 at 8/26/22 6:31 PM:
The more I think about this more is wrong:
* user defines two remote repositories with different policies for same URL
* the URL is a MRM group endpoint (and all modern MRMs merge metadata)
* consequence is that two remote repositories _metadata_ will report _same
versions_ for GA
* a release and a snapshot repository cannot (should not, best practice, etc)
have _overlapping versions_ per definitionem. A version cannot be "release" and
"snapshot" both at same time.
* the "first wins" branch is hit, due overlapping versions (so same version
will be attempted to put into map once for first and once for 2nd repo, where
2nd repository "looses").
was (Author: cstamas):
The more I think about this more is wrong:
* user defines two remote repositories with different policies for same URL
* the URL is a MRM group endpoint (and all modern MRMs merge metadata)
* consequence is that two remote repositories _metadata_ will report _same
versions_ for GA
* a release and a snapshot repository cannot (should not, best practice, etc)
have _overlapping versions_ per definitionem. A version is cannot be "release"
and "snapshot" both at same time.
* the "first wins" branch is hit, due overlapping versions (so same version
will be attempted to put into map once for first and once for 2nd repo, where
2nd repository "looses").
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
>
[jira] [Commented] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585582#comment-17585582
]
ASF GitHub Bot commented on MPLUGIN-417:
kwin commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956314886
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -43,12 +42,6 @@
@Parameter( defaultValue = "${project}", readonly = true )
protected MavenProject project;
-/**
- * The goal prefix that will appear before the ":".
- */
-@Parameter
-protected String goalPrefix;
Review Comment:
goalPrefix is almost useless in helpmojo. It is just used for the report on
this mojo. Will try to remove this last remnant
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates three different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
> ## one with plain text and additional attributes for {{helpmojo}}
> ## another temporary one to be used from {{report}} containing HTML values
> # goal {{helpmojo}} evaluates the deserialized descriptor from 2 at
> execution time of the resulting "help" mojo
> # goal {{report}} evaluates the deserialized enhanced descriptor from 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585583#comment-17585583
]
ASF GitHub Bot commented on MPLUGIN-417:
kwin commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956314886
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -43,12 +42,6 @@
@Parameter( defaultValue = "${project}", readonly = true )
protected MavenProject project;
-/**
- * The goal prefix that will appear before the ":".
- */
-@Parameter
-protected String goalPrefix;
Review Comment:
goalPrefix is almost useless in helpmojo. It is just used for the html
report on this mojo. Will try to remove this last remnant
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates three different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
> ## one with plain text and additional attributes for {{helpmojo}}
> ## another temporary one to be used from {{report}} containing HTML values
> # goal {{helpmojo}} evaluates the deserialized descriptor from 2 at
> execution time of the resulting "help" mojo
> # goal {{report}} evaluates the deserialized enhanced descriptor from 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-plugin-tools] kwin commented on a diff in pull request #139: MPLUGIN-417 Descriptor with plain text by default
kwin commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956314886
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -43,12 +42,6 @@
@Parameter( defaultValue = "${project}", readonly = true )
protected MavenProject project;
-/**
- * The goal prefix that will appear before the ":".
- */
-@Parameter
-protected String goalPrefix;
Review Comment:
goalPrefix is almost useless in helpmojo. It is just used for the html
report on this mojo. Will try to remove this last remnant
--
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-plugin-tools] kwin commented on a diff in pull request #139: MPLUGIN-417 Descriptor with plain text by default
kwin commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956314886
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -43,12 +42,6 @@
@Parameter( defaultValue = "${project}", readonly = true )
protected MavenProject project;
-/**
- * The goal prefix that will appear before the ":".
- */
-@Parameter
-protected String goalPrefix;
Review Comment:
goalPrefix is almost useless in helpmojo. It is just used for the report on
this mojo. Will try to remove this last remnant
--
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] [Comment Edited] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585581#comment-17585581
]
Tamás Cservenák edited comment on MRESOLVER-270 at 8/26/22 6:25 PM:
Questions that are not really clear to me:
* Why does/would two repositories, that in _theory_ cannot have overlapping
versions (release vs snapshot) return same versions?
* Why is expected that Maven resolve this unexpected situation (snapshot
repository returns release versions?)
* This is clearly problem on server side: as I wrote long time ago, groups are
bad, and exactly due this "metadata merge" they do (am really sorry for
"inventing" grouped repository with Proximity in 2006, sorry for that, mea
culpa).
* try to target "more specific" repositories (members of the group), instead
to target groups, find the member release and member snapshot?
but i need to dig more... but also to understand the intent here.
was (Author: cstamas):
Questions that are not really clear to me:
* Why does/would two repositories, that in _theory_ cannot have overlapping
versions (release vs snapshot) return same versions?
* Why is expected that Maven resolve this unexpected situation (snapshot
repository returns release versions?)
* This is clearly problem on server side: as I wrote long time ago, groups are
bad, and exactly due this "metadata merge" they do (am really sorry for
"inventing" grouped repository with Proximity in 2006, sorry for that, mea
culpa).
* try to target "more specific" repositories (members of the group), instead
to target groups, find the member release and member snapshot?
but i need to dig more...
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not
[jira] [Commented] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585581#comment-17585581
]
Tamás Cservenák commented on MRESOLVER-270:
---
Questions that are not really clear to me:
* Why does/would two repositories, that in _theory_ cannot have overlapping
versions (release vs snapshot) return same versions?
* Why is expected that Maven resolve this unexpected situation (snapshot
repository returns release versions?)
* This is clearly problem on server side: as I wrote long time ago, groups are
bad, and exactly due this "metadata merge" they do (am really sorry for
"inventing" grouped repository with Proximity in 2006, sorry for that, mea
culpa).
* try to target "more specific" repositories (members of the group), instead
to target groups, find the member release and member snapshot?
but i need to dig more...
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot only repository) and that repository
> rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the
[jira] [Commented] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585580#comment-17585580
]
ASF GitHub Bot commented on MPLUGIN-417:
kwin commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956313386
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -88,44 +81,7 @@ public void execute()
return;
}
-if ( !"maven-plugin".equalsIgnoreCase( project.getArtifactId() )
-&& project.getArtifactId().toLowerCase().startsWith( "maven-" )
-&& project.getArtifactId().toLowerCase().endsWith( "-plugin" )
-&& !"org.apache.maven.plugins".equals( project.getGroupId() ) )
-{
-getLog().error( LS + LS + "Artifact Ids of the format
maven-___-plugin are reserved for" + LS
-+ "plugins in the Group Id
org.apache.maven.plugins" + LS
-+ "Please change your artifactId to the format
___-maven-plugin" + LS
-+ "In the future this error will break the
build." + LS + LS );
-}
Review Comment:
Logging it more than once is a bit redundant and you always need to run
descriptor after helpmojo anyways. Therefore just logging in descriptor seems
to be enough
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates three different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
> ## one with plain text and additional attributes for {{helpmojo}}
> ## another temporary one to be used from {{report}} containing HTML values
> # goal {{helpmojo}} evaluates the deserialized descriptor from 2 at
> execution time of the resulting "help" mojo
> # goal {{report}} evaluates the deserialized enhanced descriptor from 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-plugin-tools] kwin commented on a diff in pull request #139: MPLUGIN-417 Descriptor with plain text by default
kwin commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956313386
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -88,44 +81,7 @@ public void execute()
return;
}
-if ( !"maven-plugin".equalsIgnoreCase( project.getArtifactId() )
-&& project.getArtifactId().toLowerCase().startsWith( "maven-" )
-&& project.getArtifactId().toLowerCase().endsWith( "-plugin" )
-&& !"org.apache.maven.plugins".equals( project.getGroupId() ) )
-{
-getLog().error( LS + LS + "Artifact Ids of the format
maven-___-plugin are reserved for" + LS
-+ "plugins in the Group Id
org.apache.maven.plugins" + LS
-+ "Please change your artifactId to the format
___-maven-plugin" + LS
-+ "In the future this error will break the
build." + LS + LS );
-}
Review Comment:
Logging it more than once is a bit redundant and you always need to run
descriptor after helpmojo anyways. Therefore just logging in descriptor seems
to be enough
--
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] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585579#comment-17585579
]
ASF GitHub Bot commented on MPLUGIN-417:
slawekjaranowski commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956255139
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -43,12 +42,6 @@
@Parameter( defaultValue = "${project}", readonly = true )
protected MavenProject project;
-/**
- * The goal prefix that will appear before the ":".
- */
-@Parameter
-protected String goalPrefix;
Review Comment:
Why you move this parameter connected stuff to `DescriptorGeneratorMojo`
We lost goalPrefix in HelpGeneratorMojo ?
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/report/PluginReport.java:
##
@@ -195,11 +197,22 @@
* Path to {@code plugin.xml} plugin descriptor to generate the report
from.
*
* @since 3.5.1
+ * @deprecated No longer evaluated, use {@link
Review Comment:
unfinished ... docs
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -88,44 +81,7 @@ public void execute()
return;
}
-if ( !"maven-plugin".equalsIgnoreCase( project.getArtifactId() )
-&& project.getArtifactId().toLowerCase().startsWith( "maven-" )
-&& project.getArtifactId().toLowerCase().endsWith( "-plugin" )
-&& !"org.apache.maven.plugins".equals( project.getGroupId() ) )
-{
-getLog().error( LS + LS + "Artifact Ids of the format
maven-___-plugin are reserved for" + LS
-+ "plugins in the Group Id
org.apache.maven.plugins" + LS
-+ "Please change your artifactId to the format
___-maven-plugin" + LS
-+ "In the future this error will break the
build." + LS + LS );
-}
Review Comment:
Similar - is not valid for both goals descriptor and help?
##
pom.xml:
##
@@ -94,9 +94,13 @@
8
3.3.0
3.2.5
+ report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates three different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
> ## one with plain text and additional attributes for {{helpmojo}}
> ## another temporary one to be used from {{report}} containing HTML values
> # goal {{helpmojo}} evaluates the deserialized descriptor from 2 at
> execution time of the resulting "help" mojo
> # goal {{report}} evaluates the deserialized enhanced descriptor from 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-plugin-tools] slawekjaranowski commented on a diff in pull request #139: MPLUGIN-417 Descriptor with plain text by default
slawekjaranowski commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956255139
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -43,12 +42,6 @@
@Parameter( defaultValue = "${project}", readonly = true )
protected MavenProject project;
-/**
- * The goal prefix that will appear before the ":".
- */
-@Parameter
-protected String goalPrefix;
Review Comment:
Why you move this parameter connected stuff to `DescriptorGeneratorMojo`
We lost goalPrefix in HelpGeneratorMojo ?
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/report/PluginReport.java:
##
@@ -195,11 +197,22 @@
* Path to {@code plugin.xml} plugin descriptor to generate the report
from.
*
* @since 3.5.1
+ * @deprecated No longer evaluated, use {@link
Review Comment:
unfinished ... docs
##
maven-plugin-plugin/src/main/java/org/apache/maven/plugin/plugin/AbstractGeneratorMojo.java:
##
@@ -88,44 +81,7 @@ public void execute()
return;
}
-if ( !"maven-plugin".equalsIgnoreCase( project.getArtifactId() )
-&& project.getArtifactId().toLowerCase().startsWith( "maven-" )
-&& project.getArtifactId().toLowerCase().endsWith( "-plugin" )
-&& !"org.apache.maven.plugins".equals( project.getGroupId() ) )
-{
-getLog().error( LS + LS + "Artifact Ids of the format
maven-___-plugin are reserved for" + LS
-+ "plugins in the Group Id
org.apache.maven.plugins" + LS
-+ "Please change your artifactId to the format
___-maven-plugin" + LS
-+ "In the future this error will break the
build." + LS + LS );
-}
Review Comment:
Similar - is not valid for both goals descriptor and help?
##
pom.xml:
##
@@ -94,9 +94,13 @@
8
3.3.0
3.2.5
+
Review Comment:
IMHO the same major is ok
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585578#comment-17585578
]
Tamás Cservenák commented on MRESOLVER-270:
---
Something is fishy, and need to look more, but here is where am so far:
* modifed MNG-7529 IT to run with 3.8.6, it FAILS as expected
* then changed settings.xml of IT, by simply reordering repository definitions
(so made it maven-core-it-repo, maven-core-it-snapshors), and it PASSED
* This happens as two reposes (intentionally or unintentionally, unsure about
the real intent here) contains same versions (just like this issue above, uses
same URL, the MNG-7529 IT uses same remote repositories
* hence, the two repositories with return SAME SET of versions
* if you look at related commit
[https://github.com/apache/maven/commit/ce4579108d653be2ab7eab43be7d5951151dae5b]
it had this line:
{noformat}
!versionIndex.containsKey( version ) {noformat}
that was prepended by commit with "isEnabled...". In short, this means FIRST
REPO WINS.
* having said all this above, IMHO it is in spirit of Maven, as you have same
versions in your both remote repositories, you ordered them as such, and for
Maven "first repo wins"...
So far IMHO Maven behaves. Now, am still interested in intent here, as as I
wrote above, this issue can be circumvented in build.
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
>
[GitHub] [maven] hgschmie commented on a diff in pull request #789: [MNG-7529] Maven resolver makes bad repository choices
hgschmie commented on code in PR #789:
URL: https://github.com/apache/maven/pull/789#discussion_r956268261
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:
##
@@ -195,6 +199,18 @@ private Map getVersions(
RepositorySystemSession ses
return versionIndex;
}
+private boolean isEnabled( RemoteRepository remoteRepository, String
version )
+{
+if ( remoteRepository == null )
+{
+return true;
+}
+
+boolean snapshot = version != null && version.endsWith( SNAPSHOT );
Review Comment:
Hi @cstamas ,
Thank you for looking at this. I do not understand this comment. The check
is similar to the code in the DefaultVersionResolver (where it determines
whether a local file is a SNAPSHOT version by checking that it ends with
'SNAPSHOT'
(https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java#L208).
Can you explain a bit more what you mean by "timestamped snapshots" ?
--
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-7529) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MNG-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585571#comment-17585571
]
ASF GitHub Bot commented on MNG-7529:
-
hgschmie commented on code in PR #789:
URL: https://github.com/apache/maven/pull/789#discussion_r956268261
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:
##
@@ -195,6 +199,18 @@ private Map getVersions(
RepositorySystemSession ses
return versionIndex;
}
+private boolean isEnabled( RemoteRepository remoteRepository, String
version )
+{
+if ( remoteRepository == null )
+{
+return true;
+}
+
+boolean snapshot = version != null && version.endsWith( SNAPSHOT );
Review Comment:
Hi @cstamas ,
Thank you for looking at this. I do not understand this comment. The check
is similar to the code in the DefaultVersionResolver (where it determines
whether a local file is a SNAPSHOT version by checking that it ends with
'SNAPSHOT'
(https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java#L208).
Can you explain a bit more what you mean by "timestamped snapshots" ?
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MNG-7529
> URL: https://issues.apache.org/jira/browse/MNG-7529
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.6
>Reporter: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> This is the same problem as MRESOLVER-270. The problem is actually in the
> maven core, not in the resolver. See the description there.
>
> This bug is a placeholder for the fix PR.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7529) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MNG-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585570#comment-17585570
]
ASF GitHub Bot commented on MNG-7529:
-
hgschmie commented on code in PR #789:
URL: https://github.com/apache/maven/pull/789#discussion_r956268261
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:
##
@@ -195,6 +199,18 @@ private Map getVersions(
RepositorySystemSession ses
return versionIndex;
}
+private boolean isEnabled( RemoteRepository remoteRepository, String
version )
+{
+if ( remoteRepository == null )
+{
+return true;
+}
+
+boolean snapshot = version != null && version.endsWith( SNAPSHOT );
Review Comment:
Hi @cstamas ,
Thank you for looking at this. I am not I understand this comment. The check
is similar to the code in the DefaultVersionResolver (where it determines
whether a local file is a SNAPSHOT version by checking that it ends with
'SNAPSHOT'
(https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java#L208).
Can you explain a bit more what you mean by "timestamped snapshots" ?
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MNG-7529
> URL: https://issues.apache.org/jira/browse/MNG-7529
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.6
>Reporter: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> This is the same problem as MRESOLVER-270. The problem is actually in the
> maven core, not in the resolver. See the description there.
>
> This bug is a placeholder for the fix PR.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] hgschmie commented on a diff in pull request #789: [MNG-7529] Maven resolver makes bad repository choices
hgschmie commented on code in PR #789:
URL: https://github.com/apache/maven/pull/789#discussion_r956268261
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:
##
@@ -195,6 +199,18 @@ private Map getVersions(
RepositorySystemSession ses
return versionIndex;
}
+private boolean isEnabled( RemoteRepository remoteRepository, String
version )
+{
+if ( remoteRepository == null )
+{
+return true;
+}
+
+boolean snapshot = version != null && version.endsWith( SNAPSHOT );
Review Comment:
Hi @cstamas ,
Thank you for looking at this. I am not I understand this comment. The check
is similar to the code in the DefaultVersionResolver (where it determines
whether a local file is a SNAPSHOT version by checking that it ends with
'SNAPSHOT'
(https://github.com/apache/maven/blob/master/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java#L208).
Can you explain a bit more what you mean by "timestamped snapshots" ?
--
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-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585567#comment-17585567
]
Henning Schmiedehausen commented on MRESOLVER-270:
--
Hey Tamas,
Yes, that is intentional because that is how the bug manifested. The problem is
that there are two remote repos defined. I can reproduce this with virtual
repos or normal repos. The problem is not what backs it but how the metadata is
stored locally.
You can easily reproduce the bug with this E2E test:
[https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-7529]
The bug is in the maven core code, not in the resolver itself. The resolver
works fine; it is the VersionRange resolution that creates the version ->
repository mapping which maps release versions onto the snapshot repository and
vice versa.
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot only repository) and that repository
> rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the
[GitHub] [maven-integration-testing] hgschmie merged pull request #189: [MNG-7529] Integration test for MNG-7529
hgschmie merged PR #189: URL: https://github.com/apache/maven-integration-testing/pull/189 -- 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-2114) Surefire is going to kill self fork JVM. The exit has elapsed 30 seconds after System.exit(0).
[
https://issues.apache.org/jira/browse/SUREFIRE-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamalpreet updated SUREFIRE-2114:
-
Attachment: surefire.log
> Surefire is going to kill self fork JVM. The exit has elapsed 30 seconds
> after System.exit(0).
> ---
>
> Key: SUREFIRE-2114
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2114
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: Kamalpreet
>Priority: Critical
> Labels: Issue, process
> Attachments: surefire.log
>
>
> Hi Team,
> I'm using maven surefire plugin (Latest Version) to execute tests on two
> testing frameworks (e.g, jUnit, jBehave).
> Have tried to implement parallelisation by spawning couple of Threads which
> in turn create processes to execute surefire jar, taking it from -
> {code:java}
> ManagementFactory.getRuntimeMXBean().getSystemProperties().get("sun.java.command");{code}
> Code snippet to show process creation - *CustomRunner.java*
> {code:java}
> void run() {
> ProcessBuilder processBuilder = new ProcessBuilder(commandArray);
> Map environment = processBuilder.environment();
> environment.put("platformIndex", String.valueOf(platformIndex));
> try {
> processBuilder.inheritIO();
> Process p = processBuilder.start();
> LOGGER.info("Is Alive {} {}", p.isAlive(), LocalTime.now());
> int statusCode = p.waitFor();
> } catch (Exception e) {
> e.printStackTrace();
> }
> }{code}
> *EntryPoint.java*
> {code:java}
> for (int i = 0; i < 3; i++) {
> Thread thread = new Thread(new CustomRunner(commandArray,
> String.valueOf(i)));
> thread.start();
> threadList.add(thread);
> }
> threadList.forEach(thread -> {
> try {
> thread.join();
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
> });
>
> System.exit(exitcode);{code}
> After running two or sometimes three processes in corresponding Threads, the
> process execution got stuck on p.waitFor();
> Then the process exits after 30 secs and with error message "Surefire is
> going to kill self fork JVM. The exit has elapsed 30 seconds after
> System.exit(0)." resulting in Build Failure (sometimes it doesn't) though the
> tests have passed in their respective processes.
> Seems like surefire execution is stuck in some processes. Could you please
> let me know what can be the possible reasons for it and how to mitigate this?
> Tried extending the ForkedProcessTimeoutInSeconds to few minutes but no luck.
> Any help is much appreciated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585560#comment-17585560
]
Tamás Cservenák commented on MRESOLVER-270:
---
Also, in your snippet the two URLs of two reposes hints kinda they are same. Is
this intentional? As in that case, it means that you use a repo group (virtual
repo), where MRM already _merges_ metadata on server side (so
maven-metadata.xml contains both, snapshot and release versions)...
More info needed here, and will try to reproduce this.
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot only repository) and that repository
> rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the snapshot
> repository from the maven_settings.xml and enable snapshots for the "central"
> repository.
>
> Expected resolution: The DefaultVersionRangeResolver will not select the
> "first repository that contains the version" but looks at snapshot/release
> enabled and choose based on that information.
> I might find time to whip up a bug
[jira] [Commented] (MRESOLVER-270) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MRESOLVER-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585559#comment-17585559
]
Tamás Cservenák commented on MRESOLVER-270:
---
A question: is your snapshots repository (url \{{https://.../maven-public/}})
backed by a group/virtual repository maybe?
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MRESOLVER-270
> URL: https://issues.apache.org/jira/browse/MRESOLVER-270
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.6.3
>Reporter: Henning Schmiedehausen
>Priority: Major
>
> This also affects the maven-resolver-provider which is part of Maven core. I
> still file the bug here because it is easier to explain.
> I have a repository setup like this:
> {quote}
>
> repo
>
>
> snapshots
> [https://.../maven-public/]
>
> false
> never
> warn
>
>
> true
> interval:180
> fail
>
> default
>
>
> central
> [https://...|https://.../]/maven-public/
>
> true
> never
> warn
>
>
> false
> interval:180
> fail
>
> default
>
>
> {quote}
>
> Maven is trying to resolve the metadata from this component:
> [https://repo1.maven.org/maven2/com/googlecode/owasp-java-html-sanitizer/owasp-java-html-sanitizer/20220608.1/owasp-java-html-sanitizer-20220608.1.pom]
> which contains (after resolution):
>
> {quote}
> com.google.code.findbugs
> jsr305
> [2.0.1,)
> provided
>
> {quote}
> {quote}
> com.google.code.findbugs
> annotations
> [2.0.1,)
> provided
>
>
> {quote}
>
> what happens now is that maven uses the DefaultVersionRangeResolver, which
> contains this line:
> {quote}{{Metadata metadata = new DefaultMetadata(
> request.getArtifact().getGroupId(), request.getArtifact().getArtifactId(),
> MAVEN_METADATA_XML, Metadata.Nature.RELEASE_OR_SNAPSHOT );}}
> {quote}
> So it tries to resolve the dependency range against all the repositories.
> By searching for "Nature.RELEASE_OR_SNAPSHOT", both configured repositories
> (snapshot and central) are eligible and selected. And by the order, the
> snapshot repository is chosen first.
> Because both remote repositories map to the same local repository, the
> following version check in lines 210 - 231 iterates over the local versions
> and finds the matching version in the "snapshots" repository.
> All of this code is called from the ProjectDependenciesResolver (which is
> injected into a mojo as a component), when calling resolve() on a
> DependencyResolutionRequest for this specific component
> (com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1).
> It results in the following (slightly obscure) error message:
> {quote}Could not resolve dependencies for project
> com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:bundle:20220608.1:
> The following artifacts could not be resolved:
> com.google.code.findbugs:jsr305:jar:3.0.2,
> com.google.code.findbugs:annotations:jar:3.0.1u2: Could not find artifact
> com.google.code.findbugs:jsr305:jar:3.0.2
> {quote}
> However, that artifact is clearly present both in the local and remote
> repository.
>
> What happens is that the ProjectDependenciesResolver tries to resolve the
> (release) artifact om.google.code.findbugs:jsr305:jar:3.0.2 against the
> resolved repository (which is a snapshot only repository) and that repository
> rightfully refuses to resolve it. Hence the error message.
> I can fix this (which confirms this behavior) by removing the snapshot
> repository from the maven_settings.xml and enable snapshots for the "central"
> repository.
>
> Expected resolution: The DefaultVersionRangeResolver will not select the
> "first repository that contains the version" but looks at snapshot/release
> enabled and choose based on that information.
> I might find time to whip up a bug fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7529) Maven resolver makes bad repository choices when resolving version ranges
[
https://issues.apache.org/jira/browse/MNG-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585552#comment-17585552
]
ASF GitHub Bot commented on MNG-7529:
-
cstamas commented on code in PR #789:
URL: https://github.com/apache/maven/pull/789#discussion_r956235765
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:
##
@@ -195,6 +199,18 @@ private Map getVersions(
RepositorySystemSession ses
return versionIndex;
}
+private boolean isEnabled( RemoteRepository remoteRepository, String
version )
+{
+if ( remoteRepository == null )
+{
+return true;
+}
+
+boolean snapshot = version != null && version.endsWith( SNAPSHOT );
Review Comment:
What about timestamped snapshots?
> Maven resolver makes bad repository choices when resolving version ranges
> -
>
> Key: MNG-7529
> URL: https://issues.apache.org/jira/browse/MNG-7529
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.8.6
>Reporter: Henning Schmiedehausen
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0, 4.0.0-alpha-1, 4.0.0
>
>
> This is the same problem as MRESOLVER-270. The problem is actually in the
> maven core, not in the resolver. See the description there.
>
> This bug is a placeholder for the fix PR.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas commented on a diff in pull request #789: [MNG-7529] Maven resolver makes bad repository choices
cstamas commented on code in PR #789:
URL: https://github.com/apache/maven/pull/789#discussion_r956235765
##
maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionRangeResolver.java:
##
@@ -195,6 +199,18 @@ private Map getVersions(
RepositorySystemSession ses
return versionIndex;
}
+private boolean isEnabled( RemoteRepository remoteRepository, String
version )
+{
+if ( remoteRepository == null )
+{
+return true;
+}
+
+boolean snapshot = version != null && version.endsWith( SNAPSHOT );
Review Comment:
What about timestamped snapshots?
--
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-7533) jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with maven v3.8.6
[
https://issues.apache.org/jira/browse/MNG-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585528#comment-17585528
]
Michael Osipov commented on MNG-7533:
-
The dependency isn't used:
{noformat}
[INFO] --- maven-dependency-plugin:3.1.1:analyze (default-cli) @
wagon-http-shared ---
[WARNING] Used undeclared dependencies found:
[WARNING]org.codehaus.plexus:plexus-utils:jar:3.3.0:compile
[WARNING] Unused declared dependencies found:
[WARNING]commons-io:commons-io:jar:2.6:compile
[WARNING]org.slf4j:slf4j-simple:jar:1.7.32:test
[WARNING]org.apache.maven.wagon:wagon-provider-test:jar:3.5.3-SNAPSHOT:test
{noformat}
{{grep}} the source code...
> jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with
> maven v3.8.6
> --
>
> Key: MNG-7533
> URL: https://issues.apache.org/jira/browse/MNG-7533
> Project: Maven
> Issue Type: Bug
> Environment: Production
>Reporter: John Roddy
>Priority: Major
> Attachments: MicrosoftTeams-image (5).png
>
>
> jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with
> maven v3.8.6. We're using the latest for maven which is v3.8.6. Please
> upgrade jar to the latest to remediate the Prisma vulnerability associated
> with maven v3.8.6. Thank you!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7533) jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with maven v3.8.6
[
https://issues.apache.org/jira/browse/MNG-7533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585528#comment-17585528
]
Michael Osipov edited comment on MNG-7533 at 8/26/22 4:28 PM:
--
The dependency isn't used:
{noformat}
[INFO] --- maven-dependency-plugin:3.1.1:analyze (default-cli) @
wagon-http-shared ---
[WARNING] Used undeclared dependencies found:
[WARNING]org.codehaus.plexus:plexus-utils:jar:3.3.0:compile
[WARNING] Unused declared dependencies found:
[WARNING]commons-io:commons-io:jar:2.6:compile
[WARNING]org.slf4j:slf4j-simple:jar:1.7.32:test
[WARNING]org.apache.maven.wagon:wagon-provider-test:jar:3.5.3-SNAPSHOT:test
{noformat}
{{grep}} the source code...
This is a stupid, mechanical false positive.
was (Author: michael-o):
The dependency isn't used:
{noformat}
[INFO] --- maven-dependency-plugin:3.1.1:analyze (default-cli) @
wagon-http-shared ---
[WARNING] Used undeclared dependencies found:
[WARNING]org.codehaus.plexus:plexus-utils:jar:3.3.0:compile
[WARNING] Unused declared dependencies found:
[WARNING]commons-io:commons-io:jar:2.6:compile
[WARNING]org.slf4j:slf4j-simple:jar:1.7.32:test
[WARNING]org.apache.maven.wagon:wagon-provider-test:jar:3.5.3-SNAPSHOT:test
{noformat}
{{grep}} the source code...
> jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with
> maven v3.8.6
> --
>
> Key: MNG-7533
> URL: https://issues.apache.org/jira/browse/MNG-7533
> Project: Maven
> Issue Type: Bug
> Environment: Production
>Reporter: John Roddy
>Priority: Major
> Attachments: MicrosoftTeams-image (5).png
>
>
> jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with
> maven v3.8.6. We're using the latest for maven which is v3.8.6. Please
> upgrade jar to the latest to remediate the Prisma vulnerability associated
> with maven v3.8.6. Thank you!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-build-cache-extension] eltsovalex commented on pull request #24: added possibility to skip cache lookup per project or globally
eltsovalex commented on PR #24: URL: https://github.com/apache/maven-build-cache-extension/pull/24#issuecomment-1228645084 Sorry, I do not have an MNG number yet to add as a proper commit comment But basically this PR is about adding 2 new features which are required to use this extension in yet another complex multi-module project in Deutsche Bank 1) ability to skip cache lookup for a particular module or whole project (required to get some modules always built e.g. via a profile - e.g. I have some additional artifacts published by CI). Alternatively it allows an easy "force" rebuild of a whole project The difference with not using cache is that results are put into cache, just current matching versions are not taken from caches 2) ability to disable generated source restoration on a per-module level. This is required to overcome issues with some weird Maven plugins which go nuts when cached generated sources are present and produce incorrect build result -- 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-build-cache-extension] eltsovalex opened a new pull request, #24: added possibility to skip cache lookup per project or globally
eltsovalex opened a new pull request, #24: URL: https://github.com/apache/maven-build-cache-extension/pull/24 added possibility to skip generated sources restore on per-project level added some logging Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-417:
Fix Version/s: 3.7.0
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates three different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
> ## one with plain text and additional attributes for {{helpmojo}}
> ## another temporary one to be used from {{report}} containing HTML values
> # goal {{helpmojo}} evaluates the deserialized descriptor from 2 at
> execution time of the resulting "help" mojo
> # goal {{report}} evaluates the deserialized enhanced descriptor from 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPLUGIN-9) Add link to javadoc in configuration description page for user defined types of Mojos.
[ https://issues.apache.org/jira/browse/MPLUGIN-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MPLUGIN-9: -- Fix Version/s: 3.7.0 > Add link to javadoc in configuration description page for user defined types > of Mojos. > -- > > Key: MPLUGIN-9 > URL: https://issues.apache.org/jira/browse/MPLUGIN-9 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Mark Donszelmann >Assignee: Konrad Windszus >Priority: Minor > Fix For: 3.7.0 > > > The documentation page for the configuration of a Mojo, as currently > generated, > only documents basic types (booleans, Lists, Sets, Properties) but fails > to say anything about User Defined types (for which a class is picked up > from the Mojo directory). > A link to the javadoc could be added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MPLUGIN-9) Add link to javadoc in configuration description page for user defined types of Mojos.
[ https://issues.apache.org/jira/browse/MPLUGIN-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus reassigned MPLUGIN-9: - Assignee: Konrad Windszus > Add link to javadoc in configuration description page for user defined types > of Mojos. > -- > > Key: MPLUGIN-9 > URL: https://issues.apache.org/jira/browse/MPLUGIN-9 > Project: Maven Plugin Tools > Issue Type: Improvement >Reporter: Mark Donszelmann >Assignee: Konrad Windszus >Priority: Minor > > The documentation page for the configuration of a Mojo, as currently > generated, > only documents basic types (booleans, Lists, Sets, Properties) but fails > to say anything about User Defined types (for which a class is picked up > from the Mojo directory). > A link to the javadoc could be added. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7533) jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with maven v3.8.6
John Roddy created MNG-7533: --- Summary: jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with maven v3.8.6 Key: MNG-7533 URL: https://issues.apache.org/jira/browse/MNG-7533 Project: Maven Issue Type: Bug Environment: Production Reporter: John Roddy Attachments: MicrosoftTeams-image (5).png jar v2.6 has medium (CVE-2021-29425) Prisma vulnerability associated with maven v3.8.6. We're using the latest for maven which is v3.8.6. Please upgrade jar to the latest to remediate the Prisma vulnerability associated with maven v3.8.6. Thank you! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585441#comment-17585441
]
ASF GitHub Bot commented on MPLUGIN-417:
kwin commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956151146
##
maven-script/maven-plugin-tools-beanshell/src/main/java/org/apache/maven/tools/plugin/extractor/beanshell/BeanshellMojoDescriptorExtractor.java:
##
@@ -131,6 +131,7 @@ private MojoDescriptor createMojoDescriptor( String
basedir, String resource, Pl
throw new InvalidPluginDescriptorException( "Error scanning
beanshell script", evalError );
}
+// FIXME: convert javadocs
Review Comment:
necessary to convert javadocs -> xhtml for deprecated BSH extractor?
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates three different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
> ## one with plain text and additional attributes for {{helpmojo}}
> ## another temporary one to be used from {{report}} containing HTML values
> # goal {{helpmojo}} evaluates the deserialized descriptor from 2 at
> execution time of the resulting "help" mojo
> # goal {{report}} evaluates the deserialized enhanced descriptor from 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] dependabot[bot] opened a new pull request, #182: Bump maven-dependency-tree from 3.1.1 to 3.2.0
dependabot[bot] opened a new pull request, #182: URL: https://github.com/apache/maven-enforcer/pull/182 Bumps [maven-dependency-tree](https://github.com/apache/maven-dependency-tree) from 3.1.1 to 3.2.0. Release notes Sourced from https://github.com/apache/maven-dependency-tree/releases;>maven-dependency-tree's releases. 3.2.0 Releas notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922version=12351759;>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922version=12351759 Commits https://github.com/apache/maven-dependency-tree/commit/a1db75c9da781ab67f508f099f6e74ae921002f2;>a1db75c [maven-release-plugin] prepare release maven-dependency-tree-3.2.0 https://github.com/apache/maven-dependency-tree/commit/fa5a3a10c0ee7c766a67c67b2ac7a3bcc0647598;>fa5a3a1 Use plugins build template on Jenkins https://github.com/apache/maven-dependency-tree/commit/2f88228bfcc191a02a0c17a5dc5bff28a828045f;>2f88228 Bump project version before release https://github.com/apache/maven-dependency-tree/commit/deb4cd1f7f6184c9509a79e77e8ccc6f5e23;>deb4cd1 Update dependabot.yml https://github.com/apache/maven-dependency-tree/commit/80cadf4b910cd3f8b649342ef84477c6b24be4c2;>80cadf4 [MSHARED-1071] Drop maven 3.0 compatibility, Maven 3.2.5, Injects https://github.com/apache/maven-dependency-tree/commit/3f425fead0d4f4624f47472cb4159b45e544ebba;>3f425fe Use GitHub shared action v3 https://github.com/apache/maven-dependency-tree/commit/79d48cac9a22bf12a9b1474c8fb3bed6d02dfaf5;>79d48ca Bump maven-shared-components from 36 to 37 https://github.com/apache/maven-dependency-tree/commit/d0ebc5ce4fcafe26479d04b12e4a46e03e420c33;>d0ebc5c [MSHARED-1016] IT tests for transitive provided scope dependencies https://github.com/apache/maven-dependency-tree/commit/98c59715a3d32268e775908e72a3e542da95ff66;>98c5971 [MSHARED-1016] exclude transitive provided scope dependencies https://github.com/apache/maven-dependency-tree/commit/c001873c14b15be7468e4dc6e44ec0d73f4f9b37;>c001873 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/apache/maven-dependency-tree/compare/maven-dependency-tree-3.1.1...maven-dependency-tree-3.2.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-plugin-tools] kwin commented on a diff in pull request #139: MPLUGIN-417 Descriptor with plain text by default
kwin commented on code in PR #139: URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956151146 ## maven-script/maven-plugin-tools-beanshell/src/main/java/org/apache/maven/tools/plugin/extractor/beanshell/BeanshellMojoDescriptorExtractor.java: ## @@ -131,6 +131,7 @@ private MojoDescriptor createMojoDescriptor( String basedir, String resource, Pl throw new InvalidPluginDescriptorException( "Error scanning beanshell script", evalError ); } +// FIXME: convert javadocs Review Comment: necessary to convert javadocs -> xhtml for deprecated BSH extractor? -- 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] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585440#comment-17585440
]
ASF GitHub Bot commented on MPLUGIN-417:
kwin commented on code in PR #139:
URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956150516
##
maven-plugin-tools-java/src/main/java/org/apache/maven/tools/plugin/extractor/javadoc/JavaJavadocMojoDescriptorExtractor.java:
##
@@ -56,11 +56,13 @@
/**
*
Review Comment:
Do we need to convert javadoc -> XHTML for the legacy extractor as well?
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates three different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
> ## one with plain text and additional attributes for {{helpmojo}}
> ## another temporary one to be used from {{report}} containing HTML values
> # goal {{helpmojo}} evaluates the deserialized descriptor from 2 at
> execution time of the resulting "help" mojo
> # goal {{report}} evaluates the deserialized enhanced descriptor from 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-plugin-tools] kwin commented on a diff in pull request #139: MPLUGIN-417 Descriptor with plain text by default
kwin commented on code in PR #139: URL: https://github.com/apache/maven-plugin-tools/pull/139#discussion_r956150516 ## maven-plugin-tools-java/src/main/java/org/apache/maven/tools/plugin/extractor/javadoc/JavaJavadocMojoDescriptorExtractor.java: ## @@ -56,11 +56,13 @@ /** * Review Comment: Do we need to convert javadoc -> XHTML for the legacy extractor as well? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MJAVADOC-727) Make methods from JavadocUtil public which deal with retrieving "package-list"/"element-list"
[
https://issues.apache.org/jira/browse/MJAVADOC-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585436#comment-17585436
]
Slawomir Jaranowski commented on MJAVADOC-727:
--
As I good see mentioned methods are responsible for download a resources for
given url, with optional proxy configuration.
It looks for very common case - maybe we have utils for it?
For implementation in MPLUGIN-417 - I would don't touch it, even we can copy
this methods and later we can try to find / implemets a commons place for those.
> Make methods from JavadocUtil public which deal with retrieving
> "package-list"/"element-list"
> -
>
> Key: MJAVADOC-727
> URL: https://issues.apache.org/jira/browse/MJAVADOC-727
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> The functionality added in MPLUGIN-417 requires linking to javadoc class
> pages. In order to distinguish multiple javadoc site sources it needs access
> to the following methods:
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818]
> which help evaluating the {{package-list / element-list}} provided by a
> javadoc generated site.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-filtering] gnodet opened a new pull request, #46: Switch to maven 4 and the new api
gnodet opened a new pull request, #46: URL: https://github.com/apache/maven-filtering/pull/46 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MSHARED) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MSHARED-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MSHARED-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resources-plugin] gnodet opened a new pull request, #35: Switch to maven 4 and the new api
gnodet opened a new pull request, #35: URL: https://github.com/apache/maven-resources-plugin/pull/35 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MRESOURCES) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MRESOURCES-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MRESOURCES-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MJAVADOC-727) Make methods from JavadocUtil public which deal with retrieving "package-list"/"element-list"
[
https://issues.apache.org/jira/browse/MJAVADOC-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585416#comment-17585416
]
Konrad Windszus edited comment on MJAVADOC-727 at 8/26/22 2:36 PM:
---
[~sjaranowski] I am also fine moving those methods somewhere else where both
m-javadoc-p and m-plugin-tools can access them. Any suggestion? They require a
transitive dependency to Apache HttpClient.
was (Author: kwin):
[~sjaranowski] I am also fine moving those methods somewhere else where both
m-javadoc-p and m-plugin-tools can access them. Any suggestion?
> Make methods from JavadocUtil public which deal with retrieving
> "package-list"/"element-list"
> -
>
> Key: MJAVADOC-727
> URL: https://issues.apache.org/jira/browse/MJAVADOC-727
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> The functionality added in MPLUGIN-417 requires linking to javadoc class
> pages. In order to distinguish multiple javadoc site sources it needs access
> to the following methods:
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818]
> which help evaluating the {{package-list / element-list}} provided by a
> javadoc generated site.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-dependency-plugin] slawekjaranowski commented on pull request #234: Bump mockito-core from 4.3.1 to 4.7.0
slawekjaranowski commented on PR #234: URL: https://github.com/apache/maven-dependency-plugin/pull/234#issuecomment-1228568979 @dependabot recreate -- 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] (MJAVADOC-727) Make methods from JavadocUtil public which deal with retrieving "package-list"/"element-list"
[
https://issues.apache.org/jira/browse/MJAVADOC-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585416#comment-17585416
]
Konrad Windszus commented on MJAVADOC-727:
--
[~sjaranowski] I am also fine moving those methods somewhere else where both
m-javadoc-p and m-plugin-tools can access them. Any suggestion?
> Make methods from JavadocUtil public which deal with retrieving
> "package-list"/"element-list"
> -
>
> Key: MJAVADOC-727
> URL: https://issues.apache.org/jira/browse/MJAVADOC-727
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> The functionality added in MPLUGIN-417 requires linking to javadoc class
> pages. In order to distinguish multiple javadoc site sources it needs access
> to the following methods:
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818]
> which help evaluating the {{package-list / element-list}} provided by a
> javadoc generated site.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-727) Make methods from JavadocUtil public which deal with retrieving "package-list"/"element-list"
[
https://issues.apache.org/jira/browse/MJAVADOC-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585412#comment-17585412
]
Slawomir Jaranowski commented on MJAVADOC-727:
--
How you want to reach methods from m-javadoc-p in m-plugins-p?
I wouldn't add m-javadoc-p as dependency in m-plugins-p.
> Make methods from JavadocUtil public which deal with retrieving
> "package-list"/"element-list"
> -
>
> Key: MJAVADOC-727
> URL: https://issues.apache.org/jira/browse/MJAVADOC-727
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> The functionality added in MPLUGIN-417 requires linking to javadoc class
> pages. In order to distinguish multiple javadoc site sources it needs access
> to the following methods:
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818]
> which help evaluating the {{package-list / element-list}} provided by a
> javadoc generated site.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MJAVADOC-727) Make methods from JavadocUtil public which deal with retrieving "package-list"/"element-list"
[
https://issues.apache.org/jira/browse/MJAVADOC-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MJAVADOC-727:
-
Description:
The functionality added in MPLUGIN-417 requires linking to javadoc class pages.
In order to distinguish multiple javadoc site sources it needs access to the
following methods:
#
[https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
#
[https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818]
which help evaluating the {{package-list / element-list}} provided by a javadoc
generated site.
was:
The functionality added in MPLUGIN-417 requires linking to javadoc class pages.
In order to distinguish multiple javadoc site sources it needs access to the
following methods:
#
[https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
#
[https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818]
which help evaluating the {{package-list }}/ {{element-list}} provided by a
javadoc generated site.
> Make methods from JavadocUtil public which deal with retrieving
> "package-list"/"element-list"
> -
>
> Key: MJAVADOC-727
> URL: https://issues.apache.org/jira/browse/MJAVADOC-727
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> The functionality added in MPLUGIN-417 requires linking to javadoc class
> pages. In order to distinguish multiple javadoc site sources it needs access
> to the following methods:
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818]
> which help evaluating the {{package-list / element-list}} provided by a
> javadoc generated site.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-819) Unable to delete with purge-local-repository
[
https://issues.apache.org/jira/browse/MDEP-819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585404#comment-17585404
]
Michael Osipov commented on MDEP-819:
-
Windows file locking, open file handle, permissions?
> Unable to delete with purge-local-repository
>
>
> Key: MDEP-819
> URL: https://issues.apache.org/jira/browse/MDEP-819
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: purge-local-repository
>Affects Versions: 3.3.0
> Environment: This is happening on Windows Server 2016 running Jenkins
> as a service. Maven is 3.8.6 running on JDK11
>Reporter: Delany
>Priority: Major
>
> I cant use this goal. Resolve works fine.
> {noformat}
> 15:11:36 java.io.IOException: File
> C:\Windows\system32\config\systemprofile\.m2\repository\aopalliance\aopalliance\1.0\aopalliance-1.0.jar
> unable to be deleted.
> 15:11:36 at org.codehaus.plexus.util.FileUtils.forceDelete
> (FileUtils.java:1403)
> 15:11:36 at org.codehaus.plexus.util.FileUtils.cleanDirectory
> (FileUtils.java:1658)
> 15:11:36 at org.codehaus.plexus.util.FileUtils.deleteDirectory
> (FileUtils.java:1604)
> 15:11:36 at
> org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.purgeArtifacts
> (PurgeLocalRepositoryMojo.java:649)
> 15:11:36 at
> org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.purgeLocalRepository
> (PurgeLocalRepositoryMojo.java:384)
> 15:11:36 at
> org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.execute
> (PurgeLocalRepositoryMojo.java:345)
> 15:11:36 at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:370)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:351)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:171)
> 15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> 15:11:36 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> 15:11:36 at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> 15:11:36 at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> 15:11:36 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> 15:11:36 at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:294)
> 15:11:36 at org.apache.maven.DefaultMaven.doExecute
> (DefaultMaven.java:192)
> 15:11:36 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> 15:11:36 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
> 15:11:36 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> 15:11:36 at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> 15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0
> (Native Method)
> 15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> 15:11:36 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> 15:11:36 at java.lang.reflect.Method.invoke (Method.java:566)
> 15:11:36 at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> 15:11:36 at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> 15:11:36 at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> 15:11:36 at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> 15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0
> (Native Method)
> 15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> 15:11:36 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> 15:11:36 at java.lang.reflect.Method.invoke (Method.java:566)
> 15:11:36 at org.apache.maven.wrapper.BootstrapMainStarter.start
> (BootstrapMainStarter.java:53)
> 15:11:36 at org.apache.maven.wrapper.WrapperExecutor.execute
> (WrapperExecutor.java:152)
> 15:11:36 at org.apache.maven.wrapper.MavenWrapperMain.main
> (MavenWrapperMain.java:76){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (MSCRIPTING-10) Page Not Found on majority of Maven Scripting Plugin pages
[ https://issues.apache.org/jira/browse/MSCRIPTING-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov moved MNGSITE-490 to MSCRIPTING-10: -- Key: MSCRIPTING-10 (was: MNGSITE-490) Project: Maven Scripting (was: Maven Project Web Site) > Page Not Found on majority of Maven Scripting Plugin pages > -- > > Key: MSCRIPTING-10 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-10 > Project: Maven Scripting > Issue Type: Bug > Environment: Web >Reporter: Milan Kubec >Priority: Major > > On page https://maven.apache.org/plugins/maven-scripting-plugin/index.html > there is "Page Not Found" response for following links: > [https://maven.apache.org/plugins/maven-scripting-plugin/usage.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] > [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNGSITE-490) Page Not Found on majority of Maven Scripting Plugin pages
Milan Kubec created MNGSITE-490: --- Summary: Page Not Found on majority of Maven Scripting Plugin pages Key: MNGSITE-490 URL: https://issues.apache.org/jira/browse/MNGSITE-490 Project: Maven Project Web Site Issue Type: Bug Environment: Web Reporter: Milan Kubec On page https://maven.apache.org/plugins/maven-scripting-plugin/index.html there is "Page Not Found" response for following links: [https://maven.apache.org/plugins/maven-scripting-plugin/usage.html] [https://maven.apache.org/plugins/maven-scripting-plugin/faq.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/mail-lists.html] [https://maven.apache.org/plugins/maven-scripting-plugin/issue-tracking.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAVADOC-727) Make methods from JavadocUtil public which deal with retrieving "package-list"/"element-list"
[
https://issues.apache.org/jira/browse/MJAVADOC-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MJAVADOC-727:
-
Description:
The functionality added in MPLUGIN-417 requires linking to javadoc class pages.
In order to distinguish multiple javadoc site sources it needs access to the
following methods:
#
[https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
#
[https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818]
which help evaluating the {{package-list }}/ {{element-list}} provided by a
javadoc generated site.
was:
The functionality added in MPLUGIN-417 requires linking to javadoc class pages.
In order to distinguish multiple javadoc site sources it needs access to the
following methods:
#
[https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
#
https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818
> Make methods from JavadocUtil public which deal with retrieving
> "package-list"/"element-list"
> -
>
> Key: MJAVADOC-727
> URL: https://issues.apache.org/jira/browse/MJAVADOC-727
> Project: Maven Javadoc Plugin
> Issue Type: Improvement
> Components: javadoc
>Reporter: Konrad Windszus
>Priority: Major
>
> The functionality added in MPLUGIN-417 requires linking to javadoc class
> pages. In order to distinguish multiple javadoc site sources it needs access
> to the following methods:
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694]
> #
> [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818]
> which help evaluating the {{package-list }}/ {{element-list}} provided by a
> javadoc generated site.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEP-819) Unable to delete with purge-local-repository
Delany created MDEP-819:
---
Summary: Unable to delete with purge-local-repository
Key: MDEP-819
URL: https://issues.apache.org/jira/browse/MDEP-819
Project: Maven Dependency Plugin
Issue Type: Bug
Components: purge-local-repository
Affects Versions: 3.3.0
Environment: This is happening on Windows Server 2016 running Jenkins
as a service. Maven is 3.8.6 running on JDK11
Reporter: Delany
I cant use this goal. Resolve works fine.
{noformat}
15:11:36 java.io.IOException: File
C:\Windows\system32\config\systemprofile\.m2\repository\aopalliance\aopalliance\1.0\aopalliance-1.0.jar
unable to be deleted.
15:11:36 at org.codehaus.plexus.util.FileUtils.forceDelete
(FileUtils.java:1403)
15:11:36 at org.codehaus.plexus.util.FileUtils.cleanDirectory
(FileUtils.java:1658)
15:11:36 at org.codehaus.plexus.util.FileUtils.deleteDirectory
(FileUtils.java:1604)
15:11:36 at
org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.purgeArtifacts
(PurgeLocalRepositoryMojo.java:649)
15:11:36 at
org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.purgeLocalRepository
(PurgeLocalRepositoryMojo.java:384)
15:11:36 at
org.apache.maven.plugins.dependency.PurgeLocalRepositoryMojo.execute
(PurgeLocalRepositoryMojo.java:345)
15:11:36 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:370)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:351)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:171)
15:11:36 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
15:11:36 at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
15:11:36 at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
15:11:36 at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
15:11:36 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
15:11:36 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
15:11:36 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
15:11:36 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
15:11:36 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
15:11:36 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
15:11:36 at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)
15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
15:11:36 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
15:11:36 at java.lang.reflect.Method.invoke (Method.java:566)
15:11:36 at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
15:11:36 at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
15:11:36 at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
15:11:36 at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native
Method)
15:11:36 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
15:11:36 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
15:11:36 at java.lang.reflect.Method.invoke (Method.java:566)
15:11:36 at org.apache.maven.wrapper.BootstrapMainStarter.start
(BootstrapMainStarter.java:53)
15:11:36 at org.apache.maven.wrapper.WrapperExecutor.execute
(WrapperExecutor.java:152)
15:11:36 at org.apache.maven.wrapper.MavenWrapperMain.main
(MavenWrapperMain.java:76){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MJAVADOC-727) Make methods from JavadocUtil public which deal with retrieving "package-list"/"element-list"
Konrad Windszus created MJAVADOC-727: Summary: Make methods from JavadocUtil public which deal with retrieving "package-list"/"element-list" Key: MJAVADOC-727 URL: https://issues.apache.org/jira/browse/MJAVADOC-727 Project: Maven Javadoc Plugin Issue Type: Improvement Components: javadoc Reporter: Konrad Windszus The functionality added in MPLUGIN-417 requires linking to javadoc class pages. In order to distinguish multiple javadoc site sources it needs access to the following methods: # [https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1694] # https://github.com/apache/maven-javadoc-plugin/blob/231316be785782b61d96783fad111325868cfa1f/src/main/java/org/apache/maven/plugins/javadoc/JavadocUtil.java#L1818 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MDEP-818) Bump plexus-io from 3.2.0 to 3.4.0
[ https://issues.apache.org/jira/browse/MDEP-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MDEP-818. Resolution: Fixed > Bump plexus-io from 3.2.0 to 3.4.0 > -- > > Key: MDEP-818 > URL: https://issues.apache.org/jira/browse/MDEP-818 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: next-release > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] dependabot[bot] opened a new pull request, #237: Bump maven-dependency-analyzer from 1.12.0 to 1.13.0
dependabot[bot] opened a new pull request, #237: URL: https://github.com/apache/maven-dependency-plugin/pull/237 Bumps [maven-dependency-analyzer](https://github.com/apache/maven-dependency-analyzer) from 1.12.0 to 1.13.0. Commits https://github.com/apache/maven-dependency-analyzer/commit/dcae70b0707792d86f9dfa8974af8772ae8ed15f;>dcae70b [maven-release-plugin] prepare release maven-dependency-analyzer-1.13.0 https://github.com/apache/maven-dependency-analyzer/commit/563d2205159aaa1a8e6728225545010e9f56fc26;>563d220 Bump project version for next release https://github.com/apache/maven-dependency-analyzer/commit/77f3898db21f682f91b8308b3f273321fa3aa6d1;>77f3898 [MSHARED-1119] Cleanup IT tests https://github.com/apache/maven-dependency-analyzer/commit/d0634ddfda15c321f05f3683b91cd00345e392b9;>d0634dd Bump maven-shared-components from 36 to 37 https://github.com/apache/maven-dependency-analyzer/commit/d491c5c05150414c50e036d4f5a46b515fbd350d;>d491c5c Use shared GitHub action v3 https://github.com/apache/maven-dependency-analyzer/commit/78d6b23086935937148c35df5710dd78eed80881;>78d6b23 [MSHARED-1085] Upgrade Parent to 36 https://github.com/apache/maven-dependency-analyzer/commit/5588fcf77ce1d2bf42322d36df3d12183a730e88;>5588fcf Bump assertj-core from 3.22.0 to 3.23.1 https://github.com/apache/maven-dependency-analyzer/commit/396edf163cb4a40187ba3676a73cae2ab9c18a3a;>396edf1 Use asfMavenTlpPlgnBuild for project build https://github.com/apache/maven-dependency-analyzer/commit/e8d2f4d930b00a0ae8a57463110cf0fb7639ced4;>e8d2f4d Use the latest Maven 3.8.6 for build https://github.com/apache/maven-dependency-analyzer/commit/209d5d94653f6c35807befdd5bee6dc42056cff3;>209d5d9 Bump asm from 9.2 to 9.3 Additional commits viewable in https://github.com/apache/maven-dependency-analyzer/compare/maven-dependency-analyzer-1.12.0...maven-dependency-analyzer-1.13.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MDEP-818) Bump plexus-io from 3.2.0 to 3.4.0
Slawomir Jaranowski created MDEP-818: Summary: Bump plexus-io from 3.2.0 to 3.4.0 Key: MDEP-818 URL: https://issues.apache.org/jira/browse/MDEP-818 Project: Maven Dependency Plugin Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: next-release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] slawekjaranowski merged pull request #232: Bump plexus-io from 3.2.0 to 3.4.0
slawekjaranowski merged PR #232: URL: https://github.com/apache/maven-dependency-plugin/pull/232 -- 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] [Assigned] (MDEP-806) Dependency tree in verbose mode for war is empty
[
https://issues.apache.org/jira/browse/MDEP-806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MDEP-806:
Assignee: Slawomir Jaranowski
> Dependency tree in verbose mode for war is empty
>
>
> Key: MDEP-806
> URL: https://issues.apache.org/jira/browse/MDEP-806
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: tree
>Affects Versions: 3.3.0
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: next-release
>
>
> To reproduce, in project with {{war}} packaging:
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:3.3.0:tree -Dverbose
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPMD-353) API incompatibility with jansi after upgrading m-shared-utils
[
https://issues.apache.org/jira/browse/MPMD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585369#comment-17585369
]
Michael Osipov commented on MPMD-353:
-
[~adangel], my opinion: Yes, this bug is annoying, *but* has an easy
workaround. Moreover, we encourage people to move to latest Maven version. It
is your personal choice to stay on old versoin, but then you need to accept a
bit more work if something isn't right. Therefore, if you don't intend to
release 3.19.0 only next year and people are smart enough to find this issue
and how to work around, I wouldn't release a immediately 3.18.1.
> API incompatibility with jansi after upgrading m-shared-utils
> -
>
> Key: MPMD-353
> URL: https://issues.apache.org/jira/browse/MPMD-353
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.18.0
>Reporter: Piotr Zygielo
>Assignee: Andreas Dangel
>Priority: Major
>
> Affected maven versions:
> * 3.5.3
> * 3.6.3
> *Not* affected maven versions:
> * 3.2.5
> * 3.3.9
> * 3.8.6 (latest)
> {code:bash}
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd (pmd) on project
> UnnecessaryFullyQualifiedName: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd:
> java.lang.NoSuchMethodError:
> org.fusesource.jansi.AnsiConsole.out()Lorg/fusesource/jansi/AnsiPrintStream;
> Error: -
> Error: realm = plugin>org.apache.maven.plugins:maven-pmd-plugin:3.18.0
> Error: strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> Error: urls[0] =
> file:/home/runner/.m2/repository/org/apache/maven/plugins/maven-pmd-plugin/3.18.0/maven-pmd-plugin-3.18.0.jar
> Error: urls[1] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-core/6.48.0/pmd-core-6.48.0.jar
> Error: urls[2] =
> file:/home/runner/.m2/repository/org/antlr/antlr4-runtime/4.7.2/antlr4-runtime-4.7.2.jar
> Error: urls[3] =
> file:/home/runner/.m2/repository/com/beust/jcommander/1.48/jcommander-1.48.jar
> Error: urls[4] =
> file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8.jar
> Error: urls[5] =
> file:/home/runner/.m2/repository/org/ow2/asm/asm/9.3/asm-9.3.jar
> Error: urls[6] =
> file:/home/runner/.m2/repository/com/google/code/gson/gson/2.8.9/gson-2.8.9.jar
> Error: urls[7] =
> file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8-dom.jar
> Error: urls[8] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-java/6.48.0/pmd-java-6.48.0.jar
> Error: urls[9] =
> file:/home/runner/.m2/repository/org/apache/maven/shared/maven-artifact-transfer/0.13.1/maven-artifact-transfer-0.13.1.jar
> Error: urls[10] =
> file:/home/runner/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> Error: urls[11] =
> file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> Error: urls[12] =
> file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> Error: urls[13] =
> file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> Error: urls[14] =
> file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> Error: urls[15] =
> file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> Error: urls[16] =
> file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-component-annotations/2.1.1/plexus-component-annotations-2.1.1.jar
> Error: urls[17] =
> file:/home/runner/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/3.3.1/maven-common-artifact-filters-3.3.1.jar
> Error: urls[18] =
> file:/home/runner/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar
> Error: urls[19] =
> file:/home/runner/.m2/repository/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
> Error: urls[20] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-javascript/6.48.0/pmd-javascript-6.48.0.jar
> Error: urls[21] =
> file:/home/runner/.m2/repository/org/mozilla/rhino/1.7.14/rhino-1.7.14.jar
> Error: urls[22] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-jsp/6.48.0/pmd-jsp-6.48.0.jar
> Error: urls[23] =
> file:/home/runner/.m2/repository/org/slf4j/jul-to-slf4j/1.7.36/jul-to-slf4j-1.7.36.jar
> Error: urls[24] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.jar
> Error: urls[25] =
>
[GitHub] [maven-pmd-plugin] michael-o commented on pull request #91: [MPMD-353] - API incompatibility with jansi after upgrading m-shared-…
michael-o commented on PR #91: URL: https://github.com/apache/maven-pmd-plugin/pull/91#issuecomment-1228489243 I wonder why it was necessary before? Was behavior of Jansi in previously different? -- 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] (MPMD-353) API incompatibility with jansi after upgrading m-shared-utils
[
https://issues.apache.org/jira/browse/MPMD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel updated MPMD-353:
Description:
Affected maven versions:
* 3.5.3
* 3.6.3
*Not* affected maven versions:
* 3.2.5
* 3.3.9
* 3.8.6 (latest)
{code:bash}
Error: Failed to execute goal
org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd (pmd) on project
UnnecessaryFullyQualifiedName: Execution pmd of goal
org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd:
java.lang.NoSuchMethodError:
org.fusesource.jansi.AnsiConsole.out()Lorg/fusesource/jansi/AnsiPrintStream;
Error: -
Error: realm = plugin>org.apache.maven.plugins:maven-pmd-plugin:3.18.0
Error: strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
Error: urls[0] =
file:/home/runner/.m2/repository/org/apache/maven/plugins/maven-pmd-plugin/3.18.0/maven-pmd-plugin-3.18.0.jar
Error: urls[1] =
file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-core/6.48.0/pmd-core-6.48.0.jar
Error: urls[2] =
file:/home/runner/.m2/repository/org/antlr/antlr4-runtime/4.7.2/antlr4-runtime-4.7.2.jar
Error: urls[3] =
file:/home/runner/.m2/repository/com/beust/jcommander/1.48/jcommander-1.48.jar
Error: urls[4] =
file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8.jar
Error: urls[5] =
file:/home/runner/.m2/repository/org/ow2/asm/asm/9.3/asm-9.3.jar
Error: urls[6] =
file:/home/runner/.m2/repository/com/google/code/gson/gson/2.8.9/gson-2.8.9.jar
Error: urls[7] =
file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8-dom.jar
Error: urls[8] =
file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-java/6.48.0/pmd-java-6.48.0.jar
Error: urls[9] =
file:/home/runner/.m2/repository/org/apache/maven/shared/maven-artifact-transfer/0.13.1/maven-artifact-transfer-0.13.1.jar
Error: urls[10] =
file:/home/runner/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
Error: urls[11] =
file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
Error: urls[12] =
file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
Error: urls[13] =
file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
Error: urls[14] =
file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
Error: urls[15] =
file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
Error: urls[16] =
file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-component-annotations/2.1.1/plexus-component-annotations-2.1.1.jar
Error: urls[17] =
file:/home/runner/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/3.3.1/maven-common-artifact-filters-3.3.1.jar
Error: urls[18] =
file:/home/runner/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar
Error: urls[19] =
file:/home/runner/.m2/repository/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
Error: urls[20] =
file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-javascript/6.48.0/pmd-javascript-6.48.0.jar
Error: urls[21] =
file:/home/runner/.m2/repository/org/mozilla/rhino/1.7.14/rhino-1.7.14.jar
Error: urls[22] =
file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-jsp/6.48.0/pmd-jsp-6.48.0.jar
Error: urls[23] =
file:/home/runner/.m2/repository/org/slf4j/jul-to-slf4j/1.7.36/jul-to-slf4j-1.7.36.jar
Error: urls[24] =
file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.jar
Error: urls[25] =
file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.11.1/doxia-logging-api-1.11.1.jar
Error: urls[26] =
file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.11.1/doxia-decoration-model-1.11.1.jar
Error: urls[27] =
file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.11.1/doxia-site-renderer-1.11.1.jar
Error: urls[28] =
file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-core/1.11.1/doxia-core-1.11.1.jar
Error: urls[29] =
file:/home/runner/.m2/repository/org/apache/commons/commons-text/1.3/commons-text-1.3.jar
Error: urls[30] =
file:/home/runner/.m2/repository/org/apache/httpcomponents/httpcore/4.4.14/httpcore-4.4.14.jar
Error: urls[31] =
file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-skin-model/1.11.1/doxia-skin-model-1.11.1.jar
Error: urls[32] =
file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.11.1/doxia-module-xhtml-1.11.1.jar
Error: urls[33] =
file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml5/1.11.1/doxia-module-xhtml5-1.11.1.jar
Error: urls[34] =
[jira] [Commented] (MPMD-353) API incompatibility with jansi after upgrading m-shared-utils
[
https://issues.apache.org/jira/browse/MPMD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585359#comment-17585359
]
Andreas Dangel commented on MPMD-353:
-
I've tested the original suggestion
{quote}Maybe not call method MessageUtils.setColorEnabled from pmd?
{quote}
and it turns out, that this method call doesn't seem to be necessary at all.
I've tested various combinations (toolchain and debug logging) and always got
correctly colorized log output. If I remember correctly, I had the problem when
executing PMD through toolchain, that maven logging was colorized, but the log
output produced by PMD run via toolchain wasn't - but I couldn't reproduce the
problem now.
I've created a PR -> [https://github.com/apache/maven-pmd-plugin/pull/91]
Let's see, if the CI builds turns green again
->
[https://ci-maven.apache.org/blue/organizations/jenkins/Maven%2Fmaven-box%2Fmaven-pmd-plugin/detail/MPMD-353/1/pipeline]
[~michael-o] Would this "bug" justify a 3.18.1 version or should it go into a
future 3.19.0? Please create the version in JIRA, thanks!
Only old maven versions would are affected...
> API incompatibility with jansi after upgrading m-shared-utils
> -
>
> Key: MPMD-353
> URL: https://issues.apache.org/jira/browse/MPMD-353
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.18.0
>Reporter: Piotr Zygielo
>Assignee: Andreas Dangel
>Priority: Major
>
> {code:bash}
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd (pmd) on project
> UnnecessaryFullyQualifiedName: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd:
> java.lang.NoSuchMethodError:
> org.fusesource.jansi.AnsiConsole.out()Lorg/fusesource/jansi/AnsiPrintStream;
> Error: -
> Error: realm = plugin>org.apache.maven.plugins:maven-pmd-plugin:3.18.0
> Error: strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> Error: urls[0] =
> file:/home/runner/.m2/repository/org/apache/maven/plugins/maven-pmd-plugin/3.18.0/maven-pmd-plugin-3.18.0.jar
> Error: urls[1] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-core/6.48.0/pmd-core-6.48.0.jar
> Error: urls[2] =
> file:/home/runner/.m2/repository/org/antlr/antlr4-runtime/4.7.2/antlr4-runtime-4.7.2.jar
> Error: urls[3] =
> file:/home/runner/.m2/repository/com/beust/jcommander/1.48/jcommander-1.48.jar
> Error: urls[4] =
> file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8.jar
> Error: urls[5] =
> file:/home/runner/.m2/repository/org/ow2/asm/asm/9.3/asm-9.3.jar
> Error: urls[6] =
> file:/home/runner/.m2/repository/com/google/code/gson/gson/2.8.9/gson-2.8.9.jar
> Error: urls[7] =
> file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8-dom.jar
> Error: urls[8] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-java/6.48.0/pmd-java-6.48.0.jar
> Error: urls[9] =
> file:/home/runner/.m2/repository/org/apache/maven/shared/maven-artifact-transfer/0.13.1/maven-artifact-transfer-0.13.1.jar
> Error: urls[10] =
> file:/home/runner/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> Error: urls[11] =
> file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> Error: urls[12] =
> file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> Error: urls[13] =
> file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> Error: urls[14] =
> file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> Error: urls[15] =
> file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> Error: urls[16] =
> file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-component-annotations/2.1.1/plexus-component-annotations-2.1.1.jar
> Error: urls[17] =
> file:/home/runner/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/3.3.1/maven-common-artifact-filters-3.3.1.jar
> Error: urls[18] =
> file:/home/runner/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar
> Error: urls[19] =
> file:/home/runner/.m2/repository/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
> Error: urls[20] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-javascript/6.48.0/pmd-javascript-6.48.0.jar
> Error: urls[21] =
> file:/home/runner/.m2/repository/org/mozilla/rhino/1.7.14/rhino-1.7.14.jar
> Error: urls[22] =
>
[GitHub] [maven-pmd-plugin] adangel opened a new pull request, #91: [MPMD-353] - API incompatibility with jansi after upgrading m-shared-…
adangel opened a new pull request, #91: URL: https://github.com/apache/maven-pmd-plugin/pull/91 …utils The call to `MessageUtils.setColorEnabled()` is not needed. Log output from PMD is correctly colored depending on the maven settings. No special handling is needed. https://issues.apache.org/jira/browse/MPMD-353 I tested this locally - the API incompatibility is now gone for maven version 3.5.3 and 3.6.3. With this change, the plugin works now out of the box again with all maven version since 3.3.9 (didn't test older versions). 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/MPMD) 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 `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-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. - [ ] 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
[jira] [Updated] (MPMD-353) API incompatibility with jansi after upgrading m-shared-utils
[
https://issues.apache.org/jira/browse/MPMD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel updated MPMD-353:
Summary: API incompatibility with jansi after upgrading m-shared-utils
(was: An API incompatibility was encountered while executing
org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd)
> API incompatibility with jansi after upgrading m-shared-utils
> -
>
> Key: MPMD-353
> URL: https://issues.apache.org/jira/browse/MPMD-353
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.18.0
>Reporter: Piotr Zygielo
>Priority: Major
>
> {code:bash}
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd (pmd) on project
> UnnecessaryFullyQualifiedName: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd:
> java.lang.NoSuchMethodError:
> org.fusesource.jansi.AnsiConsole.out()Lorg/fusesource/jansi/AnsiPrintStream;
> Error: -
> Error: realm = plugin>org.apache.maven.plugins:maven-pmd-plugin:3.18.0
> Error: strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> Error: urls[0] =
> file:/home/runner/.m2/repository/org/apache/maven/plugins/maven-pmd-plugin/3.18.0/maven-pmd-plugin-3.18.0.jar
> Error: urls[1] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-core/6.48.0/pmd-core-6.48.0.jar
> Error: urls[2] =
> file:/home/runner/.m2/repository/org/antlr/antlr4-runtime/4.7.2/antlr4-runtime-4.7.2.jar
> Error: urls[3] =
> file:/home/runner/.m2/repository/com/beust/jcommander/1.48/jcommander-1.48.jar
> Error: urls[4] =
> file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8.jar
> Error: urls[5] =
> file:/home/runner/.m2/repository/org/ow2/asm/asm/9.3/asm-9.3.jar
> Error: urls[6] =
> file:/home/runner/.m2/repository/com/google/code/gson/gson/2.8.9/gson-2.8.9.jar
> Error: urls[7] =
> file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8-dom.jar
> Error: urls[8] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-java/6.48.0/pmd-java-6.48.0.jar
> Error: urls[9] =
> file:/home/runner/.m2/repository/org/apache/maven/shared/maven-artifact-transfer/0.13.1/maven-artifact-transfer-0.13.1.jar
> Error: urls[10] =
> file:/home/runner/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> Error: urls[11] =
> file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> Error: urls[12] =
> file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> Error: urls[13] =
> file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> Error: urls[14] =
> file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> Error: urls[15] =
> file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> Error: urls[16] =
> file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-component-annotations/2.1.1/plexus-component-annotations-2.1.1.jar
> Error: urls[17] =
> file:/home/runner/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/3.3.1/maven-common-artifact-filters-3.3.1.jar
> Error: urls[18] =
> file:/home/runner/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar
> Error: urls[19] =
> file:/home/runner/.m2/repository/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
> Error: urls[20] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-javascript/6.48.0/pmd-javascript-6.48.0.jar
> Error: urls[21] =
> file:/home/runner/.m2/repository/org/mozilla/rhino/1.7.14/rhino-1.7.14.jar
> Error: urls[22] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-jsp/6.48.0/pmd-jsp-6.48.0.jar
> Error: urls[23] =
> file:/home/runner/.m2/repository/org/slf4j/jul-to-slf4j/1.7.36/jul-to-slf4j-1.7.36.jar
> Error: urls[24] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.jar
> Error: urls[25] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.11.1/doxia-logging-api-1.11.1.jar
> Error: urls[26] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.11.1/doxia-decoration-model-1.11.1.jar
> Error: urls[27] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.11.1/doxia-site-renderer-1.11.1.jar
> Error: urls[28] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-core/1.11.1/doxia-core-1.11.1.jar
> Error:
[jira] [Assigned] (MPMD-353) API incompatibility with jansi after upgrading m-shared-utils
[
https://issues.apache.org/jira/browse/MPMD-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel reassigned MPMD-353:
---
Assignee: Andreas Dangel
> API incompatibility with jansi after upgrading m-shared-utils
> -
>
> Key: MPMD-353
> URL: https://issues.apache.org/jira/browse/MPMD-353
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 3.18.0
>Reporter: Piotr Zygielo
>Assignee: Andreas Dangel
>Priority: Major
>
> {code:bash}
> Error: Failed to execute goal
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd (pmd) on project
> UnnecessaryFullyQualifiedName: Execution pmd of goal
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-pmd-plugin:3.18.0:pmd:
> java.lang.NoSuchMethodError:
> org.fusesource.jansi.AnsiConsole.out()Lorg/fusesource/jansi/AnsiPrintStream;
> Error: -
> Error: realm = plugin>org.apache.maven.plugins:maven-pmd-plugin:3.18.0
> Error: strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> Error: urls[0] =
> file:/home/runner/.m2/repository/org/apache/maven/plugins/maven-pmd-plugin/3.18.0/maven-pmd-plugin-3.18.0.jar
> Error: urls[1] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-core/6.48.0/pmd-core-6.48.0.jar
> Error: urls[2] =
> file:/home/runner/.m2/repository/org/antlr/antlr4-runtime/4.7.2/antlr4-runtime-4.7.2.jar
> Error: urls[3] =
> file:/home/runner/.m2/repository/com/beust/jcommander/1.48/jcommander-1.48.jar
> Error: urls[4] =
> file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8.jar
> Error: urls[5] =
> file:/home/runner/.m2/repository/org/ow2/asm/asm/9.3/asm-9.3.jar
> Error: urls[6] =
> file:/home/runner/.m2/repository/com/google/code/gson/gson/2.8.9/gson-2.8.9.jar
> Error: urls[7] =
> file:/home/runner/.m2/repository/net/sourceforge/saxon/saxon/9.1.0.8/saxon-9.1.0.8-dom.jar
> Error: urls[8] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-java/6.48.0/pmd-java-6.48.0.jar
> Error: urls[9] =
> file:/home/runner/.m2/repository/org/apache/maven/shared/maven-artifact-transfer/0.13.1/maven-artifact-transfer-0.13.1.jar
> Error: urls[10] =
> file:/home/runner/.m2/repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> Error: urls[11] =
> file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> Error: urls[12] =
> file:/home/runner/.m2/repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> Error: urls[13] =
> file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> Error: urls[14] =
> file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> Error: urls[15] =
> file:/home/runner/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> Error: urls[16] =
> file:/home/runner/.m2/repository/org/codehaus/plexus/plexus-component-annotations/2.1.1/plexus-component-annotations-2.1.1.jar
> Error: urls[17] =
> file:/home/runner/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/3.3.1/maven-common-artifact-filters-3.3.1.jar
> Error: urls[18] =
> file:/home/runner/.m2/repository/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar
> Error: urls[19] =
> file:/home/runner/.m2/repository/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
> Error: urls[20] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-javascript/6.48.0/pmd-javascript-6.48.0.jar
> Error: urls[21] =
> file:/home/runner/.m2/repository/org/mozilla/rhino/1.7.14/rhino-1.7.14.jar
> Error: urls[22] =
> file:/home/runner/.m2/repository/net/sourceforge/pmd/pmd-jsp/6.48.0/pmd-jsp-6.48.0.jar
> Error: urls[23] =
> file:/home/runner/.m2/repository/org/slf4j/jul-to-slf4j/1.7.36/jul-to-slf4j-1.7.36.jar
> Error: urls[24] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.11.1/doxia-sink-api-1.11.1.jar
> Error: urls[25] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.11.1/doxia-logging-api-1.11.1.jar
> Error: urls[26] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.11.1/doxia-decoration-model-1.11.1.jar
> Error: urls[27] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-site-renderer/1.11.1/doxia-site-renderer-1.11.1.jar
> Error: urls[28] =
> file:/home/runner/.m2/repository/org/apache/maven/doxia/doxia-core/1.11.1/doxia-core-1.11.1.jar
> Error: urls[29] =
> file:/home/runner/.m2/repository/org/apache/commons/commons-text/1.3/commons-text-1.3.jar
> Error: urls[30] =
[jira] [Updated] (SUREFIRE-2114) Surefire is going to kill self fork JVM. The exit has elapsed 30 seconds after System.exit(0).
[
https://issues.apache.org/jira/browse/SUREFIRE-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamalpreet updated SUREFIRE-2114:
-
Description:
Hi Team,
I'm using maven surefire plugin (Latest Version) to execute tests on two
testing frameworks (e.g, jUnit, jBehave).
Have tried to implement parallelisation by spawning couple of Threads which in
turn create processes to execute surefire jar, taking it from -
{code:java}
ManagementFactory.getRuntimeMXBean().getSystemProperties().get("sun.java.command");{code}
Code snippet to show process creation - *CustomRunner.java*
{code:java}
void run() {
ProcessBuilder processBuilder = new ProcessBuilder(commandArray);
Map environment = processBuilder.environment();
environment.put("platformIndex", String.valueOf(platformIndex));
try {
processBuilder.inheritIO();
Process p = processBuilder.start();
LOGGER.info("Is Alive {} {}", p.isAlive(), LocalTime.now());
int statusCode = p.waitFor();
} catch (Exception e) {
e.printStackTrace();
}
}{code}
*EntryPoint.java*
{code:java}
for (int i = 0; i < 3; i++) {
Thread thread = new Thread(new CustomRunner(commandArray,
String.valueOf(i)));
thread.start();
threadList.add(thread);
}
threadList.forEach(thread -> {
try {
thread.join();
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
});
System.exit(exitcode);{code}
After running two or sometimes three processes in corresponding Threads, the
process execution got stuck on p.waitFor();
Then the process exits after 30 secs and with error message "Surefire is going
to kill self fork JVM. The exit has elapsed 30 seconds after System.exit(0)."
resulting in Build Failure (sometimes it doesn't) though the tests have passed
in their respective processes.
Seems like surefire execution is stuck in some processes. Could you please let
me know what can be the possible reasons for it and how to mitigate this? Tried
extending the ForkedProcessTimeoutInSeconds to few minutes but no luck.
Any help is much appreciated.
was:
Hi Team,
I'm using maven surefire plugin (LTS Version) to execute tests on two testing
frameworks (e.g, jUnit, jBehave).
Have tried to implement parallelisation by spawning couple of Threads which in
turn create processes to execute surefire jar, taking it from -
{code:java}
ManagementFactory.getRuntimeMXBean().getSystemProperties().get("sun.java.command");{code}
Code snippet to show process creation -
{code:java}
ProcessBuilder processBuilder = new ProcessBuilder(commandArray);
Map environment = processBuilder.environment();
environment.put("platformIndex", String.valueOf(platformIndex));
try {
processBuilder.inheritIO();
Process p = processBuilder.start();
LOGGER.info("Is Alive {} {}", p.isAlive(), LocalTime.now());
int statusCode = p.waitFor();
} catch (Exception e) {
e.printStackTrace();
} {code}
And then calling *System.exit.*
*After running two or sometimes three processes in corresponding Threads, the
process execution got stuck on p.waitFor();*
Then the process exits after 30 secs and with error message *"Surefire is going
to kill self fork JVM. The exit has elapsed 30 seconds after System.exit(0)."*
resulting in Build Failure (sometimes it doesn't) though the tests have passed
in their respective processes.
Seems like surefire execution is stuck in some processes. Could you please let
me know what can be the possible reasons for it and how to mitigate this? Tried
extending the ForkedProcessTimeoutInSeconds to few minutes.
Thanks.
> Surefire is going to kill self fork JVM. The exit has elapsed 30 seconds
> after System.exit(0).
> ---
>
> Key: SUREFIRE-2114
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2114
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Reporter: Kamalpreet
>Priority: Critical
> Labels: Issue, process
>
> Hi Team,
> I'm using maven surefire plugin (Latest Version) to execute tests on two
> testing frameworks (e.g, jUnit, jBehave).
> Have tried to implement parallelisation by spawning couple of Threads which
> in turn create processes to execute surefire jar, taking it from -
> {code:java}
> ManagementFactory.getRuntimeMXBean().getSystemProperties().get("sun.java.command");{code}
> Code snippet to show process creation - *CustomRunner.java*
> {code:java}
> void run() {
> ProcessBuilder processBuilder = new ProcessBuilder(commandArray);
> Map environment = processBuilder.environment();
> environment.put("platformIndex", String.valueOf(platformIndex));
> try {
> processBuilder.inheritIO();
> Process p = processBuilder.start();
>
[jira] [Updated] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-417:
Description:
Currently it is not explicitly specified in
[https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which format
the {{description}} field on plugin, mojo and parameter level should have.
It partially contains HTML tags (also from converted inline javadoc taglets)
which is problematic for
[https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html] (which
expects plain text).
On the other hand, the same plugin descriptor is currently leveraged for goal
{{report}} which should include all those HTML details from the source comment.
Therefore both goals need to extract metadata from source files differently and
{{report}} can no longer rely on the previously generated plugin descriptor
file.
In addition even the plain text descriptor should contain as many details as
possible, i.e. it should be converted javadoc taglets -> html -> plain text to
no loose any detail.
Currently the plugin descriptor is written with
{{{}GeneratorUtils.toText(){}}}at
[https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
which has the following flaws
# Still emits {{https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
## one with plain text and additional attributes for {{helpmojo}}
## another temporary one to be used from {{report }}containing HTML values
# goal {{helpmojo}} evaluates the deserialized descriptor from 2 at execution
time of the resulting "help" mojo
# goal {{report}} evaluates the deserialized enhanced descriptor from 3.
was:
Currently it is not explicitly specified in
[https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which format
the {{description}} field on plugin, mojo and parameter level should have.
It partially contains HTML tags (also from converted inline javadoc taglets)
which is problematic for
[https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html] (which
expects plain text).
On the other hand, the same plugin descriptor is currently leveraged for goal
{{report }}which should include all those HTML details from the source comment.
Therefore both goals need to extract metadata from source files differently and
{{report{{ can no longer rely on the previously generated plugin descriptor
file.
In addition even the plain text descriptor should contain as many details as
possible, i.e. it should be converted javadoc taglets -> html -> plain text to
no loose any detail.
Currently the plugin descriptor is written with
{{{}GeneratorUtils.toText(){}}}at
[https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
which has the following flaws
# Still emits {{https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] and
## another temporary one to be used from both {{report}} and {{helpmojo}}
(replacing the currently generated plugin-help.xml) contains HTML and some
additional attributes (necessary for helpmojo). For that
{{PluginDescriptorGenerator}} must be enhanced to do another html -> plaintext
conversion.
# goal {{helpmojo}} evaluates the deserialized enhanced descriptor
# goal {{report}} evaluates the deserialized enhanced descriptor
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be
[jira] [Updated] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-417:
Description:
Currently it is not explicitly specified in
[https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which format
the {{description}} field on plugin, mojo and parameter level should have.
It partially contains HTML tags (also from converted inline javadoc taglets)
which is problematic for
[https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html] (which
expects plain text).
On the other hand, the same plugin descriptor is currently leveraged for goal
{{report}} which should include all those HTML details from the source comment.
Therefore both goals need to extract metadata from source files differently and
{{report}} can no longer rely on the previously generated plugin descriptor
file.
In addition even the plain text descriptor should contain as many details as
possible, i.e. it should be converted javadoc taglets -> html -> plain text to
no loose any detail.
Currently the plugin descriptor is written with
{{{}GeneratorUtils.toText(){}}}at
[https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
which has the following flaws
# Still emits {{https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
## one with plain text and additional attributes for {{helpmojo}}
## another temporary one to be used from {{report}} containing HTML values
# goal {{helpmojo}} evaluates the deserialized descriptor from 2 at execution
time of the resulting "help" mojo
# goal {{report}} evaluates the deserialized enhanced descriptor from 3.
was:
Currently it is not explicitly specified in
[https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which format
the {{description}} field on plugin, mojo and parameter level should have.
It partially contains HTML tags (also from converted inline javadoc taglets)
which is problematic for
[https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html] (which
expects plain text).
On the other hand, the same plugin descriptor is currently leveraged for goal
{{report}} which should include all those HTML details from the source comment.
Therefore both goals need to extract metadata from source files differently and
{{report}} can no longer rely on the previously generated plugin descriptor
file.
In addition even the plain text descriptor should contain as many details as
possible, i.e. it should be converted javadoc taglets -> html -> plain text to
no loose any detail.
Currently the plugin descriptor is written with
{{{}GeneratorUtils.toText(){}}}at
[https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
which has the following flaws
# Still emits {{https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html]
## one with plain text and additional attributes for {{helpmojo}}
## another temporary one to be used from {{report }}containing HTML values
# goal {{helpmojo}} evaluates the deserialized descriptor from 2 at execution
time of the resulting "help" mojo
# goal {{report}} evaluates the deserialized enhanced descriptor from 3.
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report}} which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report}} can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin
[jira] [Updated] (MPLUGIN-417) report and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-417:
Summary: report and descriptor goal need to evaluate Javadoc comments
differently (was: report/helpmojo and descriptor goal need to evaluate Javadoc
comments differently)
> report and descriptor goal need to evaluate Javadoc comments differently
>
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report }}which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report{{ can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates two different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] and
> ## another temporary one to be used from both {{report}} and {{helpmojo}}
> (replacing the currently generated plugin-help.xml) contains HTML and some
> additional attributes (necessary for helpmojo). For that
> {{PluginDescriptorGenerator}} must be enhanced to do another html ->
> plaintext conversion.
> # goal {{helpmojo}} evaluates the deserialized enhanced descriptor
> # goal {{report}} evaluates the deserialized enhanced descriptor
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] slachiewicz merged pull request #168: Bump mrm-maven-plugin from 1.3.0 to 1.4.1
slachiewicz merged PR #168: URL: https://github.com/apache/maven-enforcer/pull/168 -- 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] slachiewicz merged pull request #164: Bump maven-plugin-testing-harness from 3.1.0 to 3.3.0
slachiewicz merged PR #164: URL: https://github.com/apache/maven-enforcer/pull/164 -- 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] slachiewicz merged pull request #181: Bump mockito.version from 4.6.1 to 4.7.0
slachiewicz merged PR #181: URL: https://github.com/apache/maven-enforcer/pull/181 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-599) Upgrade parent to 31
[ https://issues.apache.org/jira/browse/MDEP-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17585248#comment-17585248 ] Hudson commented on MDEP-599: - Build succeeded in Jenkins: Maven » Maven TLP » maven-dependency-plugin » master #34 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dependency-plugin/job/master/34/ > Upgrade parent to 31 > > > Key: MDEP-599 > URL: https://issues.apache.org/jira/browse/MDEP-599 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-dependency-plugin] slawekjaranowski merged pull request #214: Bump junit from 4.12 to 4.13.1 in /src/it/projects/mdep-599-analyze-java9
slawekjaranowski merged PR #214: URL: https://github.com/apache/maven-dependency-plugin/pull/214 -- 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-dependency-plugin] slawekjaranowski merged pull request #212: Bump jsoup from 1.13.1 to 1.14.2 in /src/it/projects/analyze-testDependencyWithNonTestScope
slawekjaranowski merged PR #212: URL: https://github.com/apache/maven-dependency-plugin/pull/212 -- 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-dependency-plugin] slawekjaranowski commented on pull request #236: Bump jsoup from 1.15.2 to 1.15.3
slawekjaranowski commented on PR #236: URL: https://github.com/apache/maven-dependency-plugin/pull/236#issuecomment-1228163533 @dependabot recreate -- 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-dependency-plugin] slawekjaranowski merged pull request #213: Bump junit from 4.12 to 4.13.1 in /src/it/projects/analyze-testDependencyWithNonTestScope
slawekjaranowski merged PR #213: URL: https://github.com/apache/maven-dependency-plugin/pull/213 -- 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] [Assigned] (MPLUGIN-417) report/helpmojo and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus reassigned MPLUGIN-417:
---
Assignee: Konrad Windszus
> report/helpmojo and descriptor goal need to evaluate Javadoc comments
> differently
> -
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report }}which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report{{ can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> # Still emits {{ # Does not resolve all javadoc tags
> # Does never emit a proper link for link javadoc taglets
>
> The proposal is that
> # goal {{descriptor}} generates two different descriptor serializations
> (based on the same in-memory HTML descriptor):
> ## one with plain text according to
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] and
> ## another temporary one to be used from both {{report}} and {{helpmojo}}
> (replacing the currently generated plugin-help.xml) contains HTML and some
> additional attributes (necessary for helpmojo). For that
> {{PluginDescriptorGenerator}} must be enhanced to do another html ->
> plaintext conversion.
> # goal {{helpmojo}} evaluates the deserialized enhanced descriptor
> # goal {{report}} evaluates the deserialized enhanced descriptor
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPLUGIN-417) report/helpmojo and descriptor goal need to evaluate Javadoc comments differently
[
https://issues.apache.org/jira/browse/MPLUGIN-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MPLUGIN-417:
Description:
Currently it is not explicitly specified in
[https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which format
the {{description}} field on plugin, mojo and parameter level should have.
It partially contains HTML tags (also from converted inline javadoc taglets)
which is problematic for
[https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html] (which
expects plain text).
On the other hand, the same plugin descriptor is currently leveraged for goal
{{report }}which should include all those HTML details from the source comment.
Therefore both goals need to extract metadata from source files differently and
{{report{{ can no longer rely on the previously generated plugin descriptor
file.
In addition even the plain text descriptor should contain as many details as
possible, i.e. it should be converted javadoc taglets -> html -> plain text to
no loose any detail.
Currently the plugin descriptor is written with
{{{}GeneratorUtils.toText(){}}}at
[https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
which has the following flaws
# Still emits {{https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] and
## another temporary one to be used from both {{report}} and {{helpmojo}}
(replacing the currently generated plugin-help.xml) contains HTML and some
additional attributes (necessary for helpmojo). For that
{{PluginDescriptorGenerator}} must be enhanced to do another html -> plaintext
conversion.
# goal {{helpmojo}} evaluates the deserialized enhanced descriptor
# goal {{report}} evaluates the deserialized enhanced descriptor
was:
Currently it is not explicitly specified in
[https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which format
the {{description}} field on plugin, mojo and parameter level should have.
It partially contains HTML tags (also from converted inline javadoc taglets)
which is problematic for
[https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html] (which
expects plain text).
On the other hand, the same plugin descriptor is currently leveraged for goal
{{report}} which should include all those HTML details from the source comment.
Therefore both goals need to extract metadata from source files differently and
{{report{{ can no longer rely on the previously generated plugin descriptor
file.
In addition even the plain text descriptor should contain as many details as
possible, i.e. it should be converted javadoc taglets -> html -> plain text to
no loose any detail.
Currently the plugin descriptor is written with
{{{}GeneratorUtils.toText(){}}}at
[https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
which has the following flaws
# Still emits {{ report/helpmojo and descriptor goal need to evaluate Javadoc comments
> differently
> -
>
> Key: MPLUGIN-417
> URL: https://issues.apache.org/jira/browse/MPLUGIN-417
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently it is not explicitly specified in
> [https://maven.apache.org/ref/3.8.4/maven-plugin-api/plugin.html] which
> format the {{description}} field on plugin, mojo and parameter level should
> have.
> It partially contains HTML tags (also from converted inline javadoc taglets)
> which is problematic for
> [https://maven.apache.org/plugins/maven-help-plugin/describe-mojo.html]
> (which expects plain text).
> On the other hand, the same plugin descriptor is currently leveraged for goal
> {{report }}which should include all those HTML details from the source
> comment.
> Therefore both goals need to extract metadata from source files differently
> and {{report{{ can no longer rely on the previously generated plugin
> descriptor file.
> In addition even the plain text descriptor should contain as many details as
> possible, i.e. it should be converted javadoc taglets -> html -> plain text
> to no loose any detail.
> Currently the plugin descriptor is written with
> {{{}GeneratorUtils.toText(){}}}at
> [https://github.com/apache/maven-plugin-tools/blob/706b1d0b6730d028350f18d8459eee8b123e2f67/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java#L186]
> which has the following flaws
> #
