Re: [PR] [MPOM-440] Add maven-checkstyle-plugin to pluginManagement [maven-apache-parent]
slawekjaranowski commented on code in PR #173:
URL:
https://github.com/apache/maven-apache-parent/pull/173#discussion_r1374144851
##
pom.xml:
##
@@ -181,6 +182,11 @@ under the License.
maven-clean-plugin
${version.maven-clean-plugin}
+
+ org.apache.maven.plugins
+ maven-checkstyle-plugin
+ ${version.maven-checkstyle-plugin}
+
Review Comment:
yes it is true.
But newer checkstyle required JDK 11+, so in this place we can not make such
assumptions.
child project also define specific plugin configurations.
So here only plugin version is reasonable.
--
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] (MRESOLVER-418) Migrate to Junit5
[ https://issues.apache.org/jira/browse/MRESOLVER-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-418: -- Component/s: Resolver > Migrate to Junit5 > - > > Key: MRESOLVER-418 > URL: https://issues.apache.org/jira/browse/MRESOLVER-418 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Migrate from Junit 4 to 5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-391) Scope mediation improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780186#comment-17780186 ] Tamas Cservenak commented on MRESOLVER-391: --- Can someone provide a reproducer here? Ideally as a git repository that could be incorporated as test (UT or whatever)? > Scope mediation improvements > > > Key: MRESOLVER-391 > URL: https://issues.apache.org/jira/browse/MRESOLVER-391 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > As per MNG-5988: if an artifact in "test" scope is found nearer, but in scope > "compile" is found deeper in graph, the "test" scope wins. This at runtime > may lead to CNFEx. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPOM-438] Bump maven-plugin-plugin from 3.9.0 to 3.10.1 [maven-apache-parent]
ctubbsii commented on PR #170: URL: https://github.com/apache/maven-apache-parent/pull/170#issuecomment-1782130970 > this plugin version depends on plexus-xml 4. I didn't understand this comment from @slachiewicz , so I did some digging to see if this was a problem. I see that this plugin has a direct explicit (not provided, runtime, or optional) dependency on `org.apache.maven.plugin-tools:maven-plugin-tools-api:jar:3.10.1`, which has a direct explicit (not provided, runtime, or optional) dependency on `org.codehaus.plexus:plexus-xml:jar:4.0.0`. In the `mvn dependency:tree` for this plugin, I don't see it as a transitive dependency of any other dependencies for this plugin (click to expand): ``` [INFO] --- dependency:3.4.0:tree (default-cli) @ maven-plugin-plugin --- [INFO] org.apache.maven.plugins:maven-plugin-plugin:maven-plugin:3.10.1 [INFO] +- org.apache.maven:maven-core:jar:3.2.5:provided [INFO] | +- org.apache.maven:maven-settings:jar:3.2.5:provided [INFO] | +- org.apache.maven:maven-settings-builder:jar:3.2.5:provided [INFO] | +- org.apache.maven:maven-model-builder:jar:3.2.5:provided [INFO] | +- org.apache.maven:maven-aether-provider:jar:3.2.5:provided [INFO] | | \- org.eclipse.aether:aether-spi:jar:1.0.0.v20140518:provided [INFO] | +- org.eclipse.aether:aether-impl:jar:1.0.0.v20140518:provided [INFO] | +- org.eclipse.aether:aether-api:jar:1.0.0.v20140518:provided [INFO] | +- org.eclipse.aether:aether-util:jar:1.0.0.v20140518:provided [INFO] | +- org.sonatype.sisu:sisu-guice:jar:no_aop:3.2.3:provided [INFO] | | +- javax.inject:javax.inject:jar:1:runtime [INFO] | | +- aopalliance:aopalliance:jar:1.0:provided [INFO] | | \- com.google.guava:guava:jar:16.0.1:provided [INFO] | +- org.codehaus.plexus:plexus-interpolation:jar:1.21:provided [INFO] | +- org.codehaus.plexus:plexus-classworlds:jar:2.5.2:provided [INFO] | +- org.codehaus.plexus:plexus-component-annotations:jar:1.5.5:provided [INFO] | \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:provided [INFO] | \- org.sonatype.plexus:plexus-cipher:jar:1.4:provided [INFO] +- org.apache.maven.plugin-tools:maven-plugin-tools-api:jar:3.10.1:compile [INFO] | +- org.slf4j:slf4j-api:jar:1.7.36:compile [INFO] | +- org.apache.maven.reporting:maven-reporting-api:jar:3.1.1:compile [INFO] | | \- org.apache.maven.doxia:doxia-sink-api:jar:1.11.1:compile [INFO] | | \- org.apache.maven.doxia:doxia-logging-api:jar:1.11.1:compile [INFO] | +- org.codehaus.plexus:plexus-xml:jar:4.0.0:compile [INFO] | | \- org.apache.maven:maven-xml-impl:jar:4.0.0-alpha-5:compile [INFO] | | \- org.apache.maven:maven-api-xml:jar:4.0.0-alpha-5:compile [INFO] | |\- org.apache.maven:maven-api-meta:jar:4.0.0-alpha-5:compile [INFO] | +- org.apache.httpcomponents:httpclient:jar:4.5.14:compile [INFO] | | +- commons-logging:commons-logging:jar:1.2:compile [INFO] | | \- commons-codec:commons-codec:jar:1.11:compile [INFO] | +- org.apache.httpcomponents:httpcore:jar:4.4.16:compile [INFO] | +- org.apache.maven.wagon:wagon-provider-api:jar:2.4:compile [INFO] | \- org.codehaus.plexus:plexus-java:jar:1.1.2:compile [INFO] +- org.apache.maven.plugin-tools:maven-plugin-tools-generators:jar:3.10.1:compile [INFO] | +- org.apache.velocity:velocity:jar:1.7:compile [INFO] | | \- commons-lang:commons-lang:jar:2.4:compile [INFO] | +- org.ow2.asm:asm:jar:9.5:compile [INFO] | +- org.ow2.asm:asm-commons:jar:9.5:compile [INFO] | | \- org.ow2.asm:asm-tree:jar:9.5:compile [INFO] | +- org.jsoup:jsoup:jar:1.16.1:compile [INFO] | \- net.sf.jtidy:jtidy:jar:r938:compile [INFO] +- org.apache.maven.plugin-tools:maven-plugin-tools-java:jar:3.10.1:runtime [INFO] | \- com.thoughtworks.qdox:qdox:jar:2.0.3:compile [INFO] +- org.apache.maven.plugin-tools:maven-plugin-tools-annotations:jar:3.10.1:runtime [INFO] | +- org.codehaus.plexus:plexus-archiver:jar:4.8.0:runtime [INFO] | | +- org.codehaus.plexus:plexus-io:jar:3.4.1:runtime [INFO] | | +- commons-io:commons-io:jar:2.13.0:runtime [INFO] | | +- org.apache.commons:commons-compress:jar:1.23.0:runtime [INFO] | | +- org.iq80.snappy:snappy:jar:0.4:runtime [INFO] | | +- org.tukaani:xz:jar:1.9:runtime [INFO] | | \- com.github.luben:zstd-jni:jar:1.5.5-5:runtime [INFO] | \- org.ow2.asm:asm-util:jar:9.5:runtime [INFO] | \- org.ow2.asm:asm-analysis:jar:9.5:runtime [INFO] +- org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.10.1:compile [INFO] +- org.apache.maven.plugin-tools:maven-plugin-tools-ant:jar:3.10.1:runtime [INFO] | \- org.apache.maven.plugin-tools:maven-plugin-tools-model:jar:3.10.1:runtime [INFO] +- org.apache.maven.plugin-tools:maven-plugin-tools-beanshell:jar:3.10.1:runtime [INFO] | \- org.apache-extras.beanshell:bsh:jar:2.0b6:runtime [INFO] +- org
Re: [PR] [MPOM-440] Add maven-checkstyle-plugin to pluginManagement [maven-apache-parent]
ctubbsii commented on code in PR #173:
URL:
https://github.com/apache/maven-apache-parent/pull/173#discussion_r1373953619
##
pom.xml:
##
@@ -181,6 +182,11 @@ under the License.
maven-clean-plugin
${version.maven-clean-plugin}
+
+ org.apache.maven.plugins
+ maven-checkstyle-plugin
+ ${version.maven-checkstyle-plugin}
+
Review Comment:
The only problem with this is that the maven-checkstyle-plugin often uses a
very old version of checkstyle, so to be useful to users, they still often have
to define the plugin to override the dependency, as in:
```xml
org.apache.maven.plugins
maven-checkstyle-plugin
com.puppycrawl.tools
checkstyle
10.12.2
check-style
check
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7913) Upgrade Sisu version
[ https://issues.apache.org/jira/browse/MNG-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780112#comment-17780112 ] ASF GitHub Bot commented on MNG-7913: - cstamas merged PR #1286: URL: https://github.com/apache/maven/pull/1286 > Upgrade Sisu version > > > Key: MNG-7913 > URL: https://issues.apache.org/jira/browse/MNG-7913 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.6 > > > Recently, as new Java versions are pushed out more aggressively (with Java 21 > out this autumn), seemingly it became normal that users developing Maven > plugins (and components used by those plugins) using bytecode level that is > Java14+. > But alas, Maven 3.9.x line uses Sisu 0.3.5 that is capable to glean bytecode > only up to Java 14. Components having higher version bytecode are silently > skipped by Sisu (no output about this, only at Sisu DEBUG level not emitted > by default). > Hence, it would make sense to up Sisu version to at least 0.9.0.M2 in Maven > 3.9.x as well, that would allow use of JSR330 components using bytecode more > recent that Java 14 is, up to 19. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-7913) Upgrade Sisu version
[ https://issues.apache.org/jira/browse/MNG-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-7913. Resolution: Fixed > Upgrade Sisu version > > > Key: MNG-7913 > URL: https://issues.apache.org/jira/browse/MNG-7913 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.6 > > > Recently, as new Java versions are pushed out more aggressively (with Java 21 > out this autumn), seemingly it became normal that users developing Maven > plugins (and components used by those plugins) using bytecode level that is > Java14+. > But alas, Maven 3.9.x line uses Sisu 0.3.5 that is capable to glean bytecode > only up to Java 14. Components having higher version bytecode are silently > skipped by Sisu (no output about this, only at Sisu DEBUG level not emitted > by default). > Hence, it would make sense to up Sisu version to at least 0.9.0.M2 in Maven > 3.9.x as well, that would allow use of JSR330 components using bytecode more > recent that Java 14 is, up to 19. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7913) Upgrade Sisu version
[ https://issues.apache.org/jira/browse/MNG-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-7913: Assignee: Tamas Cservenak > Upgrade Sisu version > > > Key: MNG-7913 > URL: https://issues.apache.org/jira/browse/MNG-7913 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.6 > > > Recently, as new Java versions are pushed out more aggressively (with Java 21 > out this autumn), seemingly it became normal that users developing Maven > plugins (and components used by those plugins) using bytecode level that is > Java14+. > But alas, Maven 3.9.x line uses Sisu 0.3.5 that is capable to glean bytecode > only up to Java 14. Components having higher version bytecode are silently > skipped by Sisu (no output about this, only at Sisu DEBUG level not emitted > by default). > Hence, it would make sense to up Sisu version to at least 0.9.0.M2 in Maven > 3.9.x as well, that would allow use of JSR330 components using bytecode more > recent that Java 14 is, up to 19. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [3.9.x] [MNG-7913] Upgrade Sisu version [maven]
cstamas merged PR #1286: URL: https://github.com/apache/maven/pull/1286 -- 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] (MNG-7913) Upgrade Sisu version
[ https://issues.apache.org/jira/browse/MNG-7913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7913: - Description: Recently, as new Java versions are pushed out more aggressively (with Java 21 out this autumn), seemingly it became normal that users developing Maven plugins (and components used by those plugins) using bytecode level that is Java14+. But alas, Maven 3.9.x line uses Sisu 0.3.5 that is capable to glean bytecode only up to Java 14. Components having higher version bytecode are silently skipped by Sisu (no output about this, only at Sisu DEBUG level not emitted by default). Hence, it would make sense to up Sisu version to at least 0.9.0.M2 in Maven 3.9.x as well, that would allow use of JSR330 components using bytecode more recent that Java 14 is, up to 19. was: Recently, as new Java versions are pushed out more aggressively (with Java 21 out this autumn), seemingly it became normal that users developing Maven plugins (and components used by those plugins) using bytecode level that is Java14+. But alas, Maven 3.9.x line uses Sisu 0.3.5 that is capable to glean bytecode only up to Java 14. Components having higher version bytecode are silently skipped by Sisu (no output about this, only at Sisu DEBUG level not emitted by default). Hence, it would make sense to up Sisu version to at least 0.9.0.M2 in Maven 3.9.x as well, that would allow use of JSR330 components using bytecode more recent that Java 14 is. > Upgrade Sisu version > > > Key: MNG-7913 > URL: https://issues.apache.org/jira/browse/MNG-7913 > Project: Maven > Issue Type: Improvement > Components: Core >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.6 > > > Recently, as new Java versions are pushed out more aggressively (with Java 21 > out this autumn), seemingly it became normal that users developing Maven > plugins (and components used by those plugins) using bytecode level that is > Java14+. > But alas, Maven 3.9.x line uses Sisu 0.3.5 that is capable to glean bytecode > only up to Java 14. Components having higher version bytecode are silently > skipped by Sisu (no output about this, only at Sisu DEBUG level not emitted > by default). > Hence, it would make sense to up Sisu version to at least 0.9.0.M2 in Maven > 3.9.x as well, that would allow use of JSR330 components using bytecode more > recent that Java 14 is, up to 19. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPOM-438] Bump maven-plugin-plugin from 3.9.0 to 3.10.1 [maven-apache-parent]
slachiewicz commented on PR #170: URL: https://github.com/apache/maven-apache-parent/pull/170#issuecomment-1781944185 this plugin version depends on plexus-xml 4. -- 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] (MCHECKSTYLE-442) Not possible to specify useful ignoreStringsRegexp property for module name MultipleStringLiterals without error
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated MCHECKSTYLE-442:
--
Description:
The [checkstyle
documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
specifies this example for ignoring certain strings by regex in module
{{MultipleStringLiterals}}.
{code:xml}
{code}
Not only does this example not work, but *no* useful value for this property
works. Any regex that contains a double quote ("), which is required for this
property to work, results in an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
(checkstyle-verify-style) on project oss-parent:
Failed during checkstyle execution:
Failed during checkstyle configuration:
unable to parse configuration stream - Element type "property" must be followed
by either attribute specifications, ">" or "/>".:94:85 -> [Help 1]
{noformat}
In addition to trying their example verbatim, I have tried all of the
following, all of which result in the same error. I cannot find a workaround,
so I am unable to use this property.
{code:xml}
{code}
The parentheses and other symbols do not appear to be a problem, because the
following do not result in any errors, they're just also not useful because
checkstyle won't match on them:
{code:xml}
{code}
So it would seem that it's not possible to use legal XML techniques to insert
double quotes into property values.
was:
The [checkstyle
documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
specifies this example for ignoring certain strings by regex in module
{{MultipleStringLiterals}}.
{code:xml}
{code}
Not only does this example not work, but *no* useful value for this property
works. Any regex that contains a double quote ("), which is required for this
property to work, results in an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
(checkstyle-verify-style) on project oss-parent:
Failed during checkstyle execution:
Failed during checkstyle configuration:
unable to parse configuration stream - Element type "property" must be followed
by either attribute specifications, ">" or "/>".:94:85 -> [Help 1]
{noformat}
In addition to trying their example verbatim, I have tried all of the
following, all of which result in the same error. I cannot find a workaround,
so I am unable to use this property.
{code:xml}
{code}
The parentheses and other symbols do not appear to be a problem, because the
following do not result in any errors, they're just also not useful because
checkstyle won't match on them:
{code:xml}
{code}
So it would seem that it's not possible to use legal XML techniques to insert
double quotes into property values.
> Not possible to specify useful ignoreStringsRegexp property for module name
> MultipleStringLiterals without error
>
>
> Key: MCHECKSTYLE-442
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-442
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Reporter: Nick Williams
>Priority: Major
>
> The [checkstyle
> documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
> specifies this example for ignoring certain strings by regex in module
> {{MultipleStringLiterals}}.
> {code:xml}
>
>value='^(("")|(", "))$'/>
>
> {code}
> Not only does this example not work, but *no* useful value for this property
> works. Any regex that contains a double quote ("), which is required for this
> property to work, results in an error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
> (checkstyle-verify-style) on project oss-parent:
> Failed during checkstyle execution:
> Failed during checkstyle configuration:
> unable to parse configuration stream - Element type "property" must be
> followed by either attribute specifications, ">" or "/>".:94:85 -> [Help 1]
> {noformat}
> In addition to trying their example verbatim, I have tried all of the
> following, all of which result in the same error. I cannot find a workaround,
> so I am unable to use this property.
> {code:xml}
>value='^""$' />
>value="^""$" />
>value='^""$' />
>value="^(("")|(", "))$" />
>val
[jira] [Commented] (MNG-7920) Usage of packaging BOM fails in maven-install-plugin
[
https://issues.apache.org/jira/browse/MNG-7920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780099#comment-17780099
]
Slawomir Jaranowski commented on MNG-7920:
--
m-install-p should recognize bom packaging as pom and not require main artifact
The same will be for m-deploy-p
> Usage of packaging BOM fails in maven-install-plugin
>
>
> Key: MNG-7920
> URL: https://issues.apache.org/jira/browse/MNG-7920
> Project: Maven
> Issue Type: Bug
> Components: Deployment
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Critical
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Using to use the `bom` packaging in a module it will fail with:
> {code}
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project bom: The packaging plugin for this project did not assign a main
> file to the project but it has attachments. Change packaging to 'pom'. ->
> [Help 1]
> {code}
> The bom module looks like this:
> {code:xml}
>xmlns="http://maven.apache.org/POM/4.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
> http://maven.apache.org/maven-v4_1_0.xsd";>
> 4.1.0
>
> maven4
> bom-example
>
> bom
> bom
>
>
>
> ...maven4
> mod-1
>
>
> maven4
> mod-2
>
>
>
>
> {code}
> I would assume that I need to upgrade the maven-install-plugin which is
> capable of handling that...but I assumed that this conversion is done by core?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MCHECKSTYLE-442) Not possible to specify useful ignoreStringsRegexp property for module name MultipleStringLiterals without error
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated MCHECKSTYLE-442:
--
Description:
The [checkstyle
documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
specifies this example for ignoring certain strings by regex in module
{{MultipleStringLiterals}}.
{code:xml}
{code}
Not only does this example not work, but *no* useful value for this property
works. Any regex that contains a double quote ("), which is required for this
property to work, results in an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
(checkstyle-verify-style) on project oss-parent:
Failed during checkstyle execution:
Failed during checkstyle configuration: unable to parse configuration stream -
Element type "property" must be followed by either attribute specifications,
">" or "/>".:94:85 -> [Help 1]
{noformat}
In addition to trying their example verbatim, I have tried all of the
following, all of which result in the same error. I cannot find a workaround,
so I am unable to use this property.
{code:xml}
{code}
The parentheses and other symbols do not appear to be a problem, because the
following do not result in any errors, they're just also not useful because
checkstyle won't match on them:
{code:xml}
{code}
So it would seem that it's not possible to use legal XML techniques to insert
double quotes into property values.
was:
The [checkstyle
documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
specifies this example for ignoring certain strings by regex in module
{{MultipleStringLiterals}}.
{code:xml}
{code}
Not only does this example not work, but *no* useful value for this property
works. Any regex that contains a double quote ("), which is required for this
property to work, results in an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
(checkstyle-verify-style) on project oss-parent: Failed during checkstyle
execution: Failed during checkstyle configuration: unable to parse
configuration stream - Element type "property" must be followed by either
attribute specifications, ">" or "/>".:94:85 -> [Help 1]
{noformat}
In addition to trying their example verbatim, I have tried all of the
following, all of which result in the same error. I cannot find a workaround,
so I am unable to use this property.
{code:xml}
{code}
The parentheses and other symbols do not appear to be a problem, because the
following do not result in any errors, they're just also not useful because
checkstyle won't match on them:
{code:xml}
{code}
So it would seem that it's not possible to use legal XML techniques to insert
double quotes into property values.
> Not possible to specify useful ignoreStringsRegexp property for module name
> MultipleStringLiterals without error
>
>
> Key: MCHECKSTYLE-442
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-442
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Reporter: Nick Williams
>Priority: Major
>
> The [checkstyle
> documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
> specifies this example for ignoring certain strings by regex in module
> {{MultipleStringLiterals}}.
> {code:xml}
>
>value='^(("")|(", "))$'/>
>
> {code}
> Not only does this example not work, but *no* useful value for this property
> works. Any regex that contains a double quote ("), which is required for this
> property to work, results in an error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
> (checkstyle-verify-style) on project oss-parent:
> Failed during checkstyle execution:
> Failed during checkstyle configuration: unable to parse configuration stream
> - Element type "property" must be followed by either attribute
> specifications, ">" or "/>".:94:85 -> [Help 1]
> {noformat}
> In addition to trying their example verbatim, I have tried all of the
> following, all of which result in the same error. I cannot find a workaround,
> so I am unable to use this property.
> {code:xml}
>value='^""$' />
>value="^""$" />
>value='^(("")|(", "))$' />
>value='^("")|(", ")$' />
> {code}
> The parentheses and other symbols do not a
[jira] [Updated] (MCHECKSTYLE-442) Not possible to specify useful ignoreStringsRegexp property for module name MultipleStringLiterals without error
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated MCHECKSTYLE-442:
--
Description:
The [checkstyle
documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
specifies this example for ignoring certain strings by regex in module
{{MultipleStringLiterals}}.
{code:xml}
{code}
Not only does this example not work, but *no* useful value for this property
works. Any regex that contains a double quote ("), which is required for this
property to work, results in an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
(checkstyle-verify-style) on project oss-parent:
Failed during checkstyle execution:
Failed during checkstyle configuration:
unable to parse configuration stream - Element type "property" must be followed
by either attribute specifications, ">" or "/>".:94:85 -> [Help 1]
{noformat}
In addition to trying their example verbatim, I have tried all of the
following, all of which result in the same error. I cannot find a workaround,
so I am unable to use this property.
{code:xml}
{code}
The parentheses and other symbols do not appear to be a problem, because the
following do not result in any errors, they're just also not useful because
checkstyle won't match on them:
{code:xml}
{code}
So it would seem that it's not possible to use legal XML techniques to insert
double quotes into property values.
was:
The [checkstyle
documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
specifies this example for ignoring certain strings by regex in module
{{MultipleStringLiterals}}.
{code:xml}
{code}
Not only does this example not work, but *no* useful value for this property
works. Any regex that contains a double quote ("), which is required for this
property to work, results in an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
(checkstyle-verify-style) on project oss-parent:
Failed during checkstyle execution:
Failed during checkstyle configuration: unable to parse configuration stream -
Element type "property" must be followed by either attribute specifications,
">" or "/>".:94:85 -> [Help 1]
{noformat}
In addition to trying their example verbatim, I have tried all of the
following, all of which result in the same error. I cannot find a workaround,
so I am unable to use this property.
{code:xml}
{code}
The parentheses and other symbols do not appear to be a problem, because the
following do not result in any errors, they're just also not useful because
checkstyle won't match on them:
{code:xml}
{code}
So it would seem that it's not possible to use legal XML techniques to insert
double quotes into property values.
> Not possible to specify useful ignoreStringsRegexp property for module name
> MultipleStringLiterals without error
>
>
> Key: MCHECKSTYLE-442
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-442
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Reporter: Nick Williams
>Priority: Major
>
> The [checkstyle
> documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
> specifies this example for ignoring certain strings by regex in module
> {{MultipleStringLiterals}}.
> {code:xml}
>
>value='^(("")|(", "))$'/>
>
> {code}
> Not only does this example not work, but *no* useful value for this property
> works. Any regex that contains a double quote ("), which is required for this
> property to work, results in an error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
> (checkstyle-verify-style) on project oss-parent:
> Failed during checkstyle execution:
> Failed during checkstyle configuration:
> unable to parse configuration stream - Element type "property" must be
> followed by either attribute specifications, ">" or "/>".:94:85 -> [Help 1]
> {noformat}
> In addition to trying their example verbatim, I have tried all of the
> following, all of which result in the same error. I cannot find a workaround,
> so I am unable to use this property.
> {code:xml}
>value='^""$' />
>value="^""$" />
>value='^(("")|(", "))$' />
>value='^("")|(", ")$' />
> {code}
> The parentheses and other symbols do not a
[jira] [Updated] (MCHECKSTYLE-442) Not possible to specify useful ignoreStringsRegexp property for module name MultipleStringLiterals without error
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated MCHECKSTYLE-442:
--
Summary: Not possible to specify useful ignoreStringsRegexp property for
module name MultipleStringLiterals without error (was: Not possible to specify
ignoreStringsRegexp property for module name MultipleStringLiterals)
> Not possible to specify useful ignoreStringsRegexp property for module name
> MultipleStringLiterals without error
>
>
> Key: MCHECKSTYLE-442
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-442
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
> Components: checkstyle:check
>Reporter: Nick Williams
>Priority: Major
>
> The [checkstyle
> documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
> specifies this example for ignoring certain strings by regex in module
> {{MultipleStringLiterals}}.
> {code:xml}
>
>value='^(("")|(", "))$'/>
>
> {code}
> Not only does this example not work, but *no* useful value for this property
> works. Any regex that contains a double quote ("), which is required for this
> property to work, results in an error:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
> (checkstyle-verify-style) on project oss-parent: Failed during checkstyle
> execution: Failed during checkstyle configuration: unable to parse
> configuration stream - Element type "property" must be followed by either
> attribute specifications, ">" or "/>".:94:85 -> [Help 1]
> {noformat}
> In addition to trying their example verbatim, I have tried all of the
> following, all of which result in the same error. I cannot find a workaround,
> so I am unable to use this property.
> {code:xml}
>value='^""$' />
>value="^""$" />
>value='^(("")|(", "))$' />
>value='^("")|(", ")$' />
> {code}
> The parentheses and other symbols do not appear to be a problem, because the
> following do not result in any errors, they're just also not useful because
> checkstyle won't match on them:
> {code:xml}
>value='^$' />
>value='^()$' />
> {code}
> So it would seem that it's not possible to use legal XML techniques to insert
> double quotes into property values.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MCHECKSTYLE-442) Not possible to specify ignoreStringsRegexp property for module name MultipleStringLiterals
Nick Williams created MCHECKSTYLE-442:
-
Summary: Not possible to specify ignoreStringsRegexp property for
module name MultipleStringLiterals
Key: MCHECKSTYLE-442
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-442
Project: Maven Checkstyle Plugin
Issue Type: Bug
Components: checkstyle:check
Reporter: Nick Williams
The [checkstyle
documentation|https://checkstyle.sourceforge.io/checks/coding/multiplestringliterals.html]
specifies this example for ignoring certain strings by regex in module
{{MultipleStringLiterals}}.
{code:xml}
{code}
Not only does this example not work, but *no* useful value for this property
works. Any regex that contains a double quote ("), which is required for this
property to work, results in an error:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:3.3.0:check
(checkstyle-verify-style) on project oss-parent: Failed during checkstyle
execution: Failed during checkstyle configuration: unable to parse
configuration stream - Element type "property" must be followed by either
attribute specifications, ">" or "/>".:94:85 -> [Help 1]
{noformat}
In addition to trying their example verbatim, I have tried all of the
following, all of which result in the same error. I cannot find a workaround,
so I am unable to use this property.
{code:xml}
{code}
The parentheses and other symbols do not appear to be a problem, because the
following do not result in any errors, they're just also not useful because
checkstyle won't match on them:
{code:xml}
{code}
So it would seem that it's not possible to use legal XML techniques to insert
double quotes into property values.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7905) Link to security issue reporting information
[
https://issues.apache.org/jira/browse/MNG-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780098#comment-17780098
]
Karl Heinz Marbaise commented on MNG-7905:
--
Unfortunately this would require a change of the {{pom.xml}} format which is
used in central repository and it's consumed by a large number of tools, IDE's
etc. That would be breaking change...
The {{pom}} contains a project url where the project could put such a link.
Those informations are already shown on central can seen here:
https://central.sonatype.com/artifact/org.apache.maven.plugins/maven-surefire-plugin/overview
> Link to security issue reporting information
>
>
> Key: MNG-7905
> URL: https://issues.apache.org/jira/browse/MNG-7905
> Project: Maven
> Issue Type: Wish
> Components: Core
>Reporter: Arnout Engelen
>Priority: Minor
>
> The pom.xml already has a place where a project can describe how to report
> issues to the project ('issueManagement'). It might be nice to also provide a
> place to describe how to report security issues to the project, as that might
> be different from regular issues?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MPOM-440] Add maven-checkstyle-plugin to pluginManagement [maven-apache-parent]
slawekjaranowski opened a new pull request, #173: URL: https://github.com/apache/maven-apache-parent/pull/173 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MPOM-440) Add maven-checkstyle-plugin to pluginManagement
Slawomir Jaranowski created MPOM-440: Summary: Add maven-checkstyle-plugin to pluginManagement Key: MPOM-440 URL: https://issues.apache.org/jira/browse/MPOM-440 Project: Maven POMs Issue Type: New Feature Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-31 Looks like maven-checkstyle-plugin is widely used in ASF project ... https://github.com/search?q=org%3Aapache+maven-checkstyle-plugin+language%3A%22Maven+POM%22&type=code&l=Maven+POM So we can manage version in one place. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPOM-399) Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
[
https://issues.apache.org/jira/browse/MPOM-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MPOM-399:
-
Fix Version/s: ASF-31
> Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
> ---
>
> Key: MPOM-399
> URL: https://issues.apache.org/jira/browse/MPOM-399
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: ASF-31
>
>
> Current is {{3.2.5}}
> {{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
>
> Rationale:
> - early build fail with proper message - not when newer plugin used
> - 3.6.3 minimum version widly used on Mavne CI and in other ASF project
> - other than Maven plugins - all ASF project should use one of the newest
> version of Maven
> - in special case property {{minimalMavenBuildVersion}} can be overridden
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MPOM-399] Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins [maven-apache-parent]
slawekjaranowski opened a new pull request, #172: URL: https://github.com/apache/maven-apache-parent/pull/172 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MPOM-399) Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
[
https://issues.apache.org/jira/browse/MPOM-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MPOM-399:
-
Description:
Current is {{3.2.5}}
{{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
Rationale:
- early build fail with proper message - not when newer plugin used
- 3.6.3 minimum version widly used on Mavne CI and in other ASF project
- other than Maven plugins - all ASF project should use one of the newest
version of Maven
- in special case property {{minimalMavenBuildVersion}} can be overridden
was:
Current is {{3.2.5}}
{{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
Rationale:
- early build fail with proper message - not when newer plugin used
- 3.6.3 minimum version widly used on Mavne CI and in other ASF project
- other than Maven plugins - all ASF project should use one of the newest
version of Maven
> Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
> ---
>
> Key: MPOM-399
> URL: https://issues.apache.org/jira/browse/MPOM-399
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> Current is {{3.2.5}}
> {{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
>
> Rationale:
> - early build fail with proper message - not when newer plugin used
> - 3.6.3 minimum version widly used on Mavne CI and in other ASF project
> - other than Maven plugins - all ASF project should use one of the newest
> version of Maven
> - in special case property {{minimalMavenBuildVersion}} can be overridden
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MPOM-399) Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
[
https://issues.apache.org/jira/browse/MPOM-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned MPOM-399:
Assignee: Slawomir Jaranowski
> Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
> ---
>
> Key: MPOM-399
> URL: https://issues.apache.org/jira/browse/MPOM-399
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> Current is {{3.2.5}}
> {{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
>
> Rationale:
> - early build fail with proper message - not when newer plugin used
> - 3.6.3 minimum version widly used on Mavne CI and in other ASF project
> - other than Maven plugins - all ASF project should use one of the newest
> version of Maven
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPOM-399) Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
[
https://issues.apache.org/jira/browse/MPOM-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MPOM-399:
-
Description:
Current is {{3.2.5}}
{{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
Rationale:
- early build fail with proper message - not when newer plugin used
- 3.6.3 minimum version widly used on Mavne CI and in other ASF project
- other than Maven plugins - all ASF project should use one of the newest
version of Maven
was:
Current is {{3.2.5}}
{{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
> Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
> ---
>
> Key: MPOM-399
> URL: https://issues.apache.org/jira/browse/MPOM-399
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Current is {{3.2.5}}
> {{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
>
> Rationale:
> - early build fail with proper message - not when newer plugin used
> - 3.6.3 minimum version widly used on Mavne CI and in other ASF project
> - other than Maven plugins - all ASF project should use one of the newest
> version of Maven
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPOM-399) Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
[
https://issues.apache.org/jira/browse/MPOM-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated MPOM-399:
-
Summary: Set minimalMavenBuildVersion to 3.6.3 - the minimum used by
plugins (was: Set minimalMavenBuildVersion to the minimum used by plugins)
> Set minimalMavenBuildVersion to 3.6.3 - the minimum used by plugins
> ---
>
> Key: MPOM-399
> URL: https://issues.apache.org/jira/browse/MPOM-399
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> Current is {{3.2.5}}
> {{maven-help-plugin}} - {{3.4.0}} requires {{3.6.3}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MPOM-439] Bump maven-surefire from 3.1.2 to 3.2.1 [maven-apache-parent]
slawekjaranowski opened a new pull request, #171: URL: https://github.com/apache/maven-apache-parent/pull/171 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MPOM-439) Bump maven-surefire from 3.1.2 to 3.2.1
Slawomir Jaranowski created MPOM-439: Summary: Bump maven-surefire from 3.1.2 to 3.2.1 Key: MPOM-439 URL: https://issues.apache.org/jira/browse/MPOM-439 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-31 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MPOM-438] Bump maven-plugin-plugin from 3.9.0 to 3.10.1 [maven-apache-parent]
slawekjaranowski opened a new pull request, #170: URL: https://github.com/apache/maven-apache-parent/pull/170 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MPOM-438) Bump maven-plugin-plugin from 3.9.0 to 3.10.1
Slawomir Jaranowski created MPOM-438: Summary: Bump maven-plugin-plugin from 3.9.0 to 3.10.1 Key: MPOM-438 URL: https://issues.apache.org/jira/browse/MPOM-438 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-31 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MPOM-437] Bump maven-dependency-plugin from 3.6.0 to 3.6.1 [maven-apache-parent]
slawekjaranowski opened a new pull request, #169: URL: https://github.com/apache/maven-apache-parent/pull/169 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MPOM-437) Bump maven-dependency-plugin from 3.6.0 to 3.6.1
Slawomir Jaranowski created MPOM-437: Summary: Bump maven-dependency-plugin from 3.6.0 to 3.6.1 Key: MPOM-437 URL: https://issues.apache.org/jira/browse/MPOM-437 Project: Maven POMs Issue Type: Dependency upgrade Components: asf Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: ASF-31 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MPOM-431) Bump maven-clean-plugin from 3.2.0 to 3.3.2
[ https://issues.apache.org/jira/browse/MPOM-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski updated MPOM-431: - Summary: Bump maven-clean-plugin from 3.2.0 to 3.3.2 (was: Bump maven-clean-plugin from 3.2.0 to 3.3.1) > Bump maven-clean-plugin from 3.2.0 to 3.3.2 > > > Key: MPOM-431 > URL: https://issues.apache.org/jira/browse/MPOM-431 > Project: Maven POMs > Issue Type: Dependency upgrade > Components: asf >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: ASF-31 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-493) Provide a more meaningful hint after deprecation of goal display-info
[
https://issues.apache.org/jira/browse/MENFORCER-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17780048#comment-17780048
]
Philipp Ottlinger commented on MENFORCER-493:
-
A workaround for me would be if the version task can be added to the
defaultGoal -
is something like that possible?
{{--v clean install}}
does not work.
> Provide a more meaningful hint after deprecation of goal display-info
> -
>
> Key: MENFORCER-493
> URL: https://issues.apache.org/jira/browse/MENFORCER-493
> Project: Maven Enforcer Plugin
> Issue Type: Wish
>Affects Versions: 3.4.1
>Reporter: Philipp Ottlinger
>Priority: Major
>
> After upgrading to 3.4.1 I see many warnings in my builds
> {{[WARNING] Goal 'display-info' is deprecated: please use mvn --version}}
> as I use
> {{enforcer:display-info}}
> as part of my defaultGoal definition.
>
> I do know mvn --version but I'm not sure how to integrate it into my build as
> I did with display-info as part of my defaultGoal. Adding a new build step to
> all my projects seems a rather cumbersome way of deprecating this
> functionality.
>
> Is there a better way to get these build informations into my build logs? If
> so, I'd love to see this instead of a build warning.
>
> Thanks
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MDOCCK-38) check System Requirements History configuration
[ https://issues.apache.org/jira/browse/MDOCCK-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MDOCCK-38. - Resolution: Won't Fix > check System Requirements History configuration > --- > > Key: MDOCCK-38 > URL: https://issues.apache.org/jira/browse/MDOCCK-38 > Project: Maven Documentation Checker Plugin (RETIRED) > Issue Type: New Feature >Affects Versions: 1.1 >Reporter: Herve Boutemy >Priority: Major > > feature added in MPLUGIN-400 that requires to be used -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MDOCCK-37) Update parent pom to 39
[ https://issues.apache.org/jira/browse/MDOCCK-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slawomir Jaranowski closed MDOCCK-37. - Resolution: Won't Fix > Update parent pom to 39 > --- > > Key: MDOCCK-37 > URL: https://issues.apache.org/jira/browse/MDOCCK-37 > Project: Maven Documentation Checker Plugin (RETIRED) > Issue Type: Dependency upgrade >Reporter: Elliotte Rusty Harold >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (ARCHETYPE-652) document requirement history
[ https://issues.apache.org/jira/browse/ARCHETYPE-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779887#comment-17779887 ] ASF GitHub Bot commented on ARCHETYPE-652: -- BrowneMonke opened a new pull request, #158: URL: https://github.com/apache/maven-archetype/pull/158 1. Added info not visible on website 2. Required java version not found for some archetype versions > document requirement history > > > Key: ARCHETYPE-652 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-652 > Project: Maven Archetype > Issue Type: Task >Affects Versions: 3.2.1 >Reporter: Herve Boutemy >Priority: Major > Fix For: 3.3.0 > > > required by upgrade to Java 8: people ned to know how to keep a Java 7 > compatible plugin previous release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [ARCHETYPE-652] Added system requirements history [maven-archetype]
BrowneMonke opened a new pull request, #158: URL: https://github.com/apache/maven-archetype/pull/158 1. Added info not visible on website 2. Required java version not found for some archetype versions -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-832) Remove commons-collections-4
[
https://issues.apache.org/jira/browse/MDEP-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779862#comment-17779862
]
ASF GitHub Bot commented on MDEP-832:
-
elharo commented on PR #255:
URL:
https://github.com/apache/maven-dependency-plugin/pull/255#issuecomment-1780955284
There were a number of pom changes in flight so it looks like some of the
PRs got a little mixed up when resolving merge conflicts, but I think it is
removed at HEAD.
> Remove commons-collections-4
>
>
> Key: MDEP-832
> URL: https://issues.apache.org/jira/browse/MDEP-832
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.1
>
>
> Remove the dependency:
> {code:xml}
>
> org.apache.commons
> commons-collections4
> 4.2
>
> {code}
> which is used only for a single method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MDEP-832] - Remove commons-collections-4 [maven-dependency-plugin]
elharo commented on PR #255: URL: https://github.com/apache/maven-dependency-plugin/pull/255#issuecomment-1780955284 There were a number of pom changes in flight so it looks like some of the PRs got a little mixed up when resolving merge conflicts, but I think it is removed at HEAD. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7919) Missing .mvn directory is only reported in DEBUG mode
[
https://issues.apache.org/jira/browse/MNG-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779854#comment-17779854
]
Maarten Mulders commented on MNG-7919:
--
Agreed. I think it makes sense to log this at INFO level.
> Missing .mvn directory is only reported in DEBUG mode
> -
>
> Key: MNG-7919
> URL: https://issues.apache.org/jira/browse/MNG-7919
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Currently the alpha-8 version of Maven only reports the missing {{.mvn}}
> directory only if I activate the debugging output:
> {code}
> [DEBUG] Unable to find the root directory. Create a .mvn directory in the
> root directory or add the root="true" attribute on the root project's model
> to identify it.
> Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
> Maven home: /Users/khm/tools/maven
> Java version: 22-ea, vendor: Oracle Corporation, runtime:
> /Users/khm/.sdkman/candidates/java/22.ea.20-open
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
> {code}
> None debug output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> --
> [INFO] Reactor Build Order:
> ...
> {code}
> The question is: Should it be reported in usual output or not? Or only in
> debug mode? I would say report it not only in DEBUG mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7919) Missing .mvn directory is only reported in DEBUG mode
[
https://issues.apache.org/jira/browse/MNG-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7919:
-
Labels: up-for-grabs (was: )
> Missing .mvn directory is only reported in DEBUG mode
> -
>
> Key: MNG-7919
> URL: https://issues.apache.org/jira/browse/MNG-7919
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Currently the alpha-8 version of Maven only reports the missing {{.mvn}}
> directory only if I activate the debugging output:
> {code}
> [DEBUG] Unable to find the root directory. Create a .mvn directory in the
> root directory or add the root="true" attribute on the root project's model
> to identify it.
> Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
> Maven home: /Users/khm/tools/maven
> Java version: 22-ea, vendor: Oracle Corporation, runtime:
> /Users/khm/.sdkman/candidates/java/22.ea.20-open
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
> {code}
> None debug output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> --
> [INFO] Reactor Build Order:
> ...
> {code}
> The question is: Should it be reported in usual output or not? Or only in
> debug mode? I would say report it not only in DEBUG mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MINDEXER-205) Align Search API backend factories
[ https://issues.apache.org/jira/browse/MINDEXER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINDEXER-205. Assignee: Tamas Cservenak Resolution: Fixed > Align Search API backend factories > -- > > Key: MINDEXER-205 > URL: https://issues.apache.org/jira/browse/MINDEXER-205 > Project: Maven Indexer > Issue Type: Task >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 7.1.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINDEXER-205) Align Search API backend factories
[ https://issues.apache.org/jira/browse/MINDEXER-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779846#comment-17779846 ] ASF GitHub Bot commented on MINDEXER-205: - cstamas merged PR #334: URL: https://github.com/apache/maven-indexer/pull/334 > Align Search API backend factories > -- > > Key: MINDEXER-205 > URL: https://issues.apache.org/jira/browse/MINDEXER-205 > Project: Maven Indexer > Issue Type: Task >Reporter: Tamas Cservenak >Priority: Major > Fix For: 7.1.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MINDEXER-205] Align Search API backend factories [maven-indexer]
cstamas merged PR #334: URL: https://github.com/apache/maven-indexer/pull/334 -- 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-1327) Change output directory default in AbstractMavenReport
[
https://issues.apache.org/jira/browse/MSHARED-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779819#comment-17779819
]
ASF GitHub Bot commented on MSHARED-1327:
-
michael-o commented on code in PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#discussion_r1372885052
##
src/main/java/org/apache/maven/reporting/AbstractMavenReport.java:
##
@@ -74,11 +74,16 @@
*/
public abstract class AbstractMavenReport extends AbstractMojo implements
MavenMultiPageReport {
/**
- * The output directory for the report. Note that this parameter is only
evaluated if the goal is run directly from
- * the command line. If the goal is run indirectly as part of a site
generation, the output directory configured in
- * the Maven Site Plugin is used instead.
+ * The output base directory for the report. Note that this parameter is
only evaluated if the goal is run directly
+ * from the command line. If the goal is run indirectly as part of a site
generation, the output base directory
+ * configured in the https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#outputDirectory";>
+ * Maven Site Plugin is used instead.
+ *
+ * To the respective base directory for each use case (direct mojo call
vs.site generation), implementing plugins
+ * might want to add their specific subdirectories for multi-page reports,
either using a hard-coded name or,
+ * ideally, an additional user-defined mojo parameter with a default value.
Review Comment:
I will try to provide/merge something for both next weekend.
> Change output directory default in AbstractMavenReport
> --
>
> Key: MSHARED-1327
> URL: https://issues.apache.org/jira/browse/MSHARED-1327
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-reporting-impl
>Affects Versions: maven-reporting-impl-4.0.0-M11
>Reporter: Alexander Kriegisch
>Assignee: Michael Osipov
>Priority: Major
> Fix For: maven-reporting-impl-4.0.0-M12
>
>
> The output directory should default to {{${project.build.directory}}} instead
> of {{${project.reporting.outputDirectory}}}. Quoting my reasoning from
> https://github.com/apache/maven-jxr/commit/ae81a34ac616bf7e4ea4fa9d4eb09f0979eaccb1#commitcomment-130639906:
> {quote}
> (...) because the latter is simply wrong IMO. For stand-alone mojo execution,
> a plugin should not mess with Maven Site's default directory. Imagine a
> situation in which each module should get its own, self-consistent report
> when called stand-alone, but the site should contain an aggregate with a
> different structure or maybe no report from that plugin at all. The default
> would then pollute the site directory. This is why on the ML I asked you
> ([~michaelo]), if overriding a {{@Parameter}} annotation on a base class
> field by another {{@Parameter}} annotation on a setter in a subclass it is
> the right or canonical way to implement such a default override.
> BTW, like I also said before, Maven Javadoc Plugin, even though it does not
> use the abstract base class, implements the default correctly: build dir for
> stand-alone, report dir in site generation context.
> {quote}
> The javadoc is, BTW, still correct and does not need to be changed: In a site
> generation context, the reporting base directory will be set here
> automatically without any further changes due to:
> {code:java}
> @Override
> public void setReportOutputDirectory(File reportOutputDirectory) {
> this.reportOutputDirectory = reportOutputDirectory;
> this.outputDirectory = reportOutputDirectory;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1327] Change output directory default [maven-reporting-impl]
michael-o commented on code in PR #26:
URL:
https://github.com/apache/maven-reporting-impl/pull/26#discussion_r1372885052
##
src/main/java/org/apache/maven/reporting/AbstractMavenReport.java:
##
@@ -74,11 +74,16 @@
*/
public abstract class AbstractMavenReport extends AbstractMojo implements
MavenMultiPageReport {
/**
- * The output directory for the report. Note that this parameter is only
evaluated if the goal is run directly from
- * the command line. If the goal is run indirectly as part of a site
generation, the output directory configured in
- * the Maven Site Plugin is used instead.
+ * The output base directory for the report. Note that this parameter is
only evaluated if the goal is run directly
+ * from the command line. If the goal is run indirectly as part of a site
generation, the output base directory
+ * configured in the https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#outputDirectory";>
+ * Maven Site Plugin is used instead.
+ *
+ * To the respective base directory for each use case (direct mojo call
vs.site generation), implementing plugins
+ * might want to add their specific subdirectories for multi-page reports,
either using a hard-coded name or,
+ * ideally, an additional user-defined mojo parameter with a default value.
Review Comment:
I will try to provide/merge something for both next weekend.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MENFORCER-494) Allow banning dynamic versions before computing the final dependency tree
[
https://issues.apache.org/jira/browse/MENFORCER-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779816#comment-17779816
]
ASF GitHub Bot commented on MENFORCER-494:
--
JimmyAx opened a new pull request, #294:
URL: https://github.com/apache/maven-enforcer/pull/294
This commit introduces the possibility of banning dynamic versions in the
entire dependency tree before Maven computes the final dependency tree. If a
dependency exists multiple times in the dependency tree the plugin will not
detect any dynamic versions as long as the final dependency tree does not have
any dynamic versions.
In this example the dependency `A -> B -> D` is not detected with a dynamic
version unless the `verbose` parameter has been set in this pull request.
```
A
+- B
| \- D version 1.0
\- C
\- D version [1.0,2.0)
```
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/MENFORCER) 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 `[MENFORCER-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MENFORCER-XXX` with the appropriate JIRA issue.
Best practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [X] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [X] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [X] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [X] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> Allow banning dynamic versions before computing the final dependency tree
> -
>
> Key: MENFORCER-494
> URL: https://issues.apache.org/jira/browse/MENFORCER-494
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: banDynamicVersions
>Affects Versions: 3.4.1
>Reporter: Jimmy Axenhus
>Priority: Major
>
> {{banDynamicVersions}} won't ban a dependency with a dynamic version if it
> exists multiple times in the dependency tree, as long as the final dependency
> tree has no dynamic version.
> As an example consider the following dependency tree where D appears multiple
> times.
> {noformat}
> A
> +- B
> | \- D version 1.0
> \- C
>\- D version [1.0,2.0){noformat}
> Before the rule {{banDynmicVersions}} is applied the final dependency tree is
> computed which means we end up with the following.
> {noformat}
> A
> +- B
> | \- D version 1.0
> \- C{noformat}
> This computed dependency tree is fine by itself and has no dynamic versions
> but if the original dependency tree changes for whatever reason (such as D no
> longer being a dependency of B) the rule will now detect the dynamic version
> of D that C is trying to use.
> {noformat}
> A
> +- B
> \- C
>\- D version [1.0,2.0){noformat}
> The above example is actually something that happens to me. For various
> reasons I have a Maven project A with the dependencies B and C being
> developed independently from each other. In order to have a reproducible
> build I've applied the {{banDynamicVersions}} rule to the entire project. As
> B or C might introduce or remove dependencies at will I could actually end up
> with B removing the dependency on D and suddenly my project won't build any
> longer. At that moment I do not have the possibility of making C use a fixed
> version of D, and I do not want to introduce a dependency on D in my project
> A just to resolve that (my dependency tree is much large
[PR] [MENFORCER-494] Allow banning dynamic versions in whole tree [maven-enforcer]
JimmyAx opened a new pull request, #294: URL: https://github.com/apache/maven-enforcer/pull/294 This commit introduces the possibility of banning dynamic versions in the entire dependency tree before Maven computes the final dependency tree. If a dependency exists multiple times in the dependency tree the plugin will not detect any dynamic versions as long as the final dependency tree does not have any dynamic versions. In this example the dependency `A -> B -> D` is not detected with a dynamic version unless the `verbose` parameter has been set in this pull request. ``` A +- B | \- D version 1.0 \- C \- D version [1.0,2.0) ``` 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/MENFORCER) 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 `[MENFORCER-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MENFORCER-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [X] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-494) Allow banning dynamic versions before computing the final dependency tree
[
https://issues.apache.org/jira/browse/MENFORCER-494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779811#comment-17779811
]
Jimmy Axenhus commented on MENFORCER-494:
-
MENFORCER-405 and MENFORCER-406 seems to have a similar issue, but for a
different rule.
> Allow banning dynamic versions before computing the final dependency tree
> -
>
> Key: MENFORCER-494
> URL: https://issues.apache.org/jira/browse/MENFORCER-494
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: banDynamicVersions
>Affects Versions: 3.4.1
>Reporter: Jimmy Axenhus
>Priority: Major
>
> {{banDynamicVersions}} won't ban a dependency with a dynamic version if it
> exists multiple times in the dependency tree, as long as the final dependency
> tree has no dynamic version.
> As an example consider the following dependency tree where D appears multiple
> times.
> {noformat}
> A
> +- B
> | \- D version 1.0
> \- C
>\- D version [1.0,2.0){noformat}
> Before the rule {{banDynmicVersions}} is applied the final dependency tree is
> computed which means we end up with the following.
> {noformat}
> A
> +- B
> | \- D version 1.0
> \- C{noformat}
> This computed dependency tree is fine by itself and has no dynamic versions
> but if the original dependency tree changes for whatever reason (such as D no
> longer being a dependency of B) the rule will now detect the dynamic version
> of D that C is trying to use.
> {noformat}
> A
> +- B
> \- C
>\- D version [1.0,2.0){noformat}
> The above example is actually something that happens to me. For various
> reasons I have a Maven project A with the dependencies B and C being
> developed independently from each other. In order to have a reproducible
> build I've applied the {{banDynamicVersions}} rule to the entire project. As
> B or C might introduce or remove dependencies at will I could actually end up
> with B removing the dependency on D and suddenly my project won't build any
> longer. At that moment I do not have the possibility of making C use a fixed
> version of D, and I do not want to introduce a dependency on D in my project
> A just to resolve that (my dependency tree is much larger than this and it
> will be unreasonable to keep fixing things up).
> In order to solve that I want to ban dynamic versions in the entire
> dependency tree before the final dependency tree is computed. This currently
> isn't supported by the plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MENFORCER-494) Allow banning dynamic versions before computing the final dependency tree
Jimmy Axenhus created MENFORCER-494:
---
Summary: Allow banning dynamic versions before computing the final
dependency tree
Key: MENFORCER-494
URL: https://issues.apache.org/jira/browse/MENFORCER-494
Project: Maven Enforcer Plugin
Issue Type: Improvement
Components: banDynamicVersions
Affects Versions: 3.4.1
Reporter: Jimmy Axenhus
{{banDynamicVersions}} won't ban a dependency with a dynamic version if it
exists multiple times in the dependency tree, as long as the final dependency
tree has no dynamic version.
As an example consider the following dependency tree where D appears multiple
times.
{noformat}
A
+- B
| \- D version 1.0
\- C
\- D version [1.0,2.0){noformat}
Before the rule {{banDynmicVersions}} is applied the final dependency tree is
computed which means we end up with the following.
{noformat}
A
+- B
| \- D version 1.0
\- C{noformat}
This computed dependency tree is fine by itself and has no dynamic versions but
if the original dependency tree changes for whatever reason (such as D no
longer being a dependency of B) the rule will now detect the dynamic version of
D that C is trying to use.
{noformat}
A
+- B
\- C
\- D version [1.0,2.0){noformat}
The above example is actually something that happens to me. For various reasons
I have a Maven project A with the dependencies B and C being developed
independently from each other. In order to have a reproducible build I've
applied the {{banDynamicVersions}} rule to the entire project. As B or C might
introduce or remove dependencies at will I could actually end up with B
removing the dependency on D and suddenly my project won't build any longer. At
that moment I do not have the possibility of making C use a fixed version of D,
and I do not want to introduce a dependency on D in my project A just to
resolve that (my dependency tree is much larger than this and it will be
unreasonable to keep fixing things up).
In order to solve that I want to ban dynamic versions in the entire dependency
tree before the final dependency tree is computed. This currently isn't
supported by the plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEP-832) Remove commons-collections-4
[
https://issues.apache.org/jira/browse/MDEP-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779778#comment-17779778
]
ASF GitHub Bot commented on MDEP-832:
-
vtintillier commented on code in PR #255:
URL:
https://github.com/apache/maven-dependency-plugin/pull/255#discussion_r1372695195
##
pom.xml:
##
@@ -260,11 +260,6 @@ under the License.
commons-collections4
Review Comment:
didn't you mean to remove this one?
> Remove commons-collections-4
>
>
> Key: MDEP-832
> URL: https://issues.apache.org/jira/browse/MDEP-832
> Project: Maven Dependency Plugin
> Issue Type: Improvement
>Affects Versions: 3.3.0
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.6.1
>
>
> Remove the dependency:
> {code:xml}
>
> org.apache.commons
> commons-collections4
> 4.2
>
> {code}
> which is used only for a single method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MDEP-832] - Remove commons-collections-4 [maven-dependency-plugin]
vtintillier commented on code in PR #255: URL: https://github.com/apache/maven-dependency-plugin/pull/255#discussion_r1372695195 ## pom.xml: ## @@ -260,11 +260,6 @@ under the License. commons-collections4 Review Comment: didn't you mean to remove this one? -- 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-510) NullPointerException when using --patch-module compiler argument
[
https://issues.apache.org/jira/browse/MCOMPILER-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779776#comment-17779776
]
Slawomir Jaranowski commented on MCOMPILER-510:
---
Thanks for checking.
Can you create new issue with patch-module as jar ... I don't know why it is
required as directory :)
> NullPointerException when using --patch-module compiler argument
>
>
> Key: MCOMPILER-510
> URL: https://issues.apache.org/jira/browse/MCOMPILER-510
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.10.1
>Reporter: Artem K.
>Priority: Major
> Attachments: poc.zip
>
>
> h2. Summary
> When using {{--patch-module}} compiler argument, there is a
> {{NullPointerException}} due to field {{pathElements}} not being initialized
> in {{{}CompilerMojo{}}}.
> h2. Description
> The method {{preparePaths}} in {{CompilerMojo}} has two code paths:
> {code:java}
> @Override
> protected void preparePaths( Set sourceFiles )
> {
> boolean hasModuleDescriptor = false;
> // ...
> if ( hasModuleDescriptor )
> {
> modulepathElements = new ArrayList<>( compilePath.size() );
> classpathElements = new ArrayList<>( compilePath.size() );
> pathElements = new LinkedHashMap<>( compilePath.size() );
> }
> else
> {
> classpathElements = new ArrayList<>();
> modulepathElements = Collections.emptyList();
> // ...
> }
> }{code}
> Notice that in the else part, {{pathElements}} is not initialized. This field
> is used when the compiler arguments contain {{--patch-module}} switch. So
> whenever the compiler is used with this switch and there is no module
> descriptor in the project, NPE occurs.
> h2. Proof-of-concept
> Attached is a simple proof-of-concept to illustrate the issue. The project
> consists of a single class with raises {{NullPointerException}} using a new
> constructor {{{}NullPointerException(Throwable){}}}, which does not exist in
> base JDK.
> * When executing {{{}javac{}}}}} src\main\java\poc\Main.java{}}}, the
> compilation fails as expected.
> * Using a replacement {{NullPointerException}} class in {{java_base.jar}}
> with the added constructor, the compilation works fine:}} javac
> --patch-module java.base=java_base.jar src\main\java\poc\Main.java{}}}.
> * Attempting to do the same using Maven compiler plugin results in
> NullPointerException: {{mvn -X compile}}
> h2. Walkaround
> I was able to fix the problem by adding the line
> {code:java}
> pathElements = Collections.emptyMap(); {code}
> to the else part of the {{{}CompilerMojo.preparePaths{}}}.
> The compilation started working, it does however produce a warning
> {noformat}
> [WARNING] Can't locate java_base.jar{noformat}
> every single time. I did not investigate much the cause of this message.
> Also note that while similar, this issues is not the same as MCOMPILER-311.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
