[jira] [Reopened] (MCOMPILER-414) parameters flag does not apply to testCompile goal
[
https://issues.apache.org/jira/browse/MCOMPILER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reopened MCOMPILER-414:
--
> parameters flag does not apply to testCompile goal
> --
>
> Key: MCOMPILER-414
> URL: https://issues.apache.org/jira/browse/MCOMPILER-414
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Alberto Minetti
>Assignee: Robert Scholte
>Priority: Minor
>
> Seems that the true flag just applies properly to
> the compile goal, but not to the testCompile goal.
>
> *Workaround*: using the compilerArgs works for both goals compile and
> testCompile
> {{}}
> {{ -parameters}}
> {{}}
>
> Here on github you can find a working software with the current issue; the
> tests in master branch fail because of the usage of the flag,
> instead in the branch using-compilerArgs the build is succesful.
> [https://github.com/albertominetti/jackson-parameters/pull/1/commits/ad0fa7605fe378a4b900b7c911f4e7019533092f]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MCOMPILER-414) parameters flag does not apply to testCompile goal
[
https://issues.apache.org/jira/browse/MCOMPILER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-414.
Resolution: Duplicate
> parameters flag does not apply to testCompile goal
> --
>
> Key: MCOMPILER-414
> URL: https://issues.apache.org/jira/browse/MCOMPILER-414
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Alberto Minetti
>Assignee: Robert Scholte
>Priority: Minor
>
> Seems that the true flag just applies properly to
> the compile goal, but not to the testCompile goal.
>
> *Workaround*: using the compilerArgs works for both goals compile and
> testCompile
> {{}}
> {{ -parameters}}
> {{}}
>
> Here on github you can find a working software with the current issue; the
> tests in master branch fail because of the usage of the flag,
> instead in the branch using-compilerArgs the build is succesful.
> [https://github.com/albertominetti/jackson-parameters/pull/1/commits/ad0fa7605fe378a4b900b7c911f4e7019533092f]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MCOMPILER-414) parameters flag does not apply to testCompile goal
[
https://issues.apache.org/jira/browse/MCOMPILER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MCOMPILER-414.
Assignee: Robert Scholte
Resolution: Fixed
> parameters flag does not apply to testCompile goal
> --
>
> Key: MCOMPILER-414
> URL: https://issues.apache.org/jira/browse/MCOMPILER-414
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Alberto Minetti
>Assignee: Robert Scholte
>Priority: Minor
>
> Seems that the true flag just applies properly to
> the compile goal, but not to the testCompile goal.
>
> *Workaround*: using the compilerArgs works for both goals compile and
> testCompile
> {{}}
> {{ -parameters}}
> {{}}
>
> Here on github you can find a working software with the current issue; the
> tests in master branch fail because of the usage of the flag,
> instead in the branch using-compilerArgs the build is succesful.
> [https://github.com/albertominetti/jackson-parameters/pull/1/commits/ad0fa7605fe378a4b900b7c911f4e7019533092f]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MPLUGIN-389) Update level to Java8
Tamás Cservenák created MPLUGIN-389: --- Summary: Update level to Java8 Key: MPLUGIN-389 URL: https://issues.apache.org/jira/browse/MPLUGIN-389 Project: Maven Plugin Tools Issue Type: Task Components: Plugin Plugin Reporter: Tamás Cservenák Fix For: 3.7.0 Update plugin Java level to Java 8. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPLUGIN-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482944#comment-17482944
]
ASF GitHub Bot commented on MPLUGIN-388:
slawekjaranowski commented on a change in pull request #66:
URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r793338571
##
File path: maven-plugin-plugin/pom.xml
##
@@ -296,7 +276,7 @@
org.apache.maven.plugins
maven-plugin-plugin
-3.6.0
Review comment:
is it not valid?
will work during 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
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] slawekjaranowski commented on a change in pull request #66: [MPLUGIN-388] Make reporting dependency optional
slawekjaranowski commented on a change in pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r793338571 ## File path: maven-plugin-plugin/pom.xml ## @@ -296,7 +276,7 @@ org.apache.maven.plugins maven-plugin-plugin -3.6.0 Review comment: is it not valid? will work during 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] (MPLUGIN-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482938#comment-17482938
]
ASF GitHub Bot commented on MPLUGIN-388:
cstamas edited a comment on pull request #66:
URL:
https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022934808
@slawekjaranowski fixed them (moved property where used, renamed them to be
camelCase).
--
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
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MPLUGIN-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482940#comment-17482940
]
ASF GitHub Bot commented on MPLUGIN-388:
cstamas edited a comment on pull request #66:
URL:
https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022934808
@slawekjaranowski fixed them (moved property where used, renamed them to be
camelCase).
Using depMgt in parent for one single (atypical, only plugin) module is
overkill IMO.
--
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
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-reporting-exec] slawekjaranowski merged pull request #10: Fix build forked-lifecycle IT on macOS
slawekjaranowski merged pull request #10: URL: https://github.com/apache/maven-reporting-exec/pull/10 -- 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] cstamas edited a comment on pull request #66: [MPLUGIN-388] Make reporting dependency optional
cstamas edited a comment on pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022934808 @slawekjaranowski fixed them (moved property where used, renamed them to be camelCase). Using depMgt in parent for one single (atypical, only plugin) module is overkill IMO. -- 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] cstamas edited a comment on pull request #66: [MPLUGIN-388] Make reporting dependency optional
cstamas edited a comment on pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022934808 @slawekjaranowski fixed them (moved property where used, renamed them to be camelCase). -- 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-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482937#comment-17482937
]
ASF GitHub Bot commented on MPLUGIN-388:
cstamas commented on pull request #66:
URL:
https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022934808
@slawekjaranowski fixed then (moved property where used, renamed them to be
camelCase).
--
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
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] cstamas commented on pull request #66: [MPLUGIN-388] Make reporting dependency optional
cstamas commented on pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022934808 @slawekjaranowski fixed then (moved property where used, renamed them to be camelCase). -- 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] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482931#comment-17482931
]
Herve Boutemy edited comment on MSHARED-1032 at 1/27/22, 7:40 AM:
--
we'll define everything step by step:
# it will be for the next version of reporting-api
[https://maven.apache.org/shared/maven-reporting-api/] (unrelated to Maven 4)
# we'll see if finally the next version of maven-reporting-api is 3.1 or 4.0
# we'll se also which exception to add: reading the javadoc, it seems that
MavenReportException looks like a better choice
[https://maven.apache.org/shared/maven-reporting-api/apidocs/index.html] ,
because reporting-api is not tied to Mojo at all (that's the role of
reporting-impl to fill the gap:
[https://maven.apache.org/shared/maven-reporting-impl/] )
on major and minor question, IMHO the important aspect is binary compatibility:
# will a new report using this modified API with an Exception still be usable
from maven-site-plugin 3.x?
# will an old report using unmodified 3.0 API without exception still be
usable from maven-site-plugin that support the new API signature?
IMHO, that will impact our choice of version both for maven-reporting-api AND
maven-site-plugin = the real user-visible impact
was (Author: hboutemy):
we'll define everything step by step:
# it will be for the next version of reporting-api
[https://maven.apache.org/shared/maven-reporting-api/] (unrelated to Maven 4)
# we'll see if finally the next version of maven-reporting-api is 3.1 or 4.0
# we'll se also which exception to add: reading the javadoc, it seems that
MavenReportException looks like a better choice
[https://maven.apache.org/shared/maven-reporting-api/apidocs/index.html] ,
because reporting-api is not tied to Mojo at all (that's the role of
reporting-impl to fill the gap:
[https://maven.apache.org/shared/maven-reporting-impl/] )
on major and minor question, IMHO the important aspect is binary compatibility:
# will a new report using this modified API with an Exception still be usable
from maven-site-plugin 3.x?
# will an old report using unmodified 3.0 API without exception still be
usable from maven-site-plugin that support the new API signature?
IMHO, that will impact our choice of version both for maven-reporting-api AND
maven-site-plugin
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: maven-reporting-api-3.1.0
>
>
> Hi everyone,
> the [`{{AbstractReportMojo}}` in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [`{{canGenerateReport()}}` from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482931#comment-17482931
]
Herve Boutemy commented on MSHARED-1032:
we'll define everything step by step:
# it will be for the next version of reporting-api
[https://maven.apache.org/shared/maven-reporting-api/] (unrelated to Maven 4)
# we'll see if finally the next version of maven-reporting-api is 3.1 or 4.0
# we'll se also which exception to add: reading the javadoc, it seems that
MavenReportException looks like a better choice
[https://maven.apache.org/shared/maven-reporting-api/apidocs/index.html] ,
because reporting-api is not tied to Mojo at all (that's the role of
reporting-impl to fill the gap:
[https://maven.apache.org/shared/maven-reporting-impl/] )
on major and minor question, IMHO the important aspect is binary compatibility:
# will a new report using this modified API with an Exception still be usable
from maven-site-plugin 3.x?
# will an old report using unmodified 3.0 API without exception still be
usable from maven-site-plugin that support the new API signature?
IMHO, that will impact our choice of version both for maven-reporting-api AND
maven-site-plugin
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: maven-reporting-api-3.1.0
>
>
> Hi everyone,
> the [`{{AbstractReportMojo}}` in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [`{{canGenerateReport()}}` from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-sources] gnodet merged pull request #1: Update submodules
gnodet merged pull request #1: URL: https://github.com/apache/maven-sources/pull/1 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482928#comment-17482928
]
Michael Osipov commented on MSHARED-1032:
-
[~hboutemy], really in a minor version?
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: maven-reporting-api-3.1.0
>
>
> Hi everyone,
> the [`{{AbstractReportMojo}}` in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [`{{canGenerateReport()}}` from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482927#comment-17482927
]
Herve Boutemy commented on MSHARED-1032:
I added links to javadoc for reporting-impl and reporting-api, to better
describe where the API update questions really happen :)
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: maven-reporting-api-3.1.0
>
>
> Hi everyone,
> the [`{{AbstractReportMojo}}` in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [`{{canGenerateReport()}}` from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-1032:
---
Description:
Hi everyone,
the [`{{AbstractReportMojo}}` in
reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
implements a method [`{{canGenerateReport()}}` from
reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}} or
{{{}MavenReportEx{}}}, which is most unfortunate.
It is being used twice:
Once in {{execute() throws MojoExEx}}
and in
{{generate() throws MavenReportEx}} (and is called by execute()).
This way, there is no way for reporting plugins to scan for files, because
{{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot be
wrapped. However, the {{IOException}} from that method is useless anyway,
because it is never declared in any methods it calls.
Therefore please consider:
* Declaring any Exception on `{{{}canGenerateReports(){}}}`
* Removing the declared {{IOException}} in PlexusUtils ([PR
exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
Maven-Utils (issue: tbd).
Thanks!
was:
Hi everyone,
the [`{{AbstractReportMojo}}` in
reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
implements a method[ `{{canGenerateReport()}}` from
reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}} or
{{{}MavenReportEx{}}}, which is most unfortunate.
It is being used twice:
Once in {{execute() throws MojoExEx}}
and in
{{generate() throws MavenReportEx}} (and is called by execute()).
This way, there is no way for reporting plugins to scan for files, because
{{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot be
wrapped. However, the {{IOException}} from that method is useless anyway,
because it is never declared in any methods it calls.
Therefore please consider:
* Declaring any Exception on `{{{}canGenerateReports(){}}}`
* Removing the declared {{IOException}} in PlexusUtils ([PR
exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
Maven-Utils (issue: tbd).
Thanks!
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: maven-reporting-api-3.1.0
>
>
> Hi everyone,
> the [`{{AbstractReportMojo}}` in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method [`{{canGenerateReport()}}` from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-1032:
---
Description:
Hi everyone,
the [`{{AbstractReportMojo}}` in
reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
implements a method[ `{{canGenerateReport()}}` from
reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}} or
{{{}MavenReportEx{}}}, which is most unfortunate.
It is being used twice:
Once in {{execute() throws MojoExEx}}
and in
{{generate() throws MavenReportEx}} (and is called by execute()).
This way, there is no way for reporting plugins to scan for files, because
{{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot be
wrapped. However, the {{IOException}} from that method is useless anyway,
because it is never declared in any methods it calls.
Therefore please consider:
* Declaring any Exception on `{{{}canGenerateReports(){}}}`
* Removing the declared {{IOException}} in PlexusUtils ([PR
exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
Maven-Utils (issue: tbd).
Thanks!
was:
Hi everyone,
the `{{{}AbstractReportMojo{}}}` declares a method
`{{{}canGenerateReport(){}}}`.
However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}} or
{{{}MavenReportEx{}}}, which is most unfortunate.
It is being used twice:
Once in {{execute() throws MojoExEx}}
and in
{{generate() throws MavenReportEx}} (and is called by execute()).
This way, there is no way for reporting plugins to scan for files, because
{{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot be
wrapped. However, the {{IOException}} from that method is useless anyway,
because it is never declared in any methods it calls.
Therefore please consider:
* Declaring any Exception on `{{{}canGenerateReports(){}}}`
* Removing the declared {{IOException}} in PlexusUtils ([PR
exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
Maven-Utils (issue: tbd).
Thanks!
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: maven-reporting-api-3.1.0
>
>
> Hi everyone,
> the [`{{AbstractReportMojo}}` in
> reporting-impl|https://maven.apache.org/shared/maven-reporting-impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html]
> implements a method[ `{{canGenerateReport()}}` from
> reporting-api|https://maven.apache.org/shared/maven-reporting-api/apidocs/org/apache/maven/reporting/MavenReport.html].
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-1032:
---
Fix Version/s: maven-reporting-api-3.1.0
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
> Fix For: maven-reporting-api-3.1.0
>
>
> Hi everyone,
> the `{{{}AbstractReportMojo{}}}` declares a method
> `{{{}canGenerateReport(){}}}`.
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Moved] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy moved MNG-7393 to MSHARED-1032:
-
Key: MSHARED-1032 (was: MNG-7393)
Project: Maven Shared Components (was: Maven)
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> the `{{{}AbstractReportMojo{}}}` declares a method
> `{{{}canGenerateReport(){}}}`.
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-1032:
---
Affects Version/s: maven-reporting-api-3.0
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Affects Versions: maven-reporting-api-3.0
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> the `{{{}AbstractReportMojo{}}}` declares a method
> `{{{}canGenerateReport(){}}}`.
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MSHARED-1032) API change: let canGenerateReport() throw an Exception
[
https://issues.apache.org/jira/browse/MSHARED-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MSHARED-1032:
---
Component/s: maven-reporting-api
> API change: let canGenerateReport() throw an Exception
> --
>
> Key: MSHARED-1032
> URL: https://issues.apache.org/jira/browse/MSHARED-1032
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-api
>Reporter: Benjamin Marwell
>Priority: Major
>
> Hi everyone,
> the `{{{}AbstractReportMojo{}}}` declares a method
> `{{{}canGenerateReport(){}}}`.
> However, it is unable to throw any exceptions. Not even {{MojoExecutionEx}}
> or {{{}MavenReportEx{}}}, which is most unfortunate.
> It is being used twice:
> Once in {{execute() throws MojoExEx}}
> and in
> {{generate() throws MavenReportEx}} (and is called by execute()).
> This way, there is no way for reporting plugins to scan for files, because
> {{FileUtils::getFiles}} DOES throw a {{{}IOException{}}}, which then cannot
> be wrapped. However, the {{IOException}} from that method is useless anyway,
> because it is never declared in any methods it calls.
> Therefore please consider:
> * Declaring any Exception on `{{{}canGenerateReports(){}}}`
> * Removing the declared {{IOException}} in PlexusUtils ([PR
> exists|https://github.com/codehaus-plexus/plexus-utils/issues/180]) and
> Maven-Utils (issue: tbd).
> Thanks!
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-mvnd] robberphex opened a new issue #595: Support graceful stop
robberphex opened a new issue #595: URL: https://github.com/apache/maven-mvnd/issues/595 Currently, `mvnd --stop` will stop all background tasks. We should, like `ssh -O` option's behavior: * use `mvnd --stop` as "request the master to stop accepting further request" * use `mvnd --exit` as "request the master and tasks to exit" -- 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-invoker-plugin] dependabot[bot] opened a new pull request #93: Bump slf4j-simple from 1.7.33 to 1.7.35
dependabot[bot] opened a new pull request #93: URL: https://github.com/apache/maven-invoker-plugin/pull/93 Bumps [slf4j-simple](https://github.com/qos-ch/slf4j) from 1.7.33 to 1.7.35. Commits https://github.com/qos-ch/slf4j/commit/02860b67ef7ff39fa9c7d98fd00da2ee913faeda;>02860b6 prepare relase 1.7.35 https://github.com/qos-ch/slf4j/commit/a622f5186a57188dab7f71651245eb91c6ac263b;>a622f51 fix maven deploy issues https://github.com/qos-ch/slf4j/commit/26068bd4bf93fcbd00185ad986dc43b79aceeb4a;>26068bd slf4j no longer references log4j https://github.com/qos-ch/slf4j/commit/0a21ee1ac1daa2d8e077bec68815421dd7a7a54a;>0a21ee1 replace references to slf4j-log4j12 https://github.com/qos-ch/slf4j/commit/51b6d20b71de75f69ee68167afbf4073c1be7c31;>51b6d20 prepare release 1.7.34 https://github.com/qos-ch/slf4j/commit/d22943faedd5da8d0321cf60437796fb53618481;>d22943f relocate slf4j-log4j12 as slf4j-reload4j https://github.com/qos-ch/slf4j/commit/19e36ffdca0218797cd23048b6547865e30e1d3a;>19e36ff make VersionUtil more robust https://github.com/qos-ch/slf4j/commit/d32d0535f7274a679c47d3354411476a86f5971a;>d32d053 fix SLF4J-535 https://github.com/qos-ch/slf4j/commit/2b657bf5dc575f32791648fd95260e33aa07687c;>2b657bf start work on 1.7.33-SNAPSHOT See full diff in https://github.com/qos-ch/slf4j/compare/v_1.7.33...v_1.7.35;>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-indexer] dependabot[bot] opened a new pull request #163: Bump slf4j-simple from 1.7.32 to 1.7.35
dependabot[bot] opened a new pull request #163: URL: https://github.com/apache/maven-indexer/pull/163 Bumps [slf4j-simple](https://github.com/qos-ch/slf4j) from 1.7.32 to 1.7.35. Commits https://github.com/qos-ch/slf4j/commit/02860b67ef7ff39fa9c7d98fd00da2ee913faeda;>02860b6 prepare relase 1.7.35 https://github.com/qos-ch/slf4j/commit/a622f5186a57188dab7f71651245eb91c6ac263b;>a622f51 fix maven deploy issues https://github.com/qos-ch/slf4j/commit/26068bd4bf93fcbd00185ad986dc43b79aceeb4a;>26068bd slf4j no longer references log4j https://github.com/qos-ch/slf4j/commit/0a21ee1ac1daa2d8e077bec68815421dd7a7a54a;>0a21ee1 replace references to slf4j-log4j12 https://github.com/qos-ch/slf4j/commit/51b6d20b71de75f69ee68167afbf4073c1be7c31;>51b6d20 prepare release 1.7.34 https://github.com/qos-ch/slf4j/commit/d22943faedd5da8d0321cf60437796fb53618481;>d22943f relocate slf4j-log4j12 as slf4j-reload4j https://github.com/qos-ch/slf4j/commit/19e36ffdca0218797cd23048b6547865e30e1d3a;>19e36ff make VersionUtil more robust https://github.com/qos-ch/slf4j/commit/d32d0535f7274a679c47d3354411476a86f5971a;>d32d053 fix SLF4J-535 https://github.com/qos-ch/slf4j/commit/2b657bf5dc575f32791648fd95260e33aa07687c;>2b657bf start work on 1.7.33-SNAPSHOT https://github.com/qos-ch/slf4j/commit/2758a974264ab65df3af1d473eb9423ca978c14a;>2758a97 prepare release 1.7.33 Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.32...v_1.7.35;>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-javadoc-plugin] dependabot[bot] opened a new pull request #121: Bump mrm-maven-plugin from 1.2.0 to 1.3.0
dependabot[bot] opened a new pull request #121: URL: https://github.com/apache/maven-javadoc-plugin/pull/121 Bumps [mrm-maven-plugin](https://github.com/mojohaus/mrm) from 1.2.0 to 1.3.0. Release notes Sourced from https://github.com/mojohaus/mrm/releases;>mrm-maven-plugin's releases. 1.3.0 making timestamp deserialization consistent (https://github-redirect.dependabot.com/mojohaus/mrm/issues/18;>#18) https://github.com/or-shachar;>@or-shachar New features and improvements Upgrade to Jetty 9.4.43.v20210629 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/35;>#35) https://github.com/olamy;>@olamy java 1.8 mandatory amd some codebase update (https://github-redirect.dependabot.com/mojohaus/mrm/issues/33;>#33) https://github.com/olamy;>@olamy switch to github actions, add dependabot and use release drafter (https://github-redirect.dependabot.com/mojohaus/mrm/issues/26;>#26) https://github.com/olamy;>@olamy Dependency updates Bump mockito-core from 3.12.4 to 4.1.0 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/62;>#62) https://github.com/dependabot;>@dependabot Bump mojo-parent from 63 to 65 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/63;>#63) https://github.com/dependabot;>@dependabot Bump plexus-archiver from 4.2.5 to 4.2.6 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/60;>#60) https://github.com/dependabot;>@dependabot Bump actions/checkout from 2.3.5 to 2.4.0 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/59;>#59) https://github.com/dependabot;>@dependabot Bump actions/checkout from 2.3.4 to 2.3.5 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/58;>#58) https://github.com/dependabot;>@dependabot Bump actions/setup-java from 2.3.0 to 2.3.1 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/54;>#54) https://github.com/dependabot;>@dependabot Bump maven-war-plugin from 3.3.1 to 3.3.2 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/53;>#53) https://github.com/dependabot;>@dependabot Bump plexus-utils from 3.4.0 to 3.4.1 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/52;>#52) https://github.com/dependabot;>@dependabot Bump mockito-core from 3.12.3 to 3.12.4 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/51;>#51) https://github.com/dependabot;>@dependabot Bump mockito-core from 3.12.1 to 3.12.3 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/50;>#50) https://github.com/dependabot;>@dependabot Bump actions/setup-java from 2.2.0 to 2.3.0 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/49;>#49) https://github.com/dependabot;>@dependabot Bump mockito-core from 3.11.2 to 3.12.1 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/48;>#48) https://github.com/dependabot;>@dependabot Bump commons-io from 2.7 to 2.11.0 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/46;>#46) https://github.com/dependabot;>@dependabot Bump mockito-core from 1.9.0 to 3.11.2 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/27;>#27) https://github.com/dependabot;>@dependabot Bump plexus-archiver from 3.4 to 4.2.5 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/36;>#36) https://github.com/dependabot;>@dependabot Bump junit from 4.13.1 to 4.13.2 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/42;>#42) https://github.com/dependabot;>@dependabot Bump maven-enforcer-plugin from 3.0.0-M1 to 3.0.0 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/41;>#41) https://github.com/dependabot;>@dependabot Bump maven-common-artifact-filters from 1.4 to 3.2.0 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/37;>#37) https://github.com/dependabot;>@dependabot Bump maven-war-plugin from 3.2.1 to 3.3.1 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/38;>#38) https://github.com/dependabot;>@dependabot Bump commons-io from 2.0.1 to 2.11.0 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/32;>#32) https://github.com/dependabot;>@dependabot Bump actions/setup-java from 2.1.0 to 2.2.0 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/31;>#31) https://github.com/dependabot;>@dependabot Bump jetty-maven-plugin from 8.0.1.v20110908 to 8.1.16.v20140903 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/29;>#29) https://github.com/dependabot;>@dependabot Bump mojo-parent from 50 to 63 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/30;>#30) https://github.com/dependabot;>@dependabot Bump junit from 4.10 to 4.13.1 (https://github-redirect.dependabot.com/mojohaus/mrm/issues/24;>#24) https://github.com/dependabot;>@dependabot Commits https://github.com/mojohaus/mrm/commit/1a34933383abe618c61914614e1febbae3942063;>1a34933 [maven-release-plugin] prepare release mrm-1.3.0
[jira] [Commented] (SUREFIRE-1973) Tests fail in 3.0.0-M5 but Pass in 3.0.0-M4
[ https://issues.apache.org/jira/browse/SUREFIRE-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482835#comment-17482835 ] Eric Kolotyluk commented on SUREFIRE-1973: -- JUnit 5... I have been really busy lately, starting a new job 2022-01-04... will see what I can do... > Tests fail in 3.0.0-M5 but Pass in 3.0.0-M4 > --- > > Key: SUREFIRE-1973 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1973 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 3.0.0-M5 > Environment: https://github.com/kolotyluk/loom-lab > (laboratory/LagTests) > Windows 10, Java 17, IntelliJ IDEA 2021.3 > Build #IU-213.5744.223, built on November 27, 2021 > Runtime version: 11.0.13+7-b1751.19 amd64 > VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. >Reporter: Eric Kolotyluk >Priority: Major > Fix For: waiting-for-feedback > > > I have some unit tests that are failing when I run `mvn test` but pass when I > run them from the IntelliJ IDEA User Interface. > The same tests pass when I use `2.22.2` of the Surefire Plugin with `mvn > test`. > I am not sure what other information is helpful, but you can clone the > project from GitHub to see the issue in action. I would be happy to provide > more specific information on request. > _It is particularly odd that the test code actually behaves differently when > running with Surefire 3.0.0-M5, which I would not have thought possible._ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #348: Enabling Surefire to run test classes and test methods in any order specified by a new runOrder
Tibor17 edited a comment on pull request #348: URL: https://github.com/apache/maven-surefire/pull/348#issuecomment-1022747001 Maybe a hint, try to run a basic project in debug mode `mvn -X test -Dtests=xxx,yyy` and go to the folder `target/surefire`. You should see two properties files and one jar file. Open one property file and you should see CSV of what you have used in `-Dtest=`. This is your data. Iterate over this parse each substring, create an instance of `TestListResolver` and pickup the class/method pairs. Order them and use them as necesary in the run order calculator within the provider(s), see the `ProviderParameters#getTestRequest()`. Regarding the sanity check, go to the `AbstractSurefireMojo` class and see the parameters checkers in the `execute()` method. There are more like this. I think you should write a check that the new enum requires the test list but do not use `getTests()` directly. We are merging several config parameters together and we will change this part of code in #440 so my advice is to focus on this a bit later or check the #440 . -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #348: Enabling Surefire to run test classes and test methods in any order specified by a new runOrder
Tibor17 commented on pull request #348: URL: https://github.com/apache/maven-surefire/pull/348#issuecomment-1022747001 Maybe a hint, try to run a basic project in debug mode `mvn -X test -Dtests=xxx,yyy` and go to the folder `target/surefire`. You should see two properties files and one jar file. Open one property file and you should see CSV of what you have used in `-Dtest=`. This is your data. Iterate over this parse each substring, create an instance of `TestListResolver` and pickup the class/method pairs. Order them and use them as necesary in the run order calculator within the provider(s). Regarding the sanity check, go to the `AbstractSurefireMojo` class and see the parameters checkers in the `execute()` method. There are more like this. I think you should write a check that the new enum requires the test list but do not use `getTests()` directly. We are merging several config parameters together and we will change this part of code in #440 so my advice is to focus on this a bit later or check the #440 . -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (SUREFIRE-1989) Update maven-common-artifact-filters to Version 3.1.1
[ https://issues.apache.org/jira/browse/SUREFIRE-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1989. -- Assignee: Tibor Digana Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=cdb7c9cb69b72a916b927743069373ac863df1c1 > Update maven-common-artifact-filters to Version 3.1.1 > - > > Key: SUREFIRE-1989 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1989 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M6 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on pull request #348: Enabling Surefire to run test classes and test methods in any order specified by a new runOrder
Tibor17 commented on pull request #348: URL: https://github.com/apache/maven-surefire/pull/348#issuecomment-1022728134 Of course the documentation should say that `forkCount > 1` does not guarantee the order of classes. -- 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] (MWRAPPER-44) maven-wrapper may use outdated MavenWrapperDownloader.class
[ https://issues.apache.org/jira/browse/MWRAPPER-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482809#comment-17482809 ] ASF GitHub Bot commented on MWRAPPER-44: nhojpatrick edited a comment on pull request #15: URL: https://github.com/apache/maven-wrapper/pull/15#issuecomment-1022726725 > Hi @nhojpatrick, thanks for your PR, I already worked on this in the PR #13, it's a fairly large change with many other fixes, would you mind reviewing that PR to check if it works for you? Thanks! Hi @jorsol your `WrapperMojo.cleanup(Path)` achieves the same results. I was going to create a clean up method myself but wanted to get the fix raised with the change raised with the simplest diff to review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > maven-wrapper may use outdated MavenWrapperDownloader.class > --- > > Key: MWRAPPER-44 > URL: https://issues.apache.org/jira/browse/MWRAPPER-44 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jeremy Norris >Priority: Major > > When the mvnw script falls back to using MavenWrapperDownloader, it will use > an existing copy of MavenWrapperDownloader.class that may have originated > from compiling with an older version of MavenWrapperDownloader.java instead > of the current release version that is checked into the repository. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] nhojpatrick edited a comment on pull request #15: MWRAPPER-44 clean up MavenWrapperDownloader upon plugin execution
nhojpatrick edited a comment on pull request #15: URL: https://github.com/apache/maven-wrapper/pull/15#issuecomment-1022726725 > Hi @nhojpatrick, thanks for your PR, I already worked on this in the PR #13, it's a fairly large change with many other fixes, would you mind reviewing that PR to check if it works for you? Thanks! Hi @jorsol your `WrapperMojo.cleanup(Path)` achieves the same results. I was going to create a clean up method myself but wanted to get the fix raised with the change raised with the simplest diff to review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #348: Enabling Surefire to run test classes and test methods in any order specified by a new runOrder
Tibor17 edited a comment on pull request #348:
URL: https://github.com/apache/maven-surefire/pull/348#issuecomment-1022720153
The `TestListResolver` does not do the trick. It is only a filter. You
should not use it.
The whole trick is done in every Surefire Provider implementation. So in
this case, you have to modify the providers.
I think this snap code explains how we do it, see the `JUnit4Provider`:
```
private TestsToRun scanClassPath()
{
final TestsToRun scannedClasses = scanResult.applyFilter(
jUnit4TestChecker, testClassLoader );
return runOrderCalculator.orderTestClasses( scannedClasses );
}
```
The problem is that we do not work with methods. Only classes.
And we should remember JUnit5 because it knows the scripts, dynamic tests,
directories, etc.
So all you have to do is to serialize run order (enum + data), see
`BooterSerializer` and deserialize it via `BooterDeserializer`.
It means that you have transfered the config for `RunOrderCalculator` fom
plugin JVM to the forked JVM. Similar serialization trick in the in-plugin JVM.
Then you should obtain the instance of `RunOrderCalculator` in the
particular provider. The next step is to modify the section I mentioned above
which would include the methods as well.
The system property and TestListResolver parts can be avoided.
--
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] (MWRAPPER-44) maven-wrapper may use outdated MavenWrapperDownloader.class
[ https://issues.apache.org/jira/browse/MWRAPPER-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482808#comment-17482808 ] ASF GitHub Bot commented on MWRAPPER-44: nhojpatrick commented on pull request #15: URL: https://github.com/apache/maven-wrapper/pull/15#issuecomment-1022726725 > Hi @nhojpatrick, thanks for your PR, I already worked on this in the PR #13, it's a fairly large change with many other fixes, would you mind reviewing that PR to check if it works for you? Thanks! Hi @jorsol your `WrapperMojo.cleanup(Path)` achieves the same results. I was going to create a clean up method myself but wanted to get the fix raised with the change change and simplest diff to review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > maven-wrapper may use outdated MavenWrapperDownloader.class > --- > > Key: MWRAPPER-44 > URL: https://issues.apache.org/jira/browse/MWRAPPER-44 > Project: Maven Wrapper > Issue Type: Bug > Components: Maven Wrapper Scripts >Affects Versions: 3.1.0 >Reporter: Jeremy Norris >Priority: Major > > When the mvnw script falls back to using MavenWrapperDownloader, it will use > an existing copy of MavenWrapperDownloader.class that may have originated > from compiling with an older version of MavenWrapperDownloader.java instead > of the current release version that is checked into the repository. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-wrapper] nhojpatrick commented on pull request #15: MWRAPPER-44 clean up MavenWrapperDownloader upon plugin execution
nhojpatrick commented on pull request #15: URL: https://github.com/apache/maven-wrapper/pull/15#issuecomment-1022726725 > Hi @nhojpatrick, thanks for your PR, I already worked on this in the PR #13, it's a fairly large change with many other fixes, would you mind reviewing that PR to check if it works for you? Thanks! Hi @jorsol your `WrapperMojo.cleanup(Path)` achieves the same results. I was going to create a clean up method myself but wanted to get the fix raised with the change change and simplest diff to review. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #348: Enabling Surefire to run test classes and test methods in any order specified by a new runOrder
Tibor17 edited a comment on pull request #348: URL: https://github.com/apache/maven-surefire/pull/348#issuecomment-1022724116 It would help you and us if you have followed these steps, in separate commits, and each step would have unit tests: 1. serialize run order config + test 2. deserialize config + test 3. create deserialized instance of run order calculator, verify the config, and write a test 4. adjust the provider, isolate it in a test 5. write an integration test -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #348: Enabling Surefire to run test classes and test methods in any order specified by a new runOrder
Tibor17 edited a comment on pull request #348: URL: https://github.com/apache/maven-surefire/pull/348#issuecomment-1022724116 It would help you and us if you follow these steps, in separate commits, and each step would have unit tests: 1. serialize run order config + test 2. deserialize config + test 3. create deserialized instance of run order calculator, verify the config, and write a test 4. adjust the provider, isolate it in a test 5. write an integration test -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #449: [SUREFIRE-1987] Refactor ProviderDetector
Tibor17 commented on a change in pull request #449:
URL: https://github.com/apache/maven-surefire/pull/449#discussion_r793157137
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/surefire/providerapi/ProviderDetector.java
##
@@ -48,33 +52,36 @@
@Nonnull
public List resolve( ConfigurableProviderInfo
dynamicProvider, ProviderInfo... wellKnownProviders )
{
-List providersToRun = new ArrayList<>();
Set manuallyConfiguredProviders =
getManuallyConfiguredProviders();
-for ( String name : manuallyConfiguredProviders )
+
+List providersToRun =
manuallyConfiguredProviders.stream()
+.map( name -> findByName( name, wellKnownProviders )
+.orElseGet( () -> dynamicProvider.instantiate( name ) ) )
Review comment:
aha, it is a nested call, now I see. I can better read the second
option. Thx
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #348: Enabling Surefire to run test classes and test methods in any order specified by a new runOrder
Tibor17 commented on pull request #348: URL: https://github.com/apache/maven-surefire/pull/348#issuecomment-1022724116 It would help you and us if you follow these steps, in separate commit, and each step would have unit tests: 1. serialize run order config + test 2. deserialize config + test 3. create deserialized instance of run order calculator, verify the config, and write a test 4. adjust the provider, isolate it in a test 5. run an integration test -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #348: Enabling Surefire to run test classes and test methods in any order specified by a new runOrder
Tibor17 commented on pull request #348:
URL: https://github.com/apache/maven-surefire/pull/348#issuecomment-1022720153
The `TestListResolver` does not do the trick. It is only a filter. You
should not use it.
The whole trick is done in every Surefire Provider implementation. So in
this case, you have to modify the providers.
I think this snap code explains how we do it, see the `JUnit4Provider`:
```
private TestsToRun scanClassPath()
{
final TestsToRun scannedClasses = scanResult.applyFilter(
jUnit4TestChecker, testClassLoader );
return runOrderCalculator.orderTestClasses( scannedClasses );
}
```
The problem is that we do not work with methods. Only classes.
And we should remember JUnit5 because it know scripts, dynamic tests, etc.
So all you have to do is to serialize run order (enum + data), see
`BooterSerializer` and deserialize it via `BooterDeserializer`.
It means that you have transfered the config for `RunOrderCalculator` fom
plugin JVM to the forked JVM. Similar serialization trick in the in-plugin JVM.
Then you should obtain the instance of `RunOrderCalculator` in the
particular provider. The next step is to modify the section I mentioned above
which would include the methods as well.
The system property and TestListResolver parts can be avoided.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #440: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
Tibor17 commented on pull request #440: URL: https://github.com/apache/maven-surefire/pull/440#issuecomment-1022705606 @imonteroperez Thx for the unit test. I will use it. We have not covered this code with unit test yet so this would be worth to do it now. I have my IT already in progress, so I will commit the IT as well. T -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MCOMPILER-414) parameters flag does not apply to testCompile goal
[
https://issues.apache.org/jira/browse/MCOMPILER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482799#comment-17482799
]
Falko Modler commented on MCOMPILER-414:
[~rfscholte] this is the same problem as MCOMPILER-413, so it should be closed
as well (as of 3.9.0).
> parameters flag does not apply to testCompile goal
> --
>
> Key: MCOMPILER-414
> URL: https://issues.apache.org/jira/browse/MCOMPILER-414
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
>Reporter: Alberto Minetti
>Priority: Minor
>
> Seems that the true flag just applies properly to
> the compile goal, but not to the testCompile goal.
>
> *Workaround*: using the compilerArgs works for both goals compile and
> testCompile
> {{}}
> {{ -parameters}}
> {{}}
>
> Here on github you can find a working software with the current issue; the
> tests in master branch fail because of the usage of the flag,
> instead in the branch using-compilerArgs the build is succesful.
> [https://github.com/albertominetti/jackson-parameters/pull/1/commits/ad0fa7605fe378a4b900b7c911f4e7019533092f]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on a change in pull request #449: [SUREFIRE-1987] Refactor ProviderDetector
slawekjaranowski commented on a change in pull request #449:
URL: https://github.com/apache/maven-surefire/pull/449#discussion_r793128997
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/surefire/providerapi/ProviderDetector.java
##
@@ -48,33 +52,36 @@
@Nonnull
public List resolve( ConfigurableProviderInfo
dynamicProvider, ProviderInfo... wellKnownProviders )
{
-List providersToRun = new ArrayList<>();
Set manuallyConfiguredProviders =
getManuallyConfiguredProviders();
-for ( String name : manuallyConfiguredProviders )
+
+List providersToRun =
manuallyConfiguredProviders.stream()
+.map( name -> findByName( name, wellKnownProviders )
+.orElseGet( () -> dynamicProvider.instantiate( name ) ) )
Review comment:
`orElseGet` is called on returned Optional by `findByName`, can be:
```java
.map( name ->
findByName( name, wellKnownProviders ).orElseGet( () ->
dynamicProvider.instantiate( name ) ) )
.collect( toList() );
```
or
```java
.map( name ->
findByName( name, wellKnownProviders )
.orElseGet( () -> dynamicProvider.instantiate( name ) ) )
.collect( toList() );
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #449: [SUREFIRE-1987] Refactor ProviderDetector
Tibor17 commented on a change in pull request #449:
URL: https://github.com/apache/maven-surefire/pull/449#discussion_r793107753
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/surefire/providerapi/ProviderDetector.java
##
@@ -48,33 +52,36 @@
@Nonnull
public List resolve( ConfigurableProviderInfo
dynamicProvider, ProviderInfo... wellKnownProviders )
{
-List providersToRun = new ArrayList<>();
Set manuallyConfiguredProviders =
getManuallyConfiguredProviders();
-for ( String name : manuallyConfiguredProviders )
+
+List providersToRun =
manuallyConfiguredProviders.stream()
+.map( name -> findByName( name, wellKnownProviders )
+.orElseGet( () -> dynamicProvider.instantiate( name ) ) )
Review comment:
here is wrong identation
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #449: [SUREFIRE-1987] Refactor ProviderDetector
Tibor17 commented on pull request #449: URL: https://github.com/apache/maven-surefire/pull/449#issuecomment-1022664986 @slawekjaranowski LGTM -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #449: [SUREFIRE-1987] Refactor ProviderDetector
Tibor17 commented on a change in pull request #449:
URL: https://github.com/apache/maven-surefire/pull/449#discussion_r793090907
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/surefire/providerapi/ProviderDetector.java
##
@@ -48,33 +51,35 @@
@Nonnull
public List resolve( ConfigurableProviderInfo
dynamicProvider, ProviderInfo... wellKnownProviders )
{
-List providersToRun = new ArrayList<>();
Set manuallyConfiguredProviders =
getManuallyConfiguredProviders();
-for ( String name : manuallyConfiguredProviders )
+
+List providersToRun =
manuallyConfiguredProviders.stream()
+.map( name -> findByName( name, dynamicProvider,
wellKnownProviders ) )
+.collect( Collectors.toList() );
+
+
+if ( providersToRun.isEmpty() )
{
-ProviderInfo wellKnown = findByName( name, wellKnownProviders );
-ProviderInfo providerToAdd = wellKnown != null ? wellKnown :
dynamicProvider.instantiate( name );
-logger.info( "Using configured provider " +
providerToAdd.getProviderName() );
-providersToRun.add( providerToAdd );
+return autoDetectOneWellKnownProvider( wellKnownProviders )
+.map( Collections::singletonList )
+.orElse( Collections.emptyList() );
+}
+else
+{
+providersToRun.forEach( p -> logger.info( "Using configured
provider " + p.getProviderName() ) );
Review comment:
This logger should be called between the lines 57 and 58, or after the
line 61.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #449: [SUREFIRE-1987] Refactor ProviderDetector
Tibor17 commented on a change in pull request #449:
URL: https://github.com/apache/maven-surefire/pull/449#discussion_r793090907
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/surefire/providerapi/ProviderDetector.java
##
@@ -48,33 +51,35 @@
@Nonnull
public List resolve( ConfigurableProviderInfo
dynamicProvider, ProviderInfo... wellKnownProviders )
{
-List providersToRun = new ArrayList<>();
Set manuallyConfiguredProviders =
getManuallyConfiguredProviders();
-for ( String name : manuallyConfiguredProviders )
+
+List providersToRun =
manuallyConfiguredProviders.stream()
+.map( name -> findByName( name, dynamicProvider,
wellKnownProviders ) )
+.collect( Collectors.toList() );
+
+
+if ( providersToRun.isEmpty() )
{
-ProviderInfo wellKnown = findByName( name, wellKnownProviders );
-ProviderInfo providerToAdd = wellKnown != null ? wellKnown :
dynamicProvider.instantiate( name );
-logger.info( "Using configured provider " +
providerToAdd.getProviderName() );
-providersToRun.add( providerToAdd );
+return autoDetectOneWellKnownProvider( wellKnownProviders )
+.map( Collections::singletonList )
+.orElse( Collections.emptyList() );
+}
+else
+{
+providersToRun.forEach( p -> logger.info( "Using configured
provider " + p.getProviderName() ) );
Review comment:
This logger should be called between the lines 57 and 58.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #449: [SUREFIRE-1987] Refactor ProviderDetector
Tibor17 commented on a change in pull request #449:
URL: https://github.com/apache/maven-surefire/pull/449#discussion_r793085774
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/surefire/providerapi/ProviderDetector.java
##
@@ -48,33 +51,35 @@
@Nonnull
public List resolve( ConfigurableProviderInfo
dynamicProvider, ProviderInfo... wellKnownProviders )
{
-List providersToRun = new ArrayList<>();
Set manuallyConfiguredProviders =
getManuallyConfiguredProviders();
-for ( String name : manuallyConfiguredProviders )
+
+List providersToRun =
manuallyConfiguredProviders.stream()
+.map( name -> findByName( name, dynamicProvider,
wellKnownProviders ) )
+.collect( Collectors.toList() );
Review comment:
You can use `import static` which makes the code more compact.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #449: [SUREFIRE-1987] Refactor ProviderDetector
Tibor17 commented on a change in pull request #449:
URL: https://github.com/apache/maven-surefire/pull/449#discussion_r793083484
##
File path:
maven-surefire-common/src/main/java/org/apache/maven/surefire/providerapi/ProviderDetector.java
##
@@ -90,15 +95,13 @@
}
}
-private ProviderInfo findByName( String providerClassName, ProviderInfo...
wellKnownProviders )
+@Nonnull
+private ProviderInfo findByName( String providerClassName,
+ ConfigurableProviderInfo dynamicProvider,
ProviderInfo... wellKnownProviders )
{
-for ( ProviderInfo wellKnownProvider : wellKnownProviders )
-{
-if ( wellKnownProvider.getProviderName().equals( providerClassName
) )
-{
-return wellKnownProvider;
-}
-}
-return null;
+return Arrays.stream( wellKnownProviders )
+.filter( p -> p.getProviderName().equals( providerClassName ) )
+.findFirst()
+.orElseGet( () -> dynamicProvider.instantiate( providerClassName )
);
Review comment:
`.orElseGet( () -> dynamicProvider.instantiate( providerClassName ) )`
should be after the line 57.
This method is about finding something only.
--
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] (SUREFIRE-1989) Update maven-common-artifact-filters to Version 3.1.1
Tibor Digana created SUREFIRE-1989: -- Summary: Update maven-common-artifact-filters to Version 3.1.1 Key: SUREFIRE-1989 URL: https://issues.apache.org/jira/browse/SUREFIRE-1989 Project: Maven Surefire Issue Type: Dependency upgrade Components: Maven Failsafe Plugin, Maven Surefire Plugin Reporter: Tibor Digana Fix For: 3.0.0-M6 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski opened a new pull request #449: [SUREFIRE-1987] Refactor ProviderDetector
slawekjaranowski opened a new pull request #449: URL: https://github.com/apache/maven-surefire/pull/449 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/SUREFIRE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [x] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[SUREFIRE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `SUREFIRE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Run `mvn clean install` 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 install`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [x] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [x] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] winglam commented on pull request #348: Enabling Surefire to run test classes and test methods in any order specified by a new runOrder
winglam commented on pull request #348: URL: https://github.com/apache/maven-surefire/pull/348#issuecomment-1022581902 Hello @Tibor17 Thanks for following up on these changes. I'm a bit busy this week but I will plan on updating these changes by next week. Currently, my changes seem to use `TestListResolver` as both a filter and a Comparator (https://github.com/apache/maven-surefire/pull/348/files#diff-390b26f9fa7b88f45e645b6b1fc6b4018570ea482062b93ea85fa8c1fe20R533). Would it be fine if I keep the filter-related changes in `TestListResolver` and just moved the Comparator changes elsewhere, or do you want me to not make any changes to `TestListResolver` at all? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #445: [SUREFIRE-1962] Unit test for ProviderInfo#isApplicable
slawekjaranowski commented on pull request #445: URL: https://github.com/apache/maven-surefire/pull/445#issuecomment-1022562681 issues created and linked -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a change in pull request #139: [MRESOLVER-230] Make supported checksum algorithms extensible
michael-o commented on a change in pull request #139:
URL: https://github.com/apache/maven-resolver/pull/139#discussion_r792996067
##
File path: src/site/markdown/about-checksums.md
##
@@ -0,0 +1,72 @@
+# About checksums
Review comment:
About Checksums
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/impl/guice/AetherModule.java
##
@@ -42,6 +42,11 @@
import org.eclipse.aether.impl.RepositoryEventDispatcher;
import org.eclipse.aether.internal.impl.DefaultTrackingFileManager;
import org.eclipse.aether.internal.impl.TrackingFileManager;
+import org.eclipse.aether.internal.impl.checksum.ChecksumAlgorithmFactoryMD5;
Review comment:
I think the also name should be at the of the class name. Just like
`FileInputStream` and not `InputStreamFile`.
##
File path: src/site/site.xml
##
@@ -27,6 +27,7 @@ under the License.
+
Review comment:
About Checksums
##
File path:
maven-resolver-connector-basic/src/main/java/org/eclipse/aether/connector/basic/ChecksumValidator.java
##
@@ -241,12 +252,12 @@ public void commit()
{
if ( tmp instanceof File )
{
-fileProcessor.move( (File) tmp, checksumFile );
+fileProcessor.move( ( File ) tmp, checksumFile );
Review comment:
As far as I know we don't have spaces around casts.
##
File path: src/site/markdown/about-checksums.md
##
@@ -0,0 +1,72 @@
+# About checksums
+
+
+Maven Resolver uses checksums to verify the consistency of the downloaded
+artifacts. Checksums are usually laid out in repositories next to the file in
question, with file
+extension telling the checksum algorithm that produced the given checksum file
content. Current Maven Repository
+layout contains SHA-1 and MD5 checksums by default (they are produced by
Resolver by default).
+
+Historically, Maven Resolver used `java.security.MessageDigest` to implement
checksums. So to say, secure one-way
+hashes provided by Java Cryptography Architecture were (mis)used to implement
checksums for transport integrity
+validation. There is no misunderstanding here, secure hashes MAY be used as
checksums, as there is quite some
+overlap between "checksums" and "hashes" in general. But this simplicity comes
at a price: cryptographically "safe"
+algorithms require way more CPU cycles to calculate checksum, while all their
purpose is just
+"integrity validation", nothing more. There is no "security", "trust" or
whatever else implied or expected from
+them.
+
+If you are interested in "trust" in your artifacts, it is Artifact Signatures
(for example
+[GPG Signatures](https://maven.apache.org/plugins/maven-gpg-plugin/)) that you
should look for.
+
+Hence, the usual argument that "XXX algorithm is unsafe, deprecated, not
secure anymore" does not stand in use case
+of Maven Resolver: there is nothing "secure" being involved with checksums.
Moreover, this is true not only for SHA-1
+algorithm, but even for its "elder brother" MD5. Both algorithms are still
widely used today as "transport integrity
+validation" or "error detection" (aka "bit-rot detection").
+
+## Checksum changes
Review comment:
Checksum Changes
##
File path:
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/Maven2RepositoryLayoutFactory.java
##
@@ -163,45 +204,47 @@ public URI getLocation( Metadata metadata, boolean upload
)
return toUri( path.toString() );
}
-public List getChecksums( Artifact artifact, boolean upload,
URI location )
+@Override
+public List getChecksumLocations( Artifact artifact,
boolean upload, URI location )
{
return getChecksums( location );
}
-public List getChecksums( Metadata metadata, boolean upload,
URI location )
+@Override
+public List getChecksumLocations( Metadata metadata,
boolean upload, URI location )
{
return getChecksums( location );
}
-private List getChecksums( URI location )
+private List getChecksums( URI location )
Review comment:
`getChecksumLocations`?
--
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] (SUREFIRE-1988) Refactor DynamicProviderInfo
Slawomir Jaranowski created SUREFIRE-1988:
-
Summary: Refactor DynamicProviderInfo
Key: SUREFIRE-1988
URL: https://issues.apache.org/jira/browse/SUREFIRE-1988
Project: Maven Surefire
Issue Type: Improvement
Reporter: Slawomir Jaranowski
{{ DynamicProviderInfo( null ).isApplicable() }} should return {{false}}
to be consistent with other {{ProviderInfo}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MARCHETYPES-67) Fix maven-archetype-plugin test case
[
https://issues.apache.org/jira/browse/MARCHETYPES-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482705#comment-17482705
]
David Gibbs commented on MARCHETYPES-67:
[~lorebett] Thanks for this it was useful to me, I thought it looked wrong as
well and it confused me when I checked why my tests failed. I'm not involved in
these projects but it can't hurt to put in a PR. No-one has disputed that this
is a bug and I certainly encountered the same issue a year later than you did.
I can confirm that your fix works.
> Fix maven-archetype-plugin test case
>
>
> Key: MARCHETYPES-67
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-67
> Project: Maven Archetype Bundles
> Issue Type: Bug
> Components: Maven Plugin Archetype
>Affects Versions: 1.4
>Reporter: Lorenzo Bettini
>Priority: Major
>
> I've just started implementing (and testing) Maven plugins, but the test case
> (MyMojoTest) and, most of all, the corresponding project-to-test look wrong.
> The POM in project-to-test (for a project created with artifactId
> example-plugin1 and groupId com.example) is as follows
>
> {code:xml}
> ...
> com.example
> example-plugin1
> 1.0-SNAPSHOT
> jar
> Test MyMojo
>
>
>
> maven-my-plugin
>
>
>
> target/test-harness/project-to-test
>
>
>
>
>
> {code}
> The artifactId refers to the actual plugin's artifactId example-plugin1 and
> groupId com.example (from what I understand that's not too important since it
> won't be deployed); what looks really wrong is the plugin configuration which
> refers to an unknown `maven-my-plugin`, which does not exist (even without
> any groupId).
> The test case MyMojoTest actually succeeds:
> {code:java}
> @Test
> public void testSomething()
> throws Exception
> {
> File pom = new File( "target/test-classes/project-to-test/" );
> assertNotNull( pom );
> assertTrue( pom.exists() );
> MyMojo myMojo = ( MyMojo ) rule.lookupConfiguredMojo( pom, "touch" );
> assertNotNull( myMojo );
> myMojo.execute();
> File outputDirectory = ( File ) rule.getVariableValueFromObject(
> myMojo, "outputDirectory" );
> assertNotNull( outputDirectory );
> assertTrue( outputDirectory.exists() );
> File touch = new File( outputDirectory, "touch.txt" );
> assertTrue( touch.exists() );
> }
> {code}
> but it does not actually check that the outputDirectory is the one specified
> in the configuration section: `target/test-harness/project-to-test`.
> In fact, if you add the additional check:
> {code:java}
> ...
> File expectedOutputDirectory = new File
> (pom.getAbsoluteFile(), "target/test-harness/project-to-test");
> assertEquals(expectedOutputDirectory, outputDirectory);
> ...
> {code}
>
> This will fail (the outputDirectory is the default one, `target`, not the
> one specified in the configuration). By the way, I think this additional
> check should be part of the test case.
> The project-to-test POM should actually refer to the real plugin under test,
> with proper groupId (that's required as well) and artifactId, and the
> project's artifactId should be something else.
> This project-to-test POM makes the richer test case succeeds:
>
> {code:xml}
> ...
> com.example
> project-to-test
> 1.0-SNAPSHOT
> jar
> Test MyMojo
>
>
>
> com.example
> example-plugin1
>
>
>
> target/test-harness/project-to-test
>
>
>
>
> ...
> {code}
> Am I right or am I missing something?
> I can provide a PR in case
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7349) Limit relocation warning message to direct dependencies only
[
https://issues.apache.org/jira/browse/MNG-7349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482685#comment-17482685
]
Hudson commented on MNG-7349:
-
Build succeeded in Jenkins: Maven » Maven TLP » maven » MNG-7276 #24
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7276/24/
> Limit relocation warning message to direct dependencies only
>
>
> Key: MNG-7349
> URL: https://issues.apache.org/jira/browse/MNG-7349
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 3.8.3, 3.8.4
>Reporter: Joep Weijers
>Assignee: Guillaume Nodet
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.5
>
>
> In the
> [commit|https://github.com/apache/maven/commit/a1ba33069fad1fb9c6e9cd458ad233ff3a74aadd]
> that solved MNG-7253, the check for relocations was moved from the
> DefaultProjectDependenciesResolver to the DefaultArtifactDescriptorReader.
> This means that the relocation messages are not only shown on project
> dependencies, but on any artifact that is read.
> This may lead to unfixable WARNINGS in the output if a plugin transitively
> uses a relocated artifact.
> This can be reproduced by calling {{mvn dependency:tree}} with a simple,
> empty {{{}pom.xml{}}}. This will give the following warning:
> {code:java}
> [WARNING] The artifact xml-apis:xml-apis:jar:2.0.2 has been relocated to
> xml-apis:xml-apis:jar:1.0.b2
> {code}
> The default maven-dependency-plugin version is 2.8 and it depends on
> {{{}org.apache.maven.reporting:maven-reporting-impl:2.0.5{}}}, which depends
> on {{commons-validator:commons-validator:1.2.0}} which depends on
> {{{}xml-apis:xml-apis:2.0.2{}}}.
> In this particular case, updating to a recent maven-dependency-plugin version
> solves the issue. But since the transitive dependencies of plugins are not
> under the control of the end users, I don't think this warning should be
> shown.
> *Workaround:*
> Stay on Maven 3.8.2 or disable logging on the DefaultArtifactDescriptorReader:
> {code:java}
> -Dorg.slf4j.simpleLogger.log.org.apache.maven.repository.internal.DefaultArtifactDescriptorReader=error
> {code}
> Although this disables all relocation messages, including the ones you might
> be interested in.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MPLUGIN-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482641#comment-17482641
]
ASF GitHub Bot commented on MPLUGIN-388:
slawekjaranowski commented on pull request #66:
URL:
https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022433836
I see some inconsistency - cosmetics
- `mavenInvokerPluginVersion` - defined in root pom used in
`maven-plugin-plugin/pom.xml`
- `mavenPluginPlugin.version` - defined and used `plugin-plugin/pom.xml`
- different format of properties for versions once with dot once without dot
maybe `pluginMangment` in project root pom?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] slawekjaranowski commented on pull request #66: [MPLUGIN-388] Make reporting dependency optional
slawekjaranowski commented on pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022433836 I see some inconsistency - cosmetics - `mavenInvokerPluginVersion` - defined in root pom used in `maven-plugin-plugin/pom.xml` - `mavenPluginPlugin.version` - defined and used `plugin-plugin/pom.xml` - different format of properties for versions once with dot once without dot maybe `pluginMangment` in project root pom? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGIN-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482619#comment-17482619
]
ASF GitHub Bot commented on MPLUGIN-388:
cstamas commented on a change in pull request #66:
URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r792854238
##
File path: maven-plugin-plugin/pom.xml
##
@@ -270,8 +249,7 @@
org.apache.maven.plugins
maven-plugin-plugin
-3.6.0
-
+3.6.4
Review comment:
tx, fixed
--
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
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] cstamas commented on a change in pull request #66: [MPLUGIN-388] Make reporting dependency optional
cstamas commented on a change in pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r792854238 ## File path: maven-plugin-plugin/pom.xml ## @@ -270,8 +249,7 @@ org.apache.maven.plugins maven-plugin-plugin -3.6.0 - +3.6.4 Review comment: tx, fixed -- 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] (MPIR-403) Travis link should point to travis-ci.com instead of travis-ci.org
[ https://issues.apache.org/jira/browse/MPIR-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated MPIR-403: - Description: travis-ci.org is gonna be shut down end of May 2021 (https://blog.travis-ci.com/2021-05-07-orgshutdown) so https://github.com/apache/maven-project-info-reports-plugin/blob/f5de0d104d371ec76459b347ef44050ed5b60c9d/src/main/resources/project-info-reports.properties#L31 should point to travis-ci.com instead. (was: travis.org is gonna be shut down end of May 2021 (https://blog.travis-ci.com/2021-05-07-orgshutdown) so https://github.com/apache/maven-project-info-reports-plugin/blob/f5de0d104d371ec76459b347ef44050ed5b60c9d/src/main/resources/project-info-reports.properties#L31 should point to travis.com instead.) > Travis link should point to travis-ci.com instead of travis-ci.org > -- > > Key: MPIR-403 > URL: https://issues.apache.org/jira/browse/MPIR-403 > Project: Maven Project Info Reports Plugin > Issue Type: Bug >Affects Versions: 3.1.2 >Reporter: Konrad Windszus >Assignee: Michael Osipov >Priority: Major > Fix For: 3.1.3 > > > travis-ci.org is gonna be shut down end of May 2021 > (https://blog.travis-ci.com/2021-05-07-orgshutdown) so > https://github.com/apache/maven-project-info-reports-plugin/blob/f5de0d104d371ec76459b347ef44050ed5b60c9d/src/main/resources/project-info-reports.properties#L31 > should point to travis-ci.com instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (SUREFIRE-1987) Refactor ProviderDetector#autoDetectOneWellKnownProvider
[
https://issues.apache.org/jira/browse/SUREFIRE-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned SUREFIRE-1987:
-
Assignee: Slawomir Jaranowski
> Refactor ProviderDetector#autoDetectOneWellKnownProvider
>
>
> Key: SUREFIRE-1987
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1987
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> Method {{ProviderDetector#autoDetectOneWellKnownProvider}}
> has return type as {{List}}
> as name suggests should return one element.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (SUREFIRE-1987) Refactor ProviderDetector#autoDetectOneWellKnownProvider
Slawomir Jaranowski created SUREFIRE-1987:
-
Summary: Refactor ProviderDetector#autoDetectOneWellKnownProvider
Key: SUREFIRE-1987
URL: https://issues.apache.org/jira/browse/SUREFIRE-1987
Project: Maven Surefire
Issue Type: Improvement
Reporter: Slawomir Jaranowski
Method {{ProviderDetector#autoDetectOneWellKnownProvider}}
has return type as {{List}}
as name suggests should return one element.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MSHARED-1030) PatternIncludesArtifactFilter incorrect filtering with classifier
[
https://issues.apache.org/jira/browse/MSHARED-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MSHARED-1030.
Resolution: Duplicate
> PatternIncludesArtifactFilter incorrect filtering with classifier
> -
>
> Key: MSHARED-1030
> URL: https://issues.apache.org/jira/browse/MSHARED-1030
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-common-artifact-filters
>Affects Versions: maven-common-artifact-filters-3.2.0
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> For pattern:
> {code:java}
> org.surefire.dependency:dependent-artifact2:*:*:tests-jdk15
> {code}
> and {{{}artifact{}}}:
> {code:java}
> groupId:org.surefire.dependency
> artifactId: dependent-artifact2
> version:1.0
> scope: test
> type: jar
> classifier: tests-jdk15
> {code}
> code:
> {code:java}
> filter = PatternIncludesArtifactFilter( pattern );
> filter.iclude( artifact ) <-- return false
> {code}
> For version: {{3.1.1}}
> {code}
> filter.iclude( artifact ) < -- return true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #431: Bump maven-common-artifact-filters from 3.1.0 to 3.2.0
slawekjaranowski commented on pull request #431: URL: https://github.com/apache/maven-surefire/pull/431#issuecomment-1022372124 I can't confirm if we use correct pattern in MOJO .. it is undocumented https://issues.apache.org/jira/browse/MSHARED-1022 -- 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-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482603#comment-17482603
]
ASF GitHub Bot commented on MPLUGIN-388:
slawekjaranowski commented on a change in pull request #66:
URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r792819254
##
File path: maven-plugin-plugin/pom.xml
##
@@ -270,8 +249,7 @@
org.apache.maven.plugins
maven-plugin-plugin
-3.6.0
-
+3.6.4
Review comment:
line 277
--
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
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] slawekjaranowski commented on a change in pull request #66: [MPLUGIN-388] Make reporting dependency optional
slawekjaranowski commented on a change in pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r792819254 ## File path: maven-plugin-plugin/pom.xml ## @@ -270,8 +249,7 @@ org.apache.maven.plugins maven-plugin-plugin -3.6.0 - +3.6.4 Review comment: line 277 -- 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-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482601#comment-17482601
]
ASF GitHub Bot commented on MPLUGIN-388:
cstamas commented on a change in pull request #66:
URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r792812013
##
File path: maven-plugin-plugin/pom.xml
##
@@ -270,8 +249,7 @@
org.apache.maven.plugins
maven-plugin-plugin
-3.6.0
-
+3.6.4
Review comment:
and where do I do that?
--
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
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] cstamas commented on a change in pull request #66: [MPLUGIN-388] Make reporting dependency optional
cstamas commented on a change in pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r792812013 ## File path: maven-plugin-plugin/pom.xml ## @@ -270,8 +249,7 @@ org.apache.maven.plugins maven-plugin-plugin -3.6.0 - +3.6.4 Review comment: and where do I do that? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #431: Bump maven-common-artifact-filters from 3.1.0 to 3.2.0
Tibor17 commented on pull request #431: URL: https://github.com/apache/maven-surefire/pull/431#issuecomment-1022351745 @slawekjaranowski Additionally, we have a problem with this pattern in MOJO, pls confirm. https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L752 -- 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] (MSHARED-1031) PatternIncludesArtifactFilter#include( Artifact )
[
https://issues.apache.org/jira/browse/MSHARED-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated MSHARED-1031:
--
Description:
In principle the call looks like this:
{noformat}
new
PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:*:tests-jdk15").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
with scope tests)
{noformat}
The problem is that PatternIncludesArtifactFilter uses the comparison via
{{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}}, and next
issue is that PatternIncludesArtifactFilter expects wildcard on classifier
which is not very useful, see the comment {{we only accept 5 tokens if the
classifier = '*'}}.
was:
In principle the call looks like this:
{noformat}
new
PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
with scope tests)
{noformat}
The problem is that PatternIncludesArtifactFilter uses the comparison via
{{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}}, and next
issue is that PatternIncludesArtifactFilter expects wildcard on classifier
which is not very useful, see the comment {{we only accept 5 tokens if the
classifier = '*'}}.
> PatternIncludesArtifactFilter#include( Artifact )
> --
>
> Key: MSHARED-1031
> URL: https://issues.apache.org/jira/browse/MSHARED-1031
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-common-artifact-filters
>Affects Versions: maven-common-artifact-filters-3.2.0
>Reporter: Tibor Digana
>Priority: Major
>
> In principle the call looks like this:
> {noformat}
> new
> PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:*:tests-jdk15").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
> with scope tests)
> {noformat}
> The problem is that PatternIncludesArtifactFilter uses the comparison via
> {{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}}, and next
> issue is that PatternIncludesArtifactFilter expects wildcard on classifier
> which is not very useful, see the comment {{we only accept 5 tokens if the
> classifier = '*'}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on pull request #431: Bump maven-common-artifact-filters from 3.1.0 to 3.2.0
Tibor17 commented on pull request #431: URL: https://github.com/apache/maven-surefire/pull/431#issuecomment-1022349746 me too https://issues.apache.org/jira/browse/MSHARED-1031 ;-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MSHARED-1031) PatternIncludesArtifactFilter#include( Artifact )
[
https://issues.apache.org/jira/browse/MSHARED-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482590#comment-17482590
]
Tibor Digana commented on MSHARED-1031:
---
It was working fine in version 3.1.0 and 3.1.1.
> PatternIncludesArtifactFilter#include( Artifact )
> --
>
> Key: MSHARED-1031
> URL: https://issues.apache.org/jira/browse/MSHARED-1031
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-common-artifact-filters
>Affects Versions: maven-common-artifact-filters-3.2.0
>Reporter: Tibor Digana
>Priority: Major
>
> In principle the call looks like this:
> {noformat}
> new
> PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
> with scope tests)
> {noformat}
> The problem is that PatternIncludesArtifactFilter uses the comparison via
> {{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}}, and next
> issue is that PatternIncludesArtifactFilter expects wildcard on classifier
> which is not very useful, see the comment {{we only accept 5 tokens if the
> classifier = '*'}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MSHARED-1031) PatternIncludesArtifactFilter#include( Artifact )
[
https://issues.apache.org/jira/browse/MSHARED-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated MSHARED-1031:
--
Description:
In principle the call looks like this:
{noformat}
new
PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
with scope tests)
{noformat}
The problem is that PatternIncludesArtifactFilter uses the comparison via
{{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}}, and next
issue is that PatternIncludesArtifactFilter expects wildcard on classifier
which is not very useful, see the comment {{we only accept 5 tokens if the
classifier = '*'}}.
was:
In principle the call looks like this:
{noformat}
new
PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
with scope tests)
{noformat}
The problem is that PatternIncludesArtifactFilter uses the comparison via
{{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}} and it expects
wildcard on classifier, see the comment {{we only accept 5 tokens if the
classifier = '*'}}.
> PatternIncludesArtifactFilter#include( Artifact )
> --
>
> Key: MSHARED-1031
> URL: https://issues.apache.org/jira/browse/MSHARED-1031
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-common-artifact-filters
>Affects Versions: maven-common-artifact-filters-3.2.0
>Reporter: Tibor Digana
>Priority: Major
>
> In principle the call looks like this:
> {noformat}
> new
> PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
> with scope tests)
> {noformat}
> The problem is that PatternIncludesArtifactFilter uses the comparison via
> {{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}}, and next
> issue is that PatternIncludesArtifactFilter expects wildcard on classifier
> which is not very useful, see the comment {{we only accept 5 tokens if the
> classifier = '*'}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MSHARED-1031) PatternIncludesArtifactFilter#include( Artifact )
[
https://issues.apache.org/jira/browse/MSHARED-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated MSHARED-1031:
--
Description:
In principle the call looks like this:
{{new
PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
with scope tests)}}
The problem is that PatternIncludesArtifactFilter uses the comparison via
{{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}} and it expects
wildcard on classifier, see the comment {{we only accept 5 tokens if the
classifier = '*'}}.
was:
In principle the call looks like this:
new
PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
with scope tests)
The problem is that PatternIncludesArtifactFilter uses the comparison via
{{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}} and it expects
wildcard on classifier, see the comment {{we only accept 5 tokens if the
classifier = '*'}}.
> PatternIncludesArtifactFilter#include( Artifact )
> --
>
> Key: MSHARED-1031
> URL: https://issues.apache.org/jira/browse/MSHARED-1031
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-common-artifact-filters
>Affects Versions: maven-common-artifact-filters-3.2.0
>Reporter: Tibor Digana
>Priority: Major
>
> In principle the call looks like this:
> {{new
> PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
> with scope tests)}}
> The problem is that PatternIncludesArtifactFilter uses the comparison via
> {{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}} and it
> expects wildcard on classifier, see the comment {{we only accept 5 tokens if
> the classifier = '*'}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MSHARED-1031) PatternIncludesArtifactFilter#include( Artifact )
[
https://issues.apache.org/jira/browse/MSHARED-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated MSHARED-1031:
--
Description:
In principle the call looks like this:
{noformat}
new
PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
with scope tests)
{noformat}
The problem is that PatternIncludesArtifactFilter uses the comparison via
{{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}} and it expects
wildcard on classifier, see the comment {{we only accept 5 tokens if the
classifier = '*'}}.
was:
In principle the call looks like this:
{{new
PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
with scope tests)}}
The problem is that PatternIncludesArtifactFilter uses the comparison via
{{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}} and it expects
wildcard on classifier, see the comment {{we only accept 5 tokens if the
classifier = '*'}}.
> PatternIncludesArtifactFilter#include( Artifact )
> --
>
> Key: MSHARED-1031
> URL: https://issues.apache.org/jira/browse/MSHARED-1031
> Project: Maven Shared Components
> Issue Type: Bug
> Components: maven-common-artifact-filters
>Affects Versions: maven-common-artifact-filters-3.2.0
>Reporter: Tibor Digana
>Priority: Major
>
> In principle the call looks like this:
> {noformat}
> new
> PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
> with scope tests)
> {noformat}
> The problem is that PatternIncludesArtifactFilter uses the comparison via
> {{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}} and it
> expects wildcard on classifier, see the comment {{we only accept 5 tokens if
> the classifier = '*'}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MSHARED-1031) PatternIncludesArtifactFilter#include( Artifact )
Tibor Digana created MSHARED-1031:
-
Summary: PatternIncludesArtifactFilter#include( Artifact )
Key: MSHARED-1031
URL: https://issues.apache.org/jira/browse/MSHARED-1031
Project: Maven Shared Components
Issue Type: Bug
Components: maven-common-artifact-filters
Affects Versions: maven-common-artifact-filters-3.2.0
Reporter: Tibor Digana
In principle the call looks like this:
new
PatternIncludesArtifactFilter("org.surefire.dependency:dependent-artifact2:*:tests-jdk15:*").include("org.surefire.dependency:dependent-artifact2:jar:tests-jdk15:1.0"
with scope tests)
The problem is that PatternIncludesArtifactFilter uses the comparison via
{{!=}} on {{char[]}}, see more specifically {{tokens[3] != ANY}} and it expects
wildcard on classifier, see the comment {{we only accept 5 tokens if the
classifier = '*'}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #431: Bump maven-common-artifact-filters from 3.1.0 to 3.2.0
slawekjaranowski commented on pull request #431: URL: https://github.com/apache/maven-surefire/pull/431#issuecomment-1022336759 I just created issue: https://issues.apache.org/jira/browse/MSHARED-1030 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MSHARED-1030) PatternIncludesArtifactFilter incorrect filtering with classifier
Slawomir Jaranowski created MSHARED-1030:
Summary: PatternIncludesArtifactFilter incorrect filtering with
classifier
Key: MSHARED-1030
URL: https://issues.apache.org/jira/browse/MSHARED-1030
Project: Maven Shared Components
Issue Type: Bug
Components: maven-common-artifact-filters
Affects Versions: maven-common-artifact-filters-3.2.0
Reporter: Slawomir Jaranowski
For pattern:
{code:java}
org.surefire.dependency:dependent-artifact2:*:*:tests-jdk15
{code}
and {{{}artifact{}}}:
{code:java}
groupId:org.surefire.dependency
artifactId: dependent-artifact2
version:1.0
scope: test
type: jar
classifier: tests-jdk15
{code}
code:
{code:java}
filter = PatternIncludesArtifactFilter( pattern );
filter.iclude( artifact ) <-- return false
{code}
For version: {{3.1.1}}
{code}
filter.iclude( artifact ) < -- return true
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-surefire] Tibor17 commented on pull request #431: Bump maven-common-artifact-filters from 3.1.0 to 3.2.0
Tibor17 commented on pull request #431: URL: https://github.com/apache/maven-surefire/pull/431#issuecomment-1022333756 @slawekjaranowski I found that there are issues on both sides. First, our test used [wrong artifact parrent](https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/util/DependenciesScannerTest.java#L106), it should be like this: `groupId[:artifactId[:type[:classifier][:version]]]` Second, the library has two issues. It uses the comparison via `!=` on `char[]`, see more specifically `tokens[3] != ANY` and it expects wildcard on classifier, see the comment `we only accept 5 tokens if the classifier = '*'`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] ibabiankou commented on pull request #142: [MRESOLVER-7] Download dependency POMs in parallel
ibabiankou commented on pull request #142: URL: https://github.com/apache/maven-resolver/pull/142#issuecomment-1022263329 Not that it's solid proof, but got a very similar exception today while using the stock maven 3.8.4 樂 Stack Trace ```java [ERROR] Failed to execute goal on project dummy-artifact: Could not resolve dependencies for project dummy-group:dummy-artifact:jar:63.0-SNAPSHOT: Could not transfer artifact io.sentry:sentry:jar:5.5.3 from/to nexus-server (https://nexus.at-our-company.com/repository/maven-public): /Users/user/.m2/repository/io/sentry/sentry/5.5.3/sentry-5.5.3.jar.part (No such file or directory) -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project dummy-artifact: Could not resolve dependencies for project dummy-group:dummy-artifact:jar:63.0-SNAPSHOT: Could not transfer artifact io.sentry:sentry:jar:5.5.3 from/to nexus-server (https://nexus.at-our-company.com/repository/maven-public): /Users/user/.m2/repository/io/sentry/sentry/5.5.3/sentry-5.5.3.jar.part (No such file or directory) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies (LifecycleDependencyResolver.java:269) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies (LifecycleDependencyResolver.java:147) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved (MojoExecutor.java:248) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:202) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:196) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:186) at java.util.concurrent.FutureTask.run (FutureTask.java:264) at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515) at java.util.concurrent.FutureTask.run (FutureTask.java:264) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628) at java.lang.Thread.run (Thread.java:829) Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project dummy-group:dummy-artifact:jar:63.0-SNAPSHOT: Could not transfer artifact io.sentry:sentry:jar:5.5.3 from/to nexus-server (https://nexus.at-our-company.com/repository/maven-public): /Users/user/.m2/repository/io/sentry/sentry/5.5.3/sentry-5.5.3.jar.part (No such file or directory) at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve (DefaultProjectDependenciesResolver.java:198) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies (LifecycleDependencyResolver.java:243) at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies (LifecycleDependencyResolver.java:147) at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved (MojoExecutor.java:248) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:202) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156) at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:196) at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call (MultiThreadedBuilder.java:186) at java.util.concurrent.FutureTask.run (FutureTask.java:264) at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:515) at java.util.concurrent.FutureTask.run (FutureTask.java:264) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1128) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:628) at java.lang.Thread.run (Thread.java:829) Caused by: org.eclipse.aether.resolution.DependencyResolutionException: Could not transfer artifact io.sentry:sentry:jar:5.5.3 from/to nexus-server (https://nexus.at-our-company.com/repository/maven-public): /Users/user/.m2/repository/io/sentry/sentry/5.5.3/sentry-5.5.3.jar.part (No such file or directory) at
[jira] [Commented] (MPLUGIN-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482524#comment-17482524
]
ASF GitHub Bot commented on MPLUGIN-388:
slawekjaranowski commented on a change in pull request #66:
URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r792699198
##
File path: maven-plugin-plugin/pom.xml
##
@@ -270,8 +249,7 @@
org.apache.maven.plugins
maven-plugin-plugin
-3.6.0
-
+3.6.4
Review comment:
please also update version for reporting -> m-p-p
--
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
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] slawekjaranowski commented on a change in pull request #66: [MPLUGIN-388] Make reporting dependency optional
slawekjaranowski commented on a change in pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#discussion_r792699198 ## File path: maven-plugin-plugin/pom.xml ## @@ -270,8 +249,7 @@ org.apache.maven.plugins maven-plugin-plugin -3.6.0 - +3.6.4 Review comment: please also update version for reporting -> m-p-p -- 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-388) Make reporting optional dependency
[
https://issues.apache.org/jira/browse/MPLUGIN-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamás Cservenák updated MPLUGIN-388:
Description:
Current m-p-p is far from being "lightweight", mostly due maven-reporting-impl
being pulled in (that pulls in doxia, http-client and almost whole universe),
and all this due one single mojo, the {{report}} mojo
(org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as when
used as part of site, all these are provided by site plugin.
Make this dependency optional. This implies, that users of this release using
report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
m-p-p plugin as plugin dependency.
was:
Current m-p-p is far from being "lightweight", mostly due maven-reporting-impl
being pulled in (that pulls in doxia, http-client and almost whole universe),
and all this due one single mojo, the {{report}} mojo
(org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as when
used as part of site, all these are provided by site plugin.
Make this dependency optional. This implies, that users of this release MUST
ADD maven-reporting-impl:3.0.0 as dependency to m-p-p plugin as plugin
dependency.
> Make reporting optional dependency
> --
>
> Key: MPLUGIN-388
> URL: https://issues.apache.org/jira/browse/MPLUGIN-388
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: Plugin Plugin
>Reporter: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> Current m-p-p is far from being "lightweight", mostly due
> maven-reporting-impl being pulled in (that pulls in doxia, http-client and
> almost whole universe), and all this due one single mojo, the {{report}} mojo
> (org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
> needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as
> when used as part of site, all these are provided by site plugin.
> Make this dependency optional. This implies, that users of this release using
> report mojo "standalone" MUST ADD maven-reporting-impl:3.0.0 as dependency to
> m-p-p plugin as plugin dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MPLUGIN-388) Make reporting optional dependency
Tamás Cservenák created MPLUGIN-388:
---
Summary: Make reporting optional dependency
Key: MPLUGIN-388
URL: https://issues.apache.org/jira/browse/MPLUGIN-388
Project: Maven Plugin Tools
Issue Type: Task
Components: Plugin Plugin
Reporter: Tamás Cservenák
Fix For: 3.7.0
Current m-p-p is far from being "lightweight", mostly due maven-reporting-impl
being pulled in (that pulls in doxia, http-client and almost whole universe),
and all this due one single mojo, the {{report}} mojo
(org.apache.maven.plugin.plugin.PluginReport), and all these dependencies are
needed ONLY when mojo directly invoked (ie. {{{}mvn m-p-p:report{}}}), as when
used as part of site, all these are provided by site plugin.
Make this dependency optional. This implies, that users of this release MUST
ADD maven-reporting-impl:3.0.0 as dependency to m-p-p plugin as plugin
dependency.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] cstamas edited a comment on pull request #66: Reshuffle plugin dependencies
cstamas edited a comment on pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022232173 > ATTENTION: Reporting plugin cannot have dependencies in the POM. I tripped over it recently. ? No, this is build/plugins/m-p-p plugin is that needs dep added IF you plan to use PluginReport mojo "standalone" (invoke it directly) -- 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] cstamas commented on pull request #66: Reshuffle plugin dependencies
cstamas commented on pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022232173 > ATTENTION: Reporting plugin cannot have dependencies in the POM. I tripped over it recently. ? No, this is build/plugins/m-p-p plugin is that needs dep added IF you plan to use PluginReport mojo "standalone" -- 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] michael-o commented on pull request #66: Reshuffle plugin dependencies
michael-o commented on pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66#issuecomment-1022230827 ATTENTION: Reporting plugin cannot have dependencies in the POM. I tripped over it recently. -- 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] cstamas opened a new pull request #66: Reshuffle plugin dependencies
cstamas opened a new pull request #66: URL: https://github.com/apache/maven-plugin-tools/pull/66 Changes: * use m-p-p 3.6.4 finally, so maven bits can be provided scope * maven-reporting-impl is optional (so in case standalone mojo is used, it needs to be added to plugin dep) * align use of reporting and doxia across modules (there were several versions used) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MPLUGIN-378) Detect legacy/javadoc Mojo definitions, warn to use Java5 annotations
[
https://issues.apache.org/jira/browse/MPLUGIN-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482450#comment-17482450
]
ASF GitHub Bot commented on MPLUGIN-378:
cstamas commented on a change in pull request #46:
URL: https://github.com/apache/maven-plugin-tools/pull/46#discussion_r792603255
##
File path:
maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/extractor/GroupKey.java
##
@@ -0,0 +1,121 @@
+package org.apache.maven.tools.plugin.extractor;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.Objects;
+
+/**
+ * Group key: defines "grouping" for descriptor (based on source of
extraction) and rank within
+ * group.
+ *
+ * @since TBD
+ */
+public final class GroupKey
+implements Comparable
+{
+/**
+ * Java group is handled a bit special: is always first to be scanned.
+ */
+public static final String JAVA_GROUP = "java";
+
+private final String group;
+
+private final int order;
+
+public GroupKey( String group, int order )
+{
+if ( group == null )
+{
+throw new NullPointerException( "GroupKey.group null" );
Review comment:
This is Java7 project, but yes, we may want to up it to Java8 for 3.7.0
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Detect legacy/javadoc Mojo definitions, warn to use Java5 annotations
> -
>
> Key: MPLUGIN-378
> URL: https://issues.apache.org/jira/browse/MPLUGIN-378
> Project: Maven Plugin Tools
> Issue Type: Task
> Components: maven-plugin-tools-javadoc
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
>Priority: Major
> Fix For: 3.7.0
>
>
> In short: deprecate java-javadoc mojo descriptor extractor, as everyone
> should use the newer Java5 annotation based Mojo Annotations instead. Make
> the plugin warn (later fail?) during build if the built sources contain mojo
> definitions defined using javadoc qdox tags.
> This change will have some incompatible on extractor API, hence the 3.7.0
> version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [maven-plugin-tools] cstamas commented on a change in pull request #46: [MPLUGIN-378] Group extractors and improve their selection, deprecate javadoc extractor
cstamas commented on a change in pull request #46:
URL: https://github.com/apache/maven-plugin-tools/pull/46#discussion_r792603255
##
File path:
maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/extractor/GroupKey.java
##
@@ -0,0 +1,121 @@
+package org.apache.maven.tools.plugin.extractor;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.util.Objects;
+
+/**
+ * Group key: defines "grouping" for descriptor (based on source of
extraction) and rank within
+ * group.
+ *
+ * @since TBD
+ */
+public final class GroupKey
+implements Comparable
+{
+/**
+ * Java group is handled a bit special: is always first to be scanned.
+ */
+public static final String JAVA_GROUP = "java";
+
+private final String group;
+
+private final int order;
+
+public GroupKey( String group, int order )
+{
+if ( group == null )
+{
+throw new NullPointerException( "GroupKey.group null" );
Review comment:
This is Java7 project, but yes, we may want to up it to Java8 for 3.7.0
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] imonteroperez commented on pull request #400: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
imonteroperez commented on pull request #400: URL: https://github.com/apache/maven-surefire/pull/400#issuecomment-1022165752 Closed in favor of https://github.com/apache/maven-surefire/pull/440 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] imonteroperez closed pull request #400: [SUREFIRE-1964] Support for method filtering on excludesFile and includesFile
imonteroperez closed pull request #400: URL: https://github.com/apache/maven-surefire/pull/400 -- 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-doxia] dependabot[bot] opened a new pull request #88: Bump xmlunit-core from 2.8.4 to 2.9.0
dependabot[bot] opened a new pull request #88: URL: https://github.com/apache/maven-doxia/pull/88 Bumps [xmlunit-core](https://github.com/xmlunit/xmlunit) from 2.8.4 to 2.9.0. Release notes Sourced from https://github.com/xmlunit/xmlunit/releases;>xmlunit-core's releases. XMLUnit for Java 2.9.0 The major change of XMLUnit for Java 2.9.0 is the addition of a new module xmlunit-jakarta-jaxb-impl that can be used in addition to xmlunit-core when you want to use the Jakarta XML Binding API in version 3. For details please see the https://github.com/xmlunit/user-guide/wiki/JAXB;>user's guide. The full list of changes of XMLUnit for Java 2.9.0 is: added a new module xmlunit-jakarta-jaxb-impl that makes Input.fromJaxb use jakarta.xml.bind rather than javax.xml.bind. For more details see the https://github.com/xmlunit/user-guide/wiki/JAXB;>User's Guide. This change is not fully backwards compatible. The JaxbBuilder class has become abstract and the withMarshaller method has changed its signature. For most cases the change will not be noticed and for almost all other cases it should be enough to re-compile your code against XMLUnit 2.9.x. Issue https://github-redirect.dependabot.com/xmlunit/xmlunit/issues/227;>#227 and PR https://github-redirect.dependabot.com/xmlunit/xmlunit/issues/247;>#247 added NodeFilters#satisfiesAll and satifiesAny methods to make it easier to combine multiple node filters. added to simplify the use case of https://github-redirect.dependabot.com/xmlunit/xmlunit/issues/249;>#249 Changelog Sourced from https://github.com/xmlunit/xmlunit/blob/main/RELEASE_NOTES.md;>xmlunit-core's changelog. XMLUnit for Java 2.9.0 - /Released 2022-01-25/ added a new module xmlunit-jakarta-jaxb-impl that makes Input.fromJaxb use jakarta.xml.bind rather than javax.xml.bind. For more details see the https://github.com/xmlunit/user-guide/wiki/JAXB;>User's Guide. This change is not fully backwards compatible. The JaxbBuilder class has become abstract and the withMarshaller method has changed its signature. For most cases the change will not be noticed and for almost all other cases it should be enough to re-compile your code against XMLUnit 2.9.x. Issue https://github-redirect.dependabot.com/xmlunit/xmlunit/issues/227;>#227 and PR https://github-redirect.dependabot.com/xmlunit/xmlunit/issues/247;>#247 added NodeFilters#satisfiesAll and satifiesAny methods to make it easier to combine multiple node filters. added to simplify the use case of https://github-redirect.dependabot.com/xmlunit/xmlunit/issues/249;>#249 Commits https://github.com/xmlunit/xmlunit/commit/cc4242d06d9dee45abbb5ddaea28d64dd9b0;>cc4242d XMLUnit 2.9.0 https://github.com/xmlunit/xmlunit/commit/e8420e80ed5ff60236d09f2950f5e0c5d8fcc59d;>e8420e8 name profile properly https://github.com/xmlunit/xmlunit/commit/fc9d2cb8e4fe34669bd70c4f0038928b1b2058c4;>fc9d2cb Java9 and 10 seem to require the JAXB RI https://github.com/xmlunit/xmlunit/commit/98444ee320b4cfc7d8615e5638638c50d9b750de;>98444ee I should have known which parameter the shell script expects :-) https://github.com/xmlunit/xmlunit/commit/7638c0787cfcb73514b80d7d13a63e18d5a654c5;>7638c07 trigger Travis CI build https://github.com/xmlunit/xmlunit/commit/4d9a85438bc79c19ecb3348f4505b63de739b5bf;>4d9a854 NodeFilters.satisfyAll and .satisfyAny https://github.com/xmlunit/xmlunit/commit/eb7cc2c042e25273b8901ca425833c04bcdc8f3f;>eb7cc2c explicitly document the withFoo methods are not additive https://github.com/xmlunit/xmlunit/commit/64e55a33c658bc9d902b036f56a2d839fd63fa1d;>64e55a3 JAXB compatibility tests https://github.com/xmlunit/xmlunit/commit/51ee34b6eaeb99cf3668825a6321b501fd64668d;>51ee34b Merge pull request https://github-redirect.dependabot.com/xmlunit/xmlunit/issues/247;>#247 from xmlunit/jakarta-jaxb https://github.com/xmlunit/xmlunit/commit/528ba4f931a143835f540b514aedddee0a350744;>528ba4f document JAXB change Additional commits viewable in https://github.com/xmlunit/xmlunit/compare/v2.8.4...v2.9.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 -
[GitHub] [maven-artifact-transfer] dependabot[bot] opened a new pull request #60: Bump slf4j-api from 1.7.32 to 1.7.35
dependabot[bot] opened a new pull request #60: URL: https://github.com/apache/maven-artifact-transfer/pull/60 Bumps [slf4j-api](https://github.com/qos-ch/slf4j) from 1.7.32 to 1.7.35. Commits https://github.com/qos-ch/slf4j/commit/02860b67ef7ff39fa9c7d98fd00da2ee913faeda;>02860b6 prepare relase 1.7.35 https://github.com/qos-ch/slf4j/commit/a622f5186a57188dab7f71651245eb91c6ac263b;>a622f51 fix maven deploy issues https://github.com/qos-ch/slf4j/commit/26068bd4bf93fcbd00185ad986dc43b79aceeb4a;>26068bd slf4j no longer references log4j https://github.com/qos-ch/slf4j/commit/0a21ee1ac1daa2d8e077bec68815421dd7a7a54a;>0a21ee1 replace references to slf4j-log4j12 https://github.com/qos-ch/slf4j/commit/51b6d20b71de75f69ee68167afbf4073c1be7c31;>51b6d20 prepare release 1.7.34 https://github.com/qos-ch/slf4j/commit/d22943faedd5da8d0321cf60437796fb53618481;>d22943f relocate slf4j-log4j12 as slf4j-reload4j https://github.com/qos-ch/slf4j/commit/19e36ffdca0218797cd23048b6547865e30e1d3a;>19e36ff make VersionUtil more robust https://github.com/qos-ch/slf4j/commit/d32d0535f7274a679c47d3354411476a86f5971a;>d32d053 fix SLF4J-535 https://github.com/qos-ch/slf4j/commit/2b657bf5dc575f32791648fd95260e33aa07687c;>2b657bf start work on 1.7.33-SNAPSHOT https://github.com/qos-ch/slf4j/commit/2758a974264ab65df3af1d473eb9423ca978c14a;>2758a97 prepare release 1.7.33 Additional commits viewable in https://github.com/qos-ch/slf4j/compare/v_1.7.32...v_1.7.35;>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] [Commented] (MPLUGIN-378) Detect legacy/javadoc Mojo definitions, warn to use Java5 annotations
[ https://issues.apache.org/jira/browse/MPLUGIN-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482440#comment-17482440 ] ASF GitHub Bot commented on MPLUGIN-378: cstamas edited a comment on pull request #46: URL: https://github.com/apache/maven-plugin-tools/pull/46#issuecomment-1022150314 > Is there no way to detect `@Deprecated` instead of introducing our own `#isDeprecated()`? You mean to detect is extractor deprecated? If so, then why complicate? I mean, we author extractor API, and we author extractor implementations and we decide which one is deprecated... we could do some fancy classcheck/reflection on injected component instance, that would break in a moment (not that we plan) we switch to AOP Guice, as then we get proxies injected, and so on and so on why not just keep it simple? -- 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 > Detect legacy/javadoc Mojo definitions, warn to use Java5 annotations > - > > Key: MPLUGIN-378 > URL: https://issues.apache.org/jira/browse/MPLUGIN-378 > Project: Maven Plugin Tools > Issue Type: Task > Components: maven-plugin-tools-javadoc >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 3.7.0 > > > In short: deprecate java-javadoc mojo descriptor extractor, as everyone > should use the newer Java5 annotation based Mojo Annotations instead. Make > the plugin warn (later fail?) during build if the built sources contain mojo > definitions defined using javadoc qdox tags. > This change will have some incompatible on extractor API, hence the 3.7.0 > version. -- This message was sent by Atlassian Jira (v8.20.1#820001)
