Re: [PR] [MPLUGIN-450] Require goalPrefix to be valid [maven-plugin-tools]
laeubi commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891513101 > The fix is always trivial: grab your last release read your plugin.xml and just configure it to be aligned. This recommendation together with this fact > if the artifactId does not follow maven convention then the heuristic is just failing and returns null leading to no prefix in plugin.xml confuses me... so how can I lookup something that isn't there? So I think the **error** is correct if it is truly empty... but not for cases where it has something else, then one might **warn** that the prefix is probably not as expected (where its a bit unclear what users will expect, maybe nothing much if they never checked the prefix...). -- 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-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806674#comment-17806674 ] ASF GitHub Bot commented on MPLUGIN-450: laeubi commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891513101 > The fix is always trivial: grab your last release read your plugin.xml and just configure it to be aligned. This recommendation together with this fact > if the artifactId does not follow maven convention then the heuristic is just failing and returns null leading to no prefix in plugin.xml confuses me... so how can I lookup something that isn't there? So I think the **error** is correct if it is truly empty... but not for cases where it has something else, then one might **warn** that the prefix is probably not as expected (where its a bit unclear what users will expect, maybe nothing much if they never checked the prefix...). > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-450) Make goal prefix mandatory by default
[
https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806668#comment-17806668
]
ASF GitHub Bot commented on MPLUGIN-450:
rmannibucau commented on PR #240:
URL:
https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891500550
> Especially it seems that two projects (tycho+apache-rat) that are using
the convention -plugin getting the same resulting prefix (==
) so it can't be that random
s/random/uncontrolled or unknown/
and this is the issue, when then the plugin wants to take control cause you
don't want to type my-plugin-foo or anything else then you break backward
compat of the runtime so better to adjust the *tooling* (build only, note there
is *no* breaking change for the runtime).
The fix is *always* trivial: grab your last release read your plugin.xml and
just configure it to be aligned.
> So obviously the assumption that anything that do not matches
*-maven-plugin *-maven-plugin got no prefix is wrong, you never get an empty
prefix as claimed in the ticket.
No, you can review the previous code, if the artifactId does not follow
maven convention then the heuristic is just failing and returns null leading to
no prefix in plugin.xml.
A common pattern I saw was to name the maven plugin "maven-plugin", then,
due to the `Pattern.compile("-?(maven|plugin)-?").replaceAll("")` usage in the
heuristic it was leading to no prefix.
Indeed we can relax a bit the fix Guillaume did to keep the heuristic and
warn the user it should be set explicitly to ensure it is under control but I
guess the best is just current code which is the most straight forward for
anyone, once the error message is explicit the fix is trivial for anyone and
there wouldn't be much discussion I think.
That said I would be ok if we do this change only for maven 4 and keep maven
3 as this but I think it goes in the right direction enhancing the quality of
the built plugins and the warning would just be as bothering as an error so
let's keep it an error for the final deliverable.
Side note: if you don't know the prefix you were using you can also rely on
the doc, as of today, since it is explicit there, you can review
https://tycho.eclipseprojects.io/doc/latest/tycho-compiler-plugin/plugin-info.html
for example.
> Make goal prefix mandatory by default
> -
>
> Key: MPLUGIN-450
> URL: https://issues.apache.org/jira/browse/MPLUGIN-450
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Reporter: Tamas Cservenak
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.11.0
>
>
> The goal prefix currently is not mandatory, and plugin uses heuristic to
> figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for
> org.apache.maven plugins ONLY).
> In general, goal prefix is optional, but "good to have", and usually is
> present.
> Cases when is not present, is when heuristics fails (so plugin module is not
> named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide
> one either. The cases when prefix is not present is mostly unintentional, but
> maven-plugin-plugin leaves this without any remark or warning.
> IMHO, the maven-plugin-plugin should either warn, or even fail the build in
> case when goal prefix is not present, but we may want to have some option to
> turn off this feature (for me unknown reasons, where it would be expected to
> NOT have goal prefix for a reason).
> TL;DR Am pretty much sure that in most of the cases when plugin developer
> ends up with plugin without prefix, that it was unintentional (and causes
> surprise later, not to mention refactoring the module name or POM change to
> configure it), while there MAY be cases where goal prefix is not desired for
> some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put,
> the out of the box defaults should enforce presence of it, while advanced
> users still can produce prefix-less plugins with some extra configuration.
> This would make things more explicit as well: even if plugin is named as
> xxx-maven-plugin, configuration would be clear I do not want prefix for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MPLUGIN-450] Require goalPrefix to be valid [maven-plugin-tools]
rmannibucau commented on PR #240:
URL:
https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891500550
> Especially it seems that two projects (tycho+apache-rat) that are using
the convention -plugin getting the same resulting prefix (==
) so it can't be that random
s/random/uncontrolled or unknown/
and this is the issue, when then the plugin wants to take control cause you
don't want to type my-plugin-foo or anything else then you break backward
compat of the runtime so better to adjust the *tooling* (build only, note there
is *no* breaking change for the runtime).
The fix is *always* trivial: grab your last release read your plugin.xml and
just configure it to be aligned.
> So obviously the assumption that anything that do not matches
*-maven-plugin *-maven-plugin got no prefix is wrong, you never get an empty
prefix as claimed in the ticket.
No, you can review the previous code, if the artifactId does not follow
maven convention then the heuristic is just failing and returns null leading to
no prefix in plugin.xml.
A common pattern I saw was to name the maven plugin "maven-plugin", then,
due to the `Pattern.compile("-?(maven|plugin)-?").replaceAll("")` usage in the
heuristic it was leading to no prefix.
Indeed we can relax a bit the fix Guillaume did to keep the heuristic and
warn the user it should be set explicitly to ensure it is under control but I
guess the best is just current code which is the most straight forward for
anyone, once the error message is explicit the fix is trivial for anyone and
there wouldn't be much discussion I think.
That said I would be ok if we do this change only for maven 4 and keep maven
3 as this but I think it goes in the right direction enhancing the quality of
the built plugins and the warning would just be as bothering as an error so
let's keep it an error for the final deliverable.
Side note: if you don't know the prefix you were using you can also rely on
the doc, as of today, since it is explicit there, you can review
https://tycho.eclipseprojects.io/doc/latest/tycho-compiler-plugin/plugin-info.html
for example.
--
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] (MPOM-264) Parameterize maven-compiler-plugin with parameter "release" when running on JDK 9+
[
https://issues.apache.org/jira/browse/MPOM-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806662#comment-17806662
]
Konrad Windszus edited comment on MPOM-264 at 1/15/24 7:31 AM:
---
[~hboutemy] Any reason why you haven't added this to ASF parent?
was (Author: kwin):
[~sjaranowski] Any reason why you haven't added this to ASF parent?
> Parameterize maven-compiler-plugin with parameter "release" when running on
> JDK 9+
> --
>
> Key: MPOM-264
> URL: https://issues.apache.org/jira/browse/MPOM-264
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Affects Versions: ASF-23
>Reporter: Konrad Windszus
>Priority: Major
>
> Instead of using {{source}} and {{target}} the new parameter {{release}}
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release)
> should be used with Java 9+ as that also checks whether the used API is
> provided in the target Java release
> (https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> To be able to support both compilation with Java < 9 and above a profile
> should be used which either configures {{source}} and {{target}} or
> {{release}}.
> You have to observe though that the parameter values are different though,
> as the former supports 1.6, 1.7 and 1.8 while the latter only supports 6, 7
> and 8.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPOM-264) Parameterize maven-compiler-plugin with parameter "release" when running on JDK 9+
[
https://issues.apache.org/jira/browse/MPOM-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806662#comment-17806662
]
Konrad Windszus commented on MPOM-264:
--
[~sjaranowski] Any reason why you haven't added this to ASF parent?
> Parameterize maven-compiler-plugin with parameter "release" when running on
> JDK 9+
> --
>
> Key: MPOM-264
> URL: https://issues.apache.org/jira/browse/MPOM-264
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Affects Versions: ASF-23
>Reporter: Konrad Windszus
>Priority: Major
>
> Instead of using {{source}} and {{target}} the new parameter {{release}}
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release)
> should be used with Java 9+ as that also checks whether the used API is
> provided in the target Java release
> (https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> To be able to support both compilation with Java < 9 and above a profile
> should be used which either configures {{source}} and {{target}} or
> {{release}}.
> You have to observe though that the parameter values are different though,
> as the former supports 1.6, 1.7 and 1.8 while the latter only supports 6, 7
> and 8.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DOXIA-724) Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
[
https://issues.apache.org/jira/browse/DOXIA-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus resolved DOXIA-724.
---
Fix Version/s: 2.0.0-M10
2.0.0
Resolution: Fixed
> Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
>
>
> Key: DOXIA-724
> URL: https://issues.apache.org/jira/browse/DOXIA-724
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0-M10, 2.0.0
>
>
> According to the javadoc the SinkWrapperFactory should be ordered according
> to their priority from highest to lowest. However in
> {{AbstractParser.getWrappedSink()}} a pipeline is returned which has no
> predictable order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-724) Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
[
https://issues.apache.org/jira/browse/DOXIA-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806661#comment-17806661
]
ASF GitHub Bot commented on DOXIA-724:
--
kwin merged PR #195:
URL: https://github.com/apache/maven-doxia/pull/195
> Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
>
>
> Key: DOXIA-724
> URL: https://issues.apache.org/jira/browse/DOXIA-724
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> According to the javadoc the SinkWrapperFactory should be ordered according
> to their priority from highest to lowest. However in
> {{AbstractParser.getWrappedSink()}} a pipeline is returned which has no
> predictable order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-724] Fix order of sink wrappers in pipeline [maven-doxia]
kwin merged PR #195: URL: https://github.com/apache/maven-doxia/pull/195 -- 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-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806652#comment-17806652 ] ASF GitHub Bot commented on MPLUGIN-450: laeubi commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891431842 > I'm not sure cause no it cant happen. You can get conflicts but no surprise nor wrong behavior if explicit compared to an almost random heuristic. Until now no one could give an example of "random" behavior, so can you show where this random part happen? For me it was (and is) completely deterministic as for each given input it always gives the same output. Especially it seems that two projects (`tycho`+`apache-rat`) that are using the convention `-plugin` getting the same resulting prefix (== `` ) so it can't be _that_ random It was simply assumed (what obviously is wrong) that: 1. goal prefix is optional, but "good to have" --> actually goal prefix was always present, so only explicitly specify it was optional) 2. Cases when is not present, is when heuristics fails (so plugin module is not named as "xxx-maven-plugin" or "maven-xxx-plugin") --> also "xxx-plugin" works fine before, as well as even xxx as artifact id 3. The cases when prefix is not present is mostly unintentional --> the new behavior does not fail/war/... in cases there is no prefix, as obviously tycho+rat have a prefix successfully derived but now fail So obviously the assumption that anything that do not matches `*-maven-plugin` `*-maven-plugin` got **no prefix** is wrong, you never get an empty prefix as claimed in the ticket. > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-450] Require goalPrefix to be valid [maven-plugin-tools]
laeubi commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891431842 > I'm not sure cause no it cant happen. You can get conflicts but no surprise nor wrong behavior if explicit compared to an almost random heuristic. Until now no one could give an example of "random" behavior, so can you show where this random part happen? For me it was (and is) completely deterministic as for each given input it always gives the same output. Especially it seems that two projects (`tycho`+`apache-rat`) that are using the convention `-plugin` getting the same resulting prefix (== `` ) so it can't be _that_ random It was simply assumed (what obviously is wrong) that: 1. goal prefix is optional, but "good to have" --> actually goal prefix was always present, so only explicitly specify it was optional) 2. Cases when is not present, is when heuristics fails (so plugin module is not named as "xxx-maven-plugin" or "maven-xxx-plugin") --> also "xxx-plugin" works fine before, as well as even xxx as artifact id 3. The cases when prefix is not present is mostly unintentional --> the new behavior does not fail/war/... in cases there is no prefix, as obviously tycho+rat have a prefix successfully derived but now fail So obviously the assumption that anything that do not matches `*-maven-plugin` `*-maven-plugin` got **no prefix** is wrong, you never get an empty prefix as claimed in the ticket. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MPLUGIN-450] Require goalPrefix to be valid [maven-plugin-tools]
rmannibucau commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891408990 @laeubi well I'm not sure cause no it cant happen. You can get conflicts but no surprise nor wrong behavior if explicit compared to an almost random heuristic. Alternative is to force the naming convention - artifactid=x-maven-plugin whichbis worse is backward compat so guess we are not that bad and fact you dont know what you setup foe tycho shows it is a good thing to force the config, just an error message enhancement to help users to recover from the upgrade. -- 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-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806647#comment-17806647 ] ASF GitHub Bot commented on MPLUGIN-450: rmannibucau commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891408990 @laeubi well I'm not sure cause no it cant happen. You can get conflicts but no surprise nor wrong behavior if explicit compared to an almost random heuristic. Alternative is to force the naming convention - artifactid=x-maven-plugin whichbis worse is backward compat so guess we are not that bad and fact you dont know what you setup foe tycho shows it is a good thing to force the config, just an error message enhancement to help users to recover from the upgrade. > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806646#comment-17806646 ] Herve Boutemy edited comment on MPMD-391 at 1/15/24 6:48 AM: - "PMD version: 6.55.0" should be "Running PMD version 6.55.0 to target/pmd.xml" when PMD is being invoked, to clearly show what is being done and yes, when it's about PMD result, displaying the result before failing makes sense and before "Rendering content ", showing "Creating site PMD report" would explain why skin is relevant on that task was (Author: hboutemy): "PMD version: 6.55.0" should be "Running PMD version 6.55.0 to target/pmd.xml" when PMD is being invoked, to clearly show what is being done and yes, when it's about PMD result, displaying the result makes sense and before "Rendering content ", showing "Creating site PMD report" would explain why skin is relevant on that task > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806646#comment-17806646 ] Herve Boutemy commented on MPMD-391: "PMD version: 6.55.0" should be "Running PMD version 6.55.0 to target/pmd.xml" when PMD is being invoked, to clearly show what is being done and yes, when it's about PMD result, displaying the result makes sense and before "Rendering content ", showing "Creating site PMD report" would explain why skin is relevant on that task > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806625#comment-17806625 ] ASF GitHub Bot commented on MPLUGIN-450: laeubi commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891323384 > We got issues with plugins wrongly naming the artifactId (not respecting foo-maven-plugin) or misusing plugin in the name leading to a surprising name. All this can happen with a configured prefix as well... And as said if one is "surprised" can still configure it already but not it fails for all "non surprising" cases as well. > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Bump com.diffplug.spotless:spotless-maven-plugin from 2.41.1 to 2.42.0 [maven-parent]
dependabot[bot] opened a new pull request, #158:
URL: https://github.com/apache/maven-parent/pull/158
Bumps
[com.diffplug.spotless:spotless-maven-plugin](https://github.com/diffplug/spotless)
from 2.41.1 to 2.42.0.
Changelog
Sourced from https://github.com/diffplug/spotless/blob/main/CHANGES.md;>com.diffplug.spotless:spotless-maven-plugin's
changelog.
[2.42.0] - 2023-09-28
Added
Support for biome. The Rome project https://biomejs.dev/blog/annoucing-biome/;>was renamed to Biome.
The configuration is still the same, but you should switch to the new
biome tag / function and adjust
the version accordingly. (https://redirect.github.com/diffplug/spotless/issues/1804;>#1804).
Support for google-java-format's
skip-javadoc-formatting option. (https://redirect.github.com/diffplug/spotless/pull/1793;>#1793)
Support configuration of mirrors for P2 repositories in Maven DSL (https://redirect.github.com/diffplug/spotless/issues/1697;>#1697).
New line endings mode GIT_ATTRIBUTES_FAST_ALLSAME. (https://redirect.github.com/diffplug/spotless/pull/1838;>#1838)
Fixed
Fix support for plugins when using Prettier version 3.0.0
and newer. (https://redirect.github.com/diffplug/spotless/pull/1802;>#1802)
Fix configuration cache issue around external process started
'/usr/bin/git --version'. (https://redirect.github.com/diffplug/spotless/issues/1806;>#1806)
Changes
Bump default flexmark version to latest 0.64.0
- 0.64.8. (https://redirect.github.com/diffplug/spotless/pull/1801;>#1801)
Bump default ktlint version to latest 0.50.0
- 1.0.0. (https://redirect.github.com/diffplug/spotless/pull/1808;>#1808)
[2.41.0] - 2023-08-29
Added
Add a jsonPatch step to json formatter
configurations. This allows patching of JSON documents using https://jsonpatch.com;>JSON Patches. (https://redirect.github.com/diffplug/spotless/pull/1753;>#1753)
Support GJF own import order. (https://redirect.github.com/diffplug/spotless/pull/1780;>#1780)
Fixed
Use latest versions of popular style guides for eslint
tests to fix failing useEslintXoStandardRules test. (https://redirect.github.com/diffplug/spotless/pull/1761;>#1761, https://redirect.github.com/diffplug/spotless/issues/1756;>#1756)
Add support for prettier version 3.0.0 and
newer. (https://redirect.github.com/diffplug/spotless/pull/1760;>#1760, https://redirect.github.com/diffplug/spotless/issues/1751;>#1751)
Fix npm install calls when npm cache is not up-to-date. (https://redirect.github.com/diffplug/spotless/pull/1760;>#1760, https://redirect.github.com/diffplug/spotless/issues/1750;>#1750)
Changes
Bump default eslint version to latest 8.31.0
- 8.45.0 (https://redirect.github.com/diffplug/spotless/pull/1761;>#1761)
Bump default prettier version to latest (v2)
2.8.1 - 2.8.8. (https://redirect.github.com/diffplug/spotless/pull/1760;>#1760)
Bump default greclipse version to latest 4.27
- 4.28. (https://redirect.github.com/diffplug/spotless/pull/1775;>#1775)
[2.40.0] - 2023-07-17
Added
Added support for Protobuf formatting based on https://buf.build/;>Buf. (https://redirect.github.com/diffplug/spotless/issues/1208;>#1208)
enum OnMatch { INCLUDE, EXCLUDE } so that
FormatterStep.filterByContent can not only include based on the
pattern but also exclude. (https://redirect.github.com/diffplug/spotless/pull/1749;>#1749)
Fixed
Update documented default semanticSort to
false. (https://redirect.github.com/diffplug/spotless/pull/1728;>#1728)
Changes
Bump default cleanthat version to latest 2.13
- 2.17. (https://redirect.github.com/diffplug/spotless/pull/1734;>#1734)
Bump default ktlint version to latest 0.49.1
- 0.50.0. (https://redirect.github.com/diffplug/spotless/issues/1741;>#1741)
Dropped support for ktlint 0.47.x following our policy of
supporting two breaking changes at a time.
Dropped support for deprecated useExperimental parameter in
favor of the ktlint_experimental property.
[2.39.0] - 2023-05-24
Added
Jvm.Support now accepts -SNAPSHOT versions,
treated as the non-SNAPSHOT. (https://redirect.github.com/diffplug/spotless/issues/1583;>#1583)
Support Rome as a formatter for JavaScript and TypeScript code. Adds a
new rome step to javascript and
typescript formatter configurations. (https://redirect.github.com/diffplug/spotless/pull/1663;>#1663)
Add semantics-aware Java import ordering (i.e. sort by package, then
class, then member). (https://redirect.github.com/diffplug/spotless/issues/522;>#522)
Fixed
Fixed a regression which changed the import sorting order in
googleJavaFormat introduced in 2.38.0. (https://redirect.github.com/diffplug/spotless/pull/1680;>#1680)
Equo-based formatters now work on platforms unsupported by Eclipse such
as PowerPC (fixes https://redirect.github.com/diffplug/durian-swt/issues/20;>durian-swt#20)
When
[jira] [Created] (MPLUGIN-505) helpmojo: does not respect nested list in javadoc
Ernst Reissner created MPLUGIN-505: -- Summary: helpmojo: does not respect nested list in javadoc Key: MPLUGIN-505 URL: https://issues.apache.org/jira/browse/MPLUGIN-505 Project: Maven Plugin Tools Issue Type: Bug Affects Versions: 3.11.0 Reporter: Ernst Reissner In https://github.com/Reissner/latex-maven-plugin/blob/master/maven-latex-plugin/src/main/java/eu/simuline/m2latex/mojo/InjectionMojo.java there is an example of a parameter with documentation containing nested lists. I create the help with goal `helpmojo`. I display this with `mvn latex:help -Ddetail -Dgoal=inj` but this yields a list with one layer only. Obviously a bug. In the api doc, all is ok. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Bump org.codehaus.plexus:plexus-utils from 3.3.1 to 4.0.0 [maven-rar-plugin]
dependabot[bot] opened a new pull request, #13: URL: https://github.com/apache/maven-rar-plugin/pull/13 Bumps [org.codehaus.plexus:plexus-utils](https://github.com/codehaus-plexus/plexus-utils) from 3.3.1 to 4.0.0. Release notes Sourced from https://github.com/codehaus-plexus/plexus-utils/releases;>org.codehaus.plexus:plexus-utils's releases. 4.0.0 Starting with version 4, XML classes (in org.codehaus.plexus.util.xml and org.codehaus.plexus.util.xml.pull) have been extracted to a separate https://github.com/codehaus-plexus/plexus-xml/;>plexus-xml 4: if you need them, just use this new artifact as outlined in https://codehaus-plexus.github.io/plexus-xml/dependency-info.html;>https://codehaus-plexus.github.io/plexus-xml/dependency-info.html. Fix false difference detected with CachingOutputStream/CachingWriter when streams are flushed (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/252;>#252) https://github.com/gnodet;>@gnodet Dependency updates Switch to junit 5 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/245;>#245) https://github.com/gnodet;>@gnodet Maintenance Switch to junit 5 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/245;>#245) https://github.com/gnodet;>@gnodet Remove unused/unmaintained jira export (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/247;>#247) https://github.com/gnodet;>@gnodet Switch build ci workflow to master branch (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/250;>#250) https://github.com/slachiewicz;>@slachiewicz Bump maven-resources-plugin from 2.7 to 3.3.1 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/209;>#209) https://github.com/dependabot;>@dependabot Fix SCM information (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/254;>#254) https://github.com/gnodet;>@gnodet Fix non contiguous imports (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/255;>#255) https://github.com/gnodet;>@gnodet 3.5.1 New features and improvements Reading and writing files using Java NIO (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/232;>#232) https://github.com/mkarg;>@mkarg Bug Fixes Partial revert of Support combine.self='remove' to fix MNG-7709 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/241;>#241) https://github.com/gnodet;>@gnodet Fix reading comments with UTF chars (fixes https://redirect.github.com/codehaus-plexus/plexus-utils/issues/238;>#238) (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/240;>#240) https://github.com/gnodet;>@gnodet Dependency updates Bump codehaus-plexus/.github from 0.0.1 to 0.0.4 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/237;>#237) https://github.com/dependabot;>@dependabot Bump actions/checkout from 3.2.0 to 3.3.0 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/231;>#231) https://github.com/dependabot;>@dependabot Bump actions/checkout from 3.1.0 to 3.2.0 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/227;>#227) https://github.com/dependabot;>@dependabot Bump jmh-generator-annprocess from 1.35 to 1.36 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/222;>#222) https://github.com/dependabot;>@dependabot Bump jmh-core from 1.35 to 1.36 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/223;>#223) https://github.com/dependabot;>@dependabot Bump actions/checkout from 3.0.2 to 3.1.0 (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/220;>#220) https://github.com/dependabot;>@dependabot 3.5.0 Don't throw IOException when none is required (https://redirect.github.com/codehaus-plexus/plexus-utils/issues/206;>#206) (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/221;>#221) https://github.com/michael-o;>@michael-o Always preserve dominant node value (even if empty) (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/217;>#217) https://github.com/kwin;>@kwin Don't overwrite blank (but non-empty) dominant values during mergeXpp3Dom (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/213;>#213) https://github.com/kwin;>@kwin Deprecate isEmpty(String) and isNotEmpty(String) in favour of same named (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/218;>#218) https://github.com/kwin;>@kwin isEmpty(String) must not return false for whitespace-only values (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/219;>#219) https://github.com/kwin;>@kwin Get rid maven-plugin-testing-harness from dependency (https://redirect.github.com/codehaus-plexus/plexus-utils/pull/208;>#208) https://github.com/slawekjaranowski;>@slawekjaranowski Dependency updates Bump plexus from 8 to 10
[jira] [Commented] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806570#comment-17806570 ] Elliotte Rusty Harold commented on MPMD-391: Yes, this crosses a lot of projects. It does surface here. Also printing the actual issue PMD flagged should also be in out control. Even if PMD only writes that into a file, we should parse the data out of that file and print the problem here. > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.codehaus.plexus:plexus-interactivity-api from 1.1 to 1.2 [maven-javadoc-plugin]
elharo merged PR #258: URL: https://github.com/apache/maven-javadoc-plugin/pull/258 -- 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] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806561#comment-17806561 ] Michael Osipov commented on MPMD-391: - The PMD version can be dropped, this is in our control. > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
[
https://issues.apache.org/jira/browse/MNG-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806559#comment-17806559
]
Michael Osipov commented on MNG-8017:
-
OK, here is the deal:
[Here|https://lists.freebsd.org/pipermail/freebsd-current/2020-May/076047.html]
it was announced that {{termcap(5}}} would be replaced with {{terminfo(5)}}
which happened in [FreeBSD
14|https://github.com/freebsd/freebsd-src/commit/61f66a1f4403fded9aae14d890ad96914a3c0bc1].
Basically, {{ncurses}} was updated and all executable installed with the base
operating system. This change was never backported to 13 or 12, thus the
exception. Since jline is a new dep, some documentation should mention that
{{terminfo(5)}} is expected to be installed from {{ncurses}}.
> Maven fails at start with "Cannot run program "infocmp": error=2, No such
> file or directory"
>
>
> Key: MNG-8017
> URL: https://issues.apache.org/jira/browse/MNG-8017
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-13
> Environment: Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
>Reporter: Michael Osipov
>Priority: Critical
>
> From {{mvn -v}}:
> {noformat}
> mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
> $ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
> Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
> WARNUNG: Unable to retrieve infocmp for type xterm-color
> java.io.IOException: Cannot run program "infocmp": error=2, No such file or
> directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
> at
> org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
> at
> org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
> at
> org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
> at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
> at
> org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:251)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 17 more
> Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-463) Ensure checksum record file (summary fie) is sorted by artifact relative path and not checksum
[ https://issues.apache.org/jira/browse/MRESOLVER-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806557#comment-17806557 ] ASF GitHub Bot commented on MRESOLVER-463: -- rmannibucau commented on PR #404: URL: https://github.com/apache/maven-resolver/pull/404#issuecomment-1891072706 Yes, no strong opinion on that since I'm more aiming at mvn 4 for this one but if you feel it is worth it also happy to backport (can be delayed of +-1week that said due to personal constraints) > Ensure checksum record file (summary fie) is sorted by artifact relative path > and not checksum > -- > > Key: MRESOLVER-463 > URL: https://issues.apache.org/jira/browse/MRESOLVER-463 > Project: Maven Resolver > Issue Type: Task >Affects Versions: 2.0.0-alpha-6 >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-7 > > > Goal is to navigate in the file manually more easily - tools don't need to > navigate from vi anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8009) BOM peculiarities with build ordering
[
https://issues.apache.org/jira/browse/MNG-8009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806558#comment-17806558
]
Tamas Cservenak commented on MNG-8009:
--
Despite fix on master, the invocation of {{mvn spotless:apply}} still fails on
last module (BOM) as it has no knowledge about the plugin...
> BOM peculiarities with build ordering
> -
>
> Key: MNG-8009
> URL: https://issues.apache.org/jira/browse/MNG-8009
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.9.6, 4.0.0-alpha-10
>Reporter: Tamas Cservenak
>Priority: Blocker
>
> Maven 3.9.6 and 4.0.0-alpha-11-SNAP (current master), Java 21.
> After this commit:
> https://github.com/apache/maven/commit/f1c53cbfdfc99cfc6e1521a450adeeb817b89345
> Executing from top level command {{mvn spotless:apply}} does NOT work: plugin
> is not found!
> If you checkout commit before that one, it works.
> Diffing the debug output from two executions, the "good" one (before given
> commit) has this line:
> bq. Resolved plugin prefix spotless to
> com.diffplug.spotless:spotless-maven-plugin from POM
> org.apache.maven:maven-bom:pom:4.0.0-alpha-11-SNAPSHOT
> Meaning, plugin is resolved from BOM??? And as given commit _changes_ the BOM
> parent from maven-parent (that has spotless defined) to ASF parent (that does
> not have it), makes plugin not resolvable?
> Despite root POM of Maven parent maven-parent defines it, and even top level
> POM _redefines it_?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MRESOLVER-463] sort checksum summary file per path and not checksum to be human friendly [maven-resolver]
rmannibucau commented on PR #404: URL: https://github.com/apache/maven-resolver/pull/404#issuecomment-1891072706 Yes, no strong opinion on that since I'm more aiming at mvn 4 for this one but if you feel it is worth it also happy to backport (can be delayed of +-1week that said due to personal constraints) -- 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-164) DefaultDependencyCollector filterVersions seems always return full version range
[ https://issues.apache.org/jira/browse/MRESOLVER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-164: -- Fix Version/s: 2.0.0 2.0.0-alpha-5 > DefaultDependencyCollector filterVersions seems always return full version > range > > > Key: MRESOLVER-164 > URL: https://issues.apache.org/jira/browse/MRESOLVER-164 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.4.2, 1.6.1 >Reporter: Xiang Li >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-5 > > > Related to MNG-7049 but I think the root cause is in maven-resolver so I > opened a new issue. Correct me if it is better to still use the old ticket. > During using version ranges, I notice that maven will download all poms from > a version range, which happen in that > [loop|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L404], > the reason is that > [verFilter|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155] > here seems return null. Since by default, versionFilter is set to null by > DefaultRepositorySystemSession, and I do not see many examples that > setVersionFilter get used for some reason. > Another thing that confuses me is that version range is resolved by > DefaultVersionRangeResolver in maven rather than maven-resolver here. > > I wonder if it possible to set HighestVersionFilter > [here|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155] > instead of return all version range results. I am happy to contribute a PR > with some guidance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-164) DefaultDependencyCollector filterVersions seems always return full version range
[ https://issues.apache.org/jira/browse/MRESOLVER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-164. - Resolution: Fixed Fixed by MRESOLVER-451 > DefaultDependencyCollector filterVersions seems always return full version > range > > > Key: MRESOLVER-164 > URL: https://issues.apache.org/jira/browse/MRESOLVER-164 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Affects Versions: 1.4.2, 1.6.1 >Reporter: Xiang Li >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-5 > > > Related to MNG-7049 but I think the root cause is in maven-resolver so I > opened a new issue. Correct me if it is better to still use the old ticket. > During using version ranges, I notice that maven will download all poms from > a version range, which happen in that > [loop|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L404], > the reason is that > [verFilter|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155] > here seems return null. Since by default, versionFilter is set to null by > DefaultRepositorySystemSession, and I do not see many examples that > setVersionFilter get used for some reason. > Another thing that confuses me is that version range is resolved by > DefaultVersionRangeResolver in maven rather than maven-resolver here. > > I wonder if it possible to set HighestVersionFilter > [here|https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L155] > instead of return all version range results. I am happy to contribute a PR > with some guidance. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-217) Allow extra "sources" for Artifact decoration
[ https://issues.apache.org/jira/browse/MRESOLVER-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-217: -- Fix Version/s: 2.0.0 > Allow extra "sources" for Artifact decoration > - > > Key: MRESOLVER-217 > URL: https://issues.apache.org/jira/browse/MRESOLVER-217 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > For start, a simple API that would "enhance" Artifact instances from it (like > populating artifact properties). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-233) Add protected abstract org.e.a.artifact.AbstractArtifact.newInstance()
[
https://issues.apache.org/jira/browse/MRESOLVER-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-233:
--
Fix Version/s: 2.0.0
> Add protected abstract org.e.a.artifact.AbstractArtifact.newInstance()
> --
>
> Key: MRESOLVER-233
> URL: https://issues.apache.org/jira/browse/MRESOLVER-233
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Affects Versions: 1.7.3
>Reporter: Michael Osipov
>Priority: Major
> Fix For: 2.0.0
>
>
> This method has two issues:
> * It lacks abstraction that it relies on a subtype which should be unknown
> here
> * with an abstract method every derived type can properly return again a
> derived type instead of having {{DefaultArtifact}} which loses details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-264:
--
Fix Version/s: 2.0.0
> Make file-lock the default locking
> --
>
> Key: MRESOLVER-264
> URL: https://issues.apache.org/jira/browse/MRESOLVER-264
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Default locking in Resolver is RW locks, that is only in-JVM (so covers the
> multi threaded case). Simply, if users use Maven concurrently from different
> terminal windows, they still can end up with corrupted local repository.
> Hence, IMHO the default should be {{{}file-lock{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-243) Get rid of pre-Java 5 constructs that are cryptic
[ https://issues.apache.org/jira/browse/MRESOLVER-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-243: -- Fix Version/s: 2.0.0 > Get rid of pre-Java 5 constructs that are cryptic > - > > Key: MRESOLVER-243 > URL: https://issues.apache.org/jira/browse/MRESOLVER-243 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > There are in some places (ChecksumPolicy kind was already fixed) still in > codebase, that use pre-enum constructs. Kill them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-329. - Resolution: Fixed Seems related spots are fixed > Make IO in DefaultTrackingFileManager more robust > - > > Key: MRESOLVER-329 > URL: https://issues.apache.org/jira/browse/MRESOLVER-329 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > > There are couple of spots where implementation naively assumes is alone > running process on this world. Several user reports suggests this is not the > case, like MRESOLVER-325 or MNG-7705. Fix these spots. > Still, something is fishy, as it seems these files (all that are handled by > DefaultTrackingFileManager) are not subject to locking? This needs > investigation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
[
https://issues.apache.org/jira/browse/MNG-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806552#comment-17806552
]
Michael Osipov commented on MNG-8017:
-
I am trying to figure out why it is failing for me because there should be
{{infocmp}} installed with the base system...
> Maven fails at start with "Cannot run program "infocmp": error=2, No such
> file or directory"
>
>
> Key: MNG-8017
> URL: https://issues.apache.org/jira/browse/MNG-8017
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 4.0.0-alpha-13
> Environment: Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
>Reporter: Michael Osipov
>Priority: Critical
>
> From {{mvn -v}}:
> {noformat}
> mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
> $ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
> Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
> WARNUNG: Unable to retrieve infocmp for type xterm-color
> java.io.IOException: Cannot run program "infocmp": error=2, No such file or
> directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
> at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
> at
> org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
> at
> org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
> at
> org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
> at
> org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
> at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
> at
> org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: java.io.IOException: error=2, No such file or directory
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:251)
> at java.lang.ProcessImpl.start(ProcessImpl.java:134)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
> ... 17 more
> Apache Maven 4.0.0-alpha-13-SNAPSHOT
> (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
> Maven home:
> /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
> Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
> /usr/local/openjdk8/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-334) Maven Resolver's GenericVersionScheme diverges from the spec
[
https://issues.apache.org/jira/browse/MRESOLVER-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-334:
--
Fix Version/s: 2.0.0
> Maven Resolver's GenericVersionScheme diverges from the spec
>
>
> Key: MRESOLVER-334
> URL: https://issues.apache.org/jira/browse/MRESOLVER-334
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: 2.0.0
>
>
> The [specification for version
> resolution|https://maven.apache.org/pom.html#version-order-specification]
> indicates these facts which disagree with the implementation in
> {{{}GenericVersionScheme{}}}:
> * "The Maven coordinate is split in tokens between dots ('{{{}.{}}}'),
> hyphens ('{{{}-{}}}') and transitions between digits and characters." - in
> {{{}GenericVersion{}}}, the underscore ('{{{}_{}}}') is also treated as a
> separator.
> * In the examples area, it says that while "{{{}1-sp.1{}}}" {{>}}
> "{{{}1-ga.1{}}}", at the same time "{{{}1-sp-1{}}}" {{<}} "{{{}1-ga-1{}}}"
> {{=}} "{{{}1-1{}}}" due to "trailing 'null' values at each hyphen". But in
> addition to being untrue in the actual implementation, this relation is
> clearly nonsensical because it would place {{sp}} before {{{}ga{}}}, which
> would have a tremendous negative impact on the existing artifact ecosystem if
> it were carried out in the implementation.
> * Also in the example area, we have "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}"
> {{<}} "{{{}1-1{}}}" {{<}} "{{{}1.1{}}}", whereas in practice it is (rightly)
> "{{{}1.foo{}}}" {{=}} "{{{}1-foo{}}}" {{<}} "{{{}1-1{}}}" {{=}} "{{{}1.1{}}}".
> In my opinion all of these things are spec errors so I'd be happy to see the
> spec page be updated and this bug consequently closed as "out of date",
> especially since the implementation behavior has been in the wild for some
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-336:
--
Fix Version/s: 2.0.0
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Priority: Major
> Fix For: 2.0.0
>
>
> Given the following:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 0.0.0.ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. 0.0.0.ga.ga.foo -> 0.0.0.ga.ga.foo; tokens: [0, 0, 0, foo]
>0.0.0.ga.ga.foo == foo
> 2. foo -> foo; tokens: [foo]
> {code}
> This is expected iff zero-prefixed qualifiers are considered equal to the
> bare qualifier, which does seem to be the case *mostly*. However, we also
> have this:
> {code}
> $ jbang --main=org.eclipse.aether.util.version.GenericVersionScheme
> org.apache.maven.resolver:maven-resolver-util:1.9.5 ga.ga.foo foo
> Display parameters as parsed by Maven Resolver (in canonical form and as a
> list of tokens) and comparison result:
> 1. ga.ga.foo -> ga.ga.foo; tokens: [0, 0, foo]
>ga.ga.foo < foo
> 2. foo -> foo; tokens: [foo]
> {code}
> In this case we have "zero"-valued qualifiers but no leading numerical
> segment, which unexpectedly changes the parsing rules. I would expect
> {{ga.ga.foo == foo}} as above. Is this a bug? Is there an explanation for
> this behavior? The spec doesn't seem to directly address this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-425) Session should carry VersionScheme?
[ https://issues.apache.org/jira/browse/MRESOLVER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-425. - Resolution: Won't Fix Bad idea > Session should carry VersionScheme? > --- > > Key: MRESOLVER-425 > URL: https://issues.apache.org/jira/browse/MRESOLVER-425 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > > This is just an idea, but: maybe RepositorySystemSession should carry > VersionScheme as well? Currently Maven defines it as "component" (see > MNG-7103), while IMHO a more "flexible" way to manage version schemes are > needed. > But again, resolver really does not use version scheme, merely > dependencyFilter ctors accept it only... -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-463) Ensure checksum record file (summary fie) is sorted by artifact relative path and not checksum
[ https://issues.apache.org/jira/browse/MRESOLVER-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806550#comment-17806550 ] ASF GitHub Bot commented on MRESOLVER-463: -- cstamas commented on PR #404: URL: https://github.com/apache/maven-resolver/pull/404#issuecomment-1891068656 If am not mistaken, this can easily be backported to Resolver 1.x as well... There are no issues scheduled for 1.9.18, but still... > Ensure checksum record file (summary fie) is sorted by artifact relative path > and not checksum > -- > > Key: MRESOLVER-463 > URL: https://issues.apache.org/jira/browse/MRESOLVER-463 > Project: Maven Resolver > Issue Type: Task >Affects Versions: 2.0.0-alpha-6 >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-7 > > > Goal is to navigate in the file manually more easily - tools don't need to > navigate from vi anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-463] sort checksum summary file per path and not checksum to be human friendly [maven-resolver]
cstamas commented on PR #404: URL: https://github.com/apache/maven-resolver/pull/404#issuecomment-1891068656 If am not mistaken, this can easily be backported to Resolver 1.x as well... There are no issues scheduled for 1.9.18, but still... -- 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-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
[
https://issues.apache.org/jira/browse/MNG-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-8017:
Description:
>From {{mvn -v}}:
{noformat}
mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
$ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
WARNUNG: Unable to retrieve infocmp for type xterm-color
java.io.IOException: Cannot run program "infocmp": error=2, No such file or
directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
at
org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
at
org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
at
org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
at
org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
at org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
at
org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:251)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 17 more
Apache Maven 4.0.0-alpha-13-SNAPSHOT (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
Maven home: /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
/usr/local/openjdk8/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
{noformat}
was:
>From {{mvn -v}}:
{noformat}
mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
$ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
WARNUNG: Unable to retrieve infocmp for type xterm-color
java.io.IOException: Cannot run program "infocmp": error=2, No such file or
directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
at
org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
at
org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
at
org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
at
org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
at org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
at
org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:251)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 17 more
Apache
[jira] [Updated] (MRESOLVER-463) Ensure checksum record file (summary fie) is sorted by artifact relative path and not checksum
[ https://issues.apache.org/jira/browse/MRESOLVER-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-463: -- Fix Version/s: 2.0.0 > Ensure checksum record file (summary fie) is sorted by artifact relative path > and not checksum > -- > > Key: MRESOLVER-463 > URL: https://issues.apache.org/jira/browse/MRESOLVER-463 > Project: Maven Resolver > Issue Type: Task >Affects Versions: 2.0.0-alpha-6 >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-7 > > > Goal is to navigate in the file manually more easily - tools don't need to > navigate from vi anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-463) Ensure checksum record file (summary fie) is sorted by artifact relative path and not checksum
[ https://issues.apache.org/jira/browse/MRESOLVER-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-463: -- Fix Version/s: 2.0.0-alpha-7 > Ensure checksum record file (summary fie) is sorted by artifact relative path > and not checksum > -- > > Key: MRESOLVER-463 > URL: https://issues.apache.org/jira/browse/MRESOLVER-463 > Project: Maven Resolver > Issue Type: Task >Affects Versions: 2.0.0-alpha-6 >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: 2.0.0-alpha-7 > > > Goal is to navigate in the file manually more easily - tools don't need to > navigate from vi anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8017) Maven fails at start with "Cannot run program "infocmp": error=2, No such file or directory"
Michael Osipov created MNG-8017:
---
Summary: Maven fails at start with "Cannot run program "infocmp":
error=2, No such file or directory"
Key: MNG-8017
URL: https://issues.apache.org/jira/browse/MNG-8017
Project: Maven
Issue Type: Bug
Components: Command Line
Affects Versions: 4.0.0-alpha-13
Environment: Apache Maven 4.0.0-alpha-13-SNAPSHOT
(7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
Maven home: /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
/usr/local/openjdk8/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
Reporter: Michael Osipov
>From {{mvn -v}}:
{noformat}
mosipov@bsd1srv:/usr/home/mosipov/var/Projekte/maven (master =)
$ ../apache-maven-4.0.0-alpha-13-SNAPSHOT/bin/mvn -v
Jan 14, 2024 9:30:35 PM org.jline.utils.Log logr
WARNUNG: Unable to retrieve infocmp for type xterm-color
java.io.IOException: Cannot run program "infocmp": error=2, No such file or
directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at org.jline.utils.InfoCmp.getInfoCmp(InfoCmp.java:544)
at
org.jline.terminal.impl.AbstractTerminal.parseInfoCmp(AbstractTerminal.java:207)
at
org.jline.terminal.impl.PosixSysTerminal.(PosixSysTerminal.java:47)
at
org.jline.terminal.impl.exec.ExecTerminalProvider.posixSysTerminal(ExecTerminalProvider.java:100)
at
org.jline.terminal.impl.exec.ExecTerminalProvider.sysTerminal(ExecTerminalProvider.java:66)
at org.jline.terminal.TerminalBuilder.doBuild(TerminalBuilder.java:428)
at org.jline.terminal.TerminalBuilder.build(TerminalBuilder.java:362)
at
org.apache.maven.cli.jline.MessageUtils.systemInstall(MessageUtils.java:47)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:251)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 17 more
Apache Maven 4.0.0-alpha-13-SNAPSHOT (7f70467aa3e74a9bba602e5c61a0b5d33ae8f699)
Maven home: /usr/home/mosipov/var/Projekte/apache-maven-4.0.0-alpha-13-SNAPSHOT
Java version: 1.8.0_382, vendor: OpenJDK BSD Porting Team, runtime:
/usr/local/openjdk8/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "freebsd", version: "13.2-release-p8", arch: "amd64", family: "unix"
{noformat}
There is no {{infocmp}} on FreeBSD.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [EXPERIMENT] MT model builder [maven]
cstamas closed pull request #1379: [EXPERIMENT] MT model builder URL: https://github.com/apache/maven/pull/1379 -- 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-504) [regression] Goal prefix is required now
[ https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806517#comment-17806517 ] Romain Manni-Bucau commented on MPLUGIN-504: +1 to enhance the error message with a sample of the actual conf to inject in the plugin and keep the error to ensure any plugin owns its prefix, ideally the sample would log the heuristic goal prefix mentionning it can be customized if needed IMHO. > [regression] Goal prefix is required now > > > Key: MPLUGIN-504 > URL: https://issues.apache.org/jira/browse/MPLUGIN-504 > Project: Maven Plugin Tools > Issue Type: Bug >Reporter: Christoph Läubrich >Priority: Major > > With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression > introduced that leads to previous working builds fail if the have not > configured a goalprefix, the error message is: > > You need to specify a goalPrefix as it can not be correctly computed > This has several issues: > # It does not explain why one "needs" a goalPrefix, nor what it is useful for > or why it can not be correctly computed. > # It is effectively a breaking change in a minor version increment > # The inital JIRA mentions that > a) in general, goal prefix is *+optional+*, but "good to have", and usually > is present. > b) we may want to have some option to turn off this feature > # Now it is required and there is no option to turn it off > Also the message is not true, the plugin has successfully computed a prefix > before without any issues: > * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the > my-cool was chosen > * If the artifact ends with -plugin as in my-cool-plugin the my-cool was > chosen > * otherwise the full artifact if was chosen as a prefix as in my-cool the > my-cool was chosen > From a users point of view I don't see any problem or "disambiguates" with > this approach that justifies a breaking change here, anyone who is concerned > about not using this default can and already could choose a prefix and seem > to been fine with it for a long time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806516#comment-17806516 ] ASF GitHub Bot commented on MPLUGIN-450: rmannibucau commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891047013 > I don't see any issue that can arise from the default (beside that the prefix is maybe longer than one wants) but why enforce it to specify what the plugin was able to decide for years without a problem? We got issues with plugins wrongly naming the artifactId (not respecting `foo-maven-plugin`) or misusing `plugin` in the name leading to a surprising name. > Also not that there is a lot of plugins that will never really be called from cli All plugins can be called at some point from the cli. An example is git-commit-id plugin, it is never supposed to be called from the cli...but it is, so as a maven dev you can't assume that and the actual assumption would be "most plugin will be called at some point from the cli". Keep in mind you can reproduce the full lifecycle from the CLI. Useless? not from a CI perspective (enables to add phases depending the env or ex). > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-450] Require goalPrefix to be valid [maven-plugin-tools]
rmannibucau commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891047013 > I don't see any issue that can arise from the default (beside that the prefix is maybe longer than one wants) but why enforce it to specify what the plugin was able to decide for years without a problem? We got issues with plugins wrongly naming the artifactId (not respecting `foo-maven-plugin`) or misusing `plugin` in the name leading to a surprising name. > Also not that there is a lot of plugins that will never really be called from cli All plugins can be called at some point from the cli. An example is git-commit-id plugin, it is never supposed to be called from the cli...but it is, so as a maven dev you can't assume that and the actual assumption would be "most plugin will be called at some point from the cli". Keep in mind you can reproduce the full lifecycle from the CLI. Useless? not from a CI perspective (enables to add phases depending the env or ex). -- 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-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806512#comment-17806512 ] ASF GitHub Bot commented on MPLUGIN-450: laeubi commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891045019 I have now created: - https://issues.apache.org/jira/browse/MPLUGIN-504 I don't see any issue that can arise from the default (beside that the prefix is maybe longer than one wants) but why *enforce* it to specify what the plugin was able to decide for years without a problem? Also not that there is a lot of plugins that will never really be called from cli so it is not true that before there was **no** prefix, it has always chosen one that seem to fit most purposes. > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-504) [regression] Goal prefix is required now
Christoph Läubrich created MPLUGIN-504: -- Summary: [regression] Goal prefix is required now Key: MPLUGIN-504 URL: https://issues.apache.org/jira/browse/MPLUGIN-504 Project: Maven Plugin Tools Issue Type: Bug Reporter: Christoph Läubrich With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression introduced that leads to previous working builds fail if the have not configured a goalprefix, the error message is: > You need to specify a goalPrefix as it can not be correctly computed This has several issues: # It does not explain why one "needs" a goalPrefix, nor what it is useful for or why it can not be correctly computed. # It is effectively a breaking change in a minor version increment # The inital JIRA mentions that a) in general, goal prefix is *+optional+*, but "good to have", and usually is present. b) we may want to have some option to turn off this feature # Now it is required and there is no option to turn it off Also the message is not true, the plugin has successfully computed a prefix before without any issues: * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the my-cool was chosen * If the artifact ends with -plugin as in my-cool-plugin the my-cool was chosen * otherwise the full artifact if was chosen as a prefix as in my-cool the my-cool was chosen >From a users point of view I don't see any problem or "disambiguates" with >this approach that justifies a breaking change here, anyone who is concerned >about not using this default can and already could choose a prefix and seem to >been fine with it for a long time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806511#comment-17806511 ] ASF GitHub Bot commented on MPLUGIN-450: rmannibucau commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891041901 > I also see some risk that different plugins now they are forced to, choose some prefix that clashes in the name. AFAIK it always had been the case, the heuristic always had been considered bad but put there by compatibility when it got realized. The fact plugin prefix is an identifier in a build - you can extend it to globally on a pure theorical standpoint - had the issue you mention but only if you call it from the CLI using the prefix - else it is ignored and not used - and if we want to drop that constraint that it means we'll not enable to call `prefix:goal` but will enforce `ga[v]:goal` which is a joke from a CLI standpoint so guess we'll probably stay in the current status and maybe just log the heuristic and show the plugin configuration to set to stay in the same status, was not an issue before, it will not be tomorrow ;). > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-450] Require goalPrefix to be valid [maven-plugin-tools]
rmannibucau commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891041901 > I also see some risk that different plugins now they are forced to, choose some prefix that clashes in the name. AFAIK it always had been the case, the heuristic always had been considered bad but put there by compatibility when it got realized. The fact plugin prefix is an identifier in a build - you can extend it to globally on a pure theorical standpoint - had the issue you mention but only if you call it from the CLI using the prefix - else it is ignored and not used - and if we want to drop that constraint that it means we'll not enable to call `prefix:goal` but will enforce `ga[v]:goal` which is a joke from a CLI standpoint so guess we'll probably stay in the current status and maybe just log the heuristic and show the plugin configuration to set to stay in the same status, was not an issue before, it will not be tomorrow ;). -- 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] (DOXIA-724) Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
[
https://issues.apache.org/jira/browse/DOXIA-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806510#comment-17806510
]
ASF GitHub Bot commented on DOXIA-724:
--
michael-o commented on code in PR #195:
URL: https://github.com/apache/maven-doxia/pull/195#discussion_r1451786289
##
doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java:
##
@@ -95,11 +95,12 @@ public interface Parser {
void addSinkWrapperFactory(SinkWrapperFactory factory);
/**
- *
- * @return all sink wrapper factories in the correct order (both
registered automatically and manually)
+ * Returns all sink wrapper factories (both registered automatically and
manually). The collection is ordered in a way that
+ * the factories having the lowest priority come first (i.e. in reverse
order).
+ * @return all sink wrapper factories in the reverse order
* @since 2.0.0
*/
-Collection getSinkWrapperFactories();
+List getSinkWrapperFactories();
Review Comment:
The drop it from `Parser` altogether, no?
> Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
>
>
> Key: DOXIA-724
> URL: https://issues.apache.org/jira/browse/DOXIA-724
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> According to the javadoc the SinkWrapperFactory should be ordered according
> to their priority from highest to lowest. However in
> {{AbstractParser.getWrappedSink()}} a pipeline is returned which has no
> predictable order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-724] Fix order of sink wrappers in pipeline [maven-doxia]
michael-o commented on code in PR #195:
URL: https://github.com/apache/maven-doxia/pull/195#discussion_r1451786289
##
doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java:
##
@@ -95,11 +95,12 @@ public interface Parser {
void addSinkWrapperFactory(SinkWrapperFactory factory);
/**
- *
- * @return all sink wrapper factories in the correct order (both
registered automatically and manually)
+ * Returns all sink wrapper factories (both registered automatically and
manually). The collection is ordered in a way that
+ * the factories having the lowest priority come first (i.e. in reverse
order).
+ * @return all sink wrapper factories in the reverse order
* @since 2.0.0
*/
-Collection getSinkWrapperFactories();
+List getSinkWrapperFactories();
Review Comment:
The drop it from `Parser` altogether, no?
--
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] (MCHANGES-421) Typo in changes.xsd
[ https://issues.apache.org/jira/browse/MCHANGES-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806509#comment-17806509 ] ASF GitHub Bot commented on MCHANGES-421: - michael-o commented on PR #30: URL: https://github.com/apache/maven-changes-plugin/pull/30#issuecomment-1891041505 > @michael-o is there a chance to publish the new XSD? Thanks for your help and sorry to hear about the project's state. Done. > Typo in changes.xsd > --- > > Key: MCHANGES-421 > URL: https://issues.apache.org/jira/browse/MCHANGES-421 > Project: Maven Changes Plugin > Issue Type: Bug >Affects Versions: 2.12.1 >Reporter: Philipp Ottlinger >Assignee: Michael Osipov >Priority: Major > Fix For: backlog > > > While wondering which types to fill in as action type I stumbled upon > https://maven.apache.org/plugins/maven-changes-plugin/xsd/changes-1.0.0.xsd > and realized that there are typos: > It should be "functionality" instead of "functionnality" > As I was unable to spot the file in the repo of maven-changes-plugin I > thought creating a bugticket might be an easier way to get those trivial > fixes into the XSD. > Thanks -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] MCHANGES-421: Fix typos in changes.mdo [maven-changes-plugin]
michael-o commented on PR #30: URL: https://github.com/apache/maven-changes-plugin/pull/30#issuecomment-1891041505 > @michael-o is there a chance to publish the new XSD? Thanks for your help and sorry to hear about the project's state. Done. -- 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] (DOXIASITETOOLS-303) Implement workaround for MNG-7758/MRESOLVER-335
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806508#comment-17806508 ] Michael Osipov commented on DOXIASITETOOLS-303: --- I do not object, but that would also mean at least that the cherry pick works without conficts and someone is willing to release Sitetools along with Maven Site Plugin and maybe the reporting plugins. > Implement workaround for MNG-7758/MRESOLVER-335 > --- > > Key: DOXIASITETOOLS-303 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-303 > Project: Maven Doxia Sitetools > Issue Type: Task > Components: Integration Tools >Affects Versions: 2.0.0-M7 >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 2.0.0-M8, 2.0.0 > > > Details see tickets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806507#comment-17806507 ] ASF GitHub Bot commented on MPLUGIN-450: michael-o commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891039908 > @gnodet the JIRA mentions > > > but we may want to have some option to turn off this feature > > but it seems there is no such option as far as I can see? > > Can the "heuristics" maybe be enhanced to also accept `-plugin` and using then as a `prefix`? This seems to be the previous behavior here in fact. > > e.g in Tycho there are several plugins named e.g. `tycho--plugin` and having them all renamed /relocated to `tycho--maven-plugin` seems not really usefull, also configuring a prefix for each of them is possible we never needed any nor used any prefix as the most natural choice would be `tycho` for all plugins but that seems not possible > > I also see some risk that different plugins now they are forced to, choose some prefix that clashes in the name. You should file a JIRA issue for any request which we can explore together... > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MPLUGIN-450] Require goalPrefix to be valid [maven-plugin-tools]
michael-o commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891039908 > @gnodet the JIRA mentions > > > but we may want to have some option to turn off this feature > > but it seems there is no such option as far as I can see? > > Can the "heuristics" maybe be enhanced to also accept `-plugin` and using then as a `prefix`? This seems to be the previous behavior here in fact. > > e.g in Tycho there are several plugins named e.g. `tycho--plugin` and having them all renamed /relocated to `tycho--maven-plugin` seems not really usefull, also configuring a prefix for each of them is possible we never needed any nor used any prefix as the most natural choice would be `tycho` for all plugins but that seems not possible > > I also see some risk that different plugins now they are forced to, choose some prefix that clashes in the name. You should file a JIRA issue for any request which we can explore together... -- 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-450) Make goal prefix mandatory by default
[ https://issues.apache.org/jira/browse/MPLUGIN-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806506#comment-17806506 ] ASF GitHub Bot commented on MPLUGIN-450: laeubi commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891038293 @gnodet the JIRA mentions > but we may want to have some option to turn off this feature but it seems there is no such option as far as I can see? Can the "heuristics" maybe be enhanced to also accept `-plugin` and using then as a `prefix`? e.g in Tycho there are several plugins named e.g. `tycho--plugin` and having them all renamed /relocated to `tycho--maven-plugin` seems not really usefull, also configuring a prefix for each of them is possible we never needed any nor used any prefix as the most natural choice would be `tycho` for all plugins but that seems not possible I also see some risk that different plugins now they are forced to, choose some prefix that clashes in the name. > Make goal prefix mandatory by default > - > > Key: MPLUGIN-450 > URL: https://issues.apache.org/jira/browse/MPLUGIN-450 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.11.0 > > > The goal prefix currently is not mandatory, and plugin uses heuristic to > figure it out, if possible (xxx-maven-plugin or maven-xxx-plugin, latter for > org.apache.maven plugins ONLY). > In general, goal prefix is optional, but "good to have", and usually is > present. > Cases when is not present, is when heuristics fails (so plugin module is not > named as "xxx-maven-plugin" or "maven-xxx-plugin") and user did not provide > one either. The cases when prefix is not present is mostly unintentional, but > maven-plugin-plugin leaves this without any remark or warning. > IMHO, the maven-plugin-plugin should either warn, or even fail the build in > case when goal prefix is not present, but we may want to have some option to > turn off this feature (for me unknown reasons, where it would be expected to > NOT have goal prefix for a reason). > TL;DR Am pretty much sure that in most of the cases when plugin developer > ends up with plugin without prefix, that it was unintentional (and causes > surprise later, not to mention refactoring the module name or POM change to > configure it), while there MAY be cases where goal prefix is not desired for > some reason (ie. plugin not mentioned for manual/CLI invocation). Simply put, > the out of the box defaults should enforce presence of it, while advanced > users still can produce prefix-less plugins with some extra configuration. > This would make things more explicit as well: even if plugin is named as > xxx-maven-plugin, configuration would be clear I do not want prefix for it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIASITETOOLS-303) Implement workaround for MNG-7758/MRESOLVER-335
[
https://issues.apache.org/jira/browse/DOXIASITETOOLS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806505#comment-17806505
]
Konrad Windszus commented on DOXIASITETOOLS-303:
[~michael-o] Given that this is not fixed in the most recent Maven version WDYT
about backporting to Doxia Sitetools 1.x? I am running into it with
{{org.apache.maven.doxia:doxia-integration-tools:jar:1.11.1}} referenced in
https://github.com/apache/maven-project-info-reports-plugin/blob/28ac4b55b4b3476302bcd9814516ad66aea3afca/pom.xml#L315...
> Implement workaround for MNG-7758/MRESOLVER-335
> ---
>
> Key: DOXIASITETOOLS-303
> URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-303
> Project: Maven Doxia Sitetools
> Issue Type: Task
> Components: Integration Tools
>Affects Versions: 2.0.0-M7
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 2.0.0-M8, 2.0.0
>
>
> Details see tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MPOM-453] Disable annotation processing by compiler [maven-parent]
slawekjaranowski commented on PR #157: URL: https://github.com/apache/maven-parent/pull/157#issuecomment-1891022896 We use `sisu-maven-plugin` for generating list of components, so should be ok. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MPOM-453] Disable annotation processing by compiler [maven-parent]
cstamas commented on PR #157: URL: https://github.com/apache/maven-parent/pull/157#issuecomment-1891022212 This can be a problem, as now way to override this later (only in java 20? "full"?) @bmarwell will tell :smile: -- 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-459) Bump org.apache.maven.plugins:maven-jxr-plugin from 3.3.1 to 3.3.2
Slawomir Jaranowski created MPOM-459: Summary: Bump org.apache.maven.plugins:maven-jxr-plugin from 3.3.1 to 3.3.2 Key: MPOM-459 URL: https://issues.apache.org/jira/browse/MPOM-459 Project: Maven POMs Issue Type: Dependency upgrade Reporter: Slawomir Jaranowski Assignee: Slawomir Jaranowski Fix For: MAVEN-42 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MARCHETYPES-81) generate maven.compiler.target 8 instead of 1.8
[ https://issues.apache.org/jira/browse/MARCHETYPES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806503#comment-17806503 ] ASF GitHub Bot commented on MARCHETYPES-81: --- judovana commented on code in PR #27: URL: https://github.com/apache/maven-archetypes/pull/27#discussion_r1451778377 ## maven-archetype-quickstart/src/test/resources/projects/it-java-7/archetype.properties: ## @@ -2,4 +2,4 @@ groupId=archetype.it artifactId=java-8-quickstart version=0.1-SNAPSHOT package=it.pkg -javaCompilerVersion=1.7 +javaCompilerVersion=7 Review Comment: Thanx! > generate maven.compiler.target 8 instead of 1.8 > --- > > Key: MARCHETYPES-81 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-81 > Project: Maven Archetype Bundles > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 1.5 > > > target bytecode is configured as 1.x because it is an habit from old times > with JDK 1.4 > since JDK 5, javac supports 5 as an alias for 1.5: this is the same for 6, 7 > and 8 > and since 9, only 9 exists, not even 1.9 > configuring 8 instead of 1.8 gives better habit for nowadays -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MARCHETYPES-81] generate target 8 instead of 1.8 [maven-archetypes]
judovana commented on code in PR #27: URL: https://github.com/apache/maven-archetypes/pull/27#discussion_r1451778377 ## maven-archetype-quickstart/src/test/resources/projects/it-java-7/archetype.properties: ## @@ -2,4 +2,4 @@ groupId=archetype.it artifactId=java-8-quickstart version=0.1-SNAPSHOT package=it.pkg -javaCompilerVersion=1.7 +javaCompilerVersion=7 Review Comment: Thanx! -- 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] (MPOM-264) Parameterize maven-compiler-plugin with parameter "release" when running on JDK 9+
[
https://issues.apache.org/jira/browse/MPOM-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806502#comment-17806502
]
Slawomir Jaranowski commented on MPOM-264:
--
Done in MPOM-447
> Parameterize maven-compiler-plugin with parameter "release" when running on
> JDK 9+
> --
>
> Key: MPOM-264
> URL: https://issues.apache.org/jira/browse/MPOM-264
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Affects Versions: ASF-23
>Reporter: Konrad Windszus
>Priority: Major
>
> Instead of using {{source}} and {{target}} the new parameter {{release}}
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release)
> should be used with Java 9+ as that also checks whether the used API is
> provided in the target Java release
> (https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> To be able to support both compilation with Java < 9 and above a profile
> should be used which either configures {{source}} and {{target}} or
> {{release}}.
> You have to observe though that the parameter values are different though,
> as the former supports 1.6, 1.7 and 1.8 while the latter only supports 6, 7
> and 8.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MPOM-264) Parameterize maven-compiler-plugin with parameter "release" when running on JDK 9+
[
https://issues.apache.org/jira/browse/MPOM-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806502#comment-17806502
]
Slawomir Jaranowski edited comment on MPOM-264 at 1/14/24 5:53 PM:
---
Done in MPOM-447 for Maven parent
was (Author: slawekjaranowski):
Done in MPOM-447
> Parameterize maven-compiler-plugin with parameter "release" when running on
> JDK 9+
> --
>
> Key: MPOM-264
> URL: https://issues.apache.org/jira/browse/MPOM-264
> Project: Maven POMs
> Issue Type: Improvement
> Components: asf
>Affects Versions: ASF-23
>Reporter: Konrad Windszus
>Priority: Major
>
> Instead of using {{source}} and {{target}} the new parameter {{release}}
> (https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release)
> should be used with Java 9+ as that also checks whether the used API is
> provided in the target Java release
> (https://docs.oracle.com/javase/9/tools/javac.htm#GUID-AEEC9F07-CB49-4E96-8BC7-BCC2C7F725C9__GUID-D343F6B4-3FDD-43A8-AD24-43DD70214471).
> To be able to support both compilation with Java < 9 and above a profile
> should be used which either configures {{source}} and {{target}} or
> {{release}}.
> You have to observe though that the parameter values are different though,
> as the former supports 1.6, 1.7 and 1.8 while the latter only supports 6, 7
> and 8.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPOM-449) Remove the leading "1." from source/target properties
[
https://issues.apache.org/jira/browse/MPOM-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806500#comment-17806500
]
Herve Boutemy commented on MPOM-449:
I tested with older maven-compiler-plugin up to 2.1 and it worked
> Remove the leading "1." from source/target properties
> -
>
> Key: MPOM-449
> URL: https://issues.apache.org/jira/browse/MPOM-449
> Project: Maven POMs
> Issue Type: Bug
> Components: maven
>Affects Versions: MAVEN-41
>Reporter: Tamas Cservenak
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: MAVEN-42
>
>
> The parent 41 has these lines:
> {noformat}
> 1.${javaVersion}
> 1.${javaVersion} {noformat}
> This makes any Java above 9 defunct (and we do not go below 8, so it works
> for only two versions). If you try to use 11, 17 or oh my god 21, you end up
> with "1.11", "1.17" and "1.21" subsequently. While for javac this is not a
> biggie (it will ignore this if release set, and hopefully is), but
> reporting/site/whatever craps out badly on this.
> Remove the prefix "1.", and let those on 8 use 1.8 instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPMD-391) Log what developers care about and not what they don't
[ https://issues.apache.org/jira/browse/MPMD-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806499#comment-17806499 ] Michael Osipov commented on MPMD-391: - You are conflating many things: output of PMD, the plugin and Maven. > Log what developers care about and not what they don't > -- > > Key: MPMD-391 > URL: https://issues.apache.org/jira/browse/MPMD-391 > Project: Maven PMD Plugin > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Major > > Here's output from a recent PMD plugin run that failed: > [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] Rendering content with > org.apache.maven.skins:maven-default-skin:jar:1.3 skin. > [INFO] > [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< > [INFO] > [INFO] > [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- > [INFO] PMD version: 6.55.0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 05:22 min > [INFO] Finished at: 2024-01-14T14:11:30Z > [INFO] > > Error: Failed to execute goal > org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on > project commons-io: You have 1 PMD violation. For more details see: > /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] > Error: > Error: To see the full stack trace of the errors, re-run Maven with the -e > switch. > Error: Re-run Maven using the -X switch to enable full debug logging. > Error: > Error: For more information about the errors and possible solutions, please > read the following articles: > Error: [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > Error: Process completed with exit code 1. > Things I don't care about that are printed: > * PMD version > * Doxia skin > * Blank lines > * Total time > * Timestamp when it finished > * Generic information about Mojo failures > * Exit code from Mojo > The one thing I care about: > * The actual error that caused the failure > Everything in the first list can be hidden in some random log file no one > will ever look at. Everything in the second list should be front and center. > Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MARCHETYPES-82) generate maven.compiler.release property as comment
[
https://issues.apache.org/jira/browse/MARCHETYPES-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806498#comment-17806498
]
ASF GitHub Bot commented on MARCHETYPES-82:
---
hboutemy commented on code in PR #28:
URL: https://github.com/apache/maven-archetypes/pull/28#discussion_r1451770820
##
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
##
@@ -6,6 +6,7 @@
#else
${javaCompilerVersionLocal}
${javaCompilerVersionLocal}
+
Review Comment:
#27 merged, I'll rebase: this will ease understanding the scope of this
precise PR
> generate maven.compiler.release property as comment
> ---
>
> Key: MARCHETYPES-82
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-82
> Project: Maven Archetype Bundles
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Herve Boutemy
>Priority: Major
> Fix For: 1.5
>
>
> if JDK 11+ is used to compile, it's better to define maven.compiler.release
> instead of maven.compiler.source/target
> we currently generate for Java 8, so we don't really know if the compiler
> used support release parameter
> adding a comment is a good first step to help discovery, before benefiting
> from MARCHETYPES-70 when generating against newer JDK
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MARCHETYPES-82] generate comments for maven.compiler.release [maven-archetypes]
hboutemy commented on code in PR #28:
URL: https://github.com/apache/maven-archetypes/pull/28#discussion_r1451770820
##
maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml:
##
@@ -6,6 +6,7 @@
#else
${javaCompilerVersionLocal}
${javaCompilerVersionLocal}
+
Review Comment:
#27 merged, I'll rebase: this will ease understanding the scope of this
precise PR
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Closed] (MARCHETYPES-81) generate maven.compiler.target 8 instead of 1.8
[ https://issues.apache.org/jira/browse/MARCHETYPES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MARCHETYPES-81. Assignee: Herve Boutemy Resolution: Fixed > generate maven.compiler.target 8 instead of 1.8 > --- > > Key: MARCHETYPES-81 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-81 > Project: Maven Archetype Bundles > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 1.5 > > > target bytecode is configured as 1.x because it is an habit from old times > with JDK 1.4 > since JDK 5, javac supports 5 as an alias for 1.5: this is the same for 6, 7 > and 8 > and since 9, only 9 exists, not even 1.9 > configuring 8 instead of 1.8 gives better habit for nowadays -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MARCHETYPES-81) generate maven.compiler.target 8 instead of 1.8
[ https://issues.apache.org/jira/browse/MARCHETYPES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806496#comment-17806496 ] ASF GitHub Bot commented on MARCHETYPES-81: --- hboutemy merged PR #27: URL: https://github.com/apache/maven-archetypes/pull/27 > generate maven.compiler.target 8 instead of 1.8 > --- > > Key: MARCHETYPES-81 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-81 > Project: Maven Archetype Bundles > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Herve Boutemy >Priority: Major > Fix For: 1.5 > > > target bytecode is configured as 1.x because it is an habit from old times > with JDK 1.4 > since JDK 5, javac supports 5 as an alias for 1.5: this is the same for 6, 7 > and 8 > and since 9, only 9 exists, not even 1.9 > configuring 8 instead of 1.8 gives better habit for nowadays -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MARCHETYPES-81) generate maven.compiler.target 8 instead of 1.8
[ https://issues.apache.org/jira/browse/MARCHETYPES-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806495#comment-17806495 ] ASF GitHub Bot commented on MARCHETYPES-81: --- hboutemy commented on code in PR #27: URL: https://github.com/apache/maven-archetypes/pull/27#discussion_r1451770167 ## maven-archetype-quickstart/src/test/resources/projects/it-java-7/archetype.properties: ## @@ -2,4 +2,4 @@ groupId=archetype.it artifactId=java-8-quickstart version=0.1-SNAPSHOT package=it.pkg -javaCompilerVersion=1.7 +javaCompilerVersion=7 Review Comment: you can build and see it works but this is a good question that I had myself previously: what precisely makes this work? I summarised my findings in https://issues.apache.org/jira/browse/MPOM-449 > generate maven.compiler.target 8 instead of 1.8 > --- > > Key: MARCHETYPES-81 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-81 > Project: Maven Archetype Bundles > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Herve Boutemy >Priority: Major > Fix For: 1.5 > > > target bytecode is configured as 1.x because it is an habit from old times > with JDK 1.4 > since JDK 5, javac supports 5 as an alias for 1.5: this is the same for 6, 7 > and 8 > and since 9, only 9 exists, not even 1.9 > configuring 8 instead of 1.8 gives better habit for nowadays -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MARCHETYPES-81] generate target 8 instead of 1.8 [maven-archetypes]
hboutemy merged PR #27: URL: https://github.com/apache/maven-archetypes/pull/27 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MARCHETYPES-81] generate target 8 instead of 1.8 [maven-archetypes]
hboutemy commented on code in PR #27: URL: https://github.com/apache/maven-archetypes/pull/27#discussion_r1451770167 ## maven-archetype-quickstart/src/test/resources/projects/it-java-7/archetype.properties: ## @@ -2,4 +2,4 @@ groupId=archetype.it artifactId=java-8-quickstart version=0.1-SNAPSHOT package=it.pkg -javaCompilerVersion=1.7 +javaCompilerVersion=7 Review Comment: you can build and see it works but this is a good question that I had myself previously: what precisely makes this work? I summarised my findings in https://issues.apache.org/jira/browse/MPOM-449 -- 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] (MCHANGES-421) Typo in changes.xsd
[ https://issues.apache.org/jira/browse/MCHANGES-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806485#comment-17806485 ] ASF GitHub Bot commented on MCHANGES-421: - ottlinger commented on PR #30: URL: https://github.com/apache/maven-changes-plugin/pull/30#issuecomment-1890989518 @michael-o is there a chance to publish the new XSD? Thanks for your help and sorry to hear about the project's state. > Typo in changes.xsd > --- > > Key: MCHANGES-421 > URL: https://issues.apache.org/jira/browse/MCHANGES-421 > Project: Maven Changes Plugin > Issue Type: Bug >Affects Versions: 2.12.1 >Reporter: Philipp Ottlinger >Assignee: Michael Osipov >Priority: Major > Fix For: backlog > > > While wondering which types to fill in as action type I stumbled upon > https://maven.apache.org/plugins/maven-changes-plugin/xsd/changes-1.0.0.xsd > and realized that there are typos: > It should be "functionality" instead of "functionnality" > As I was unable to spot the file in the repo of maven-changes-plugin I > thought creating a bugticket might be an easier way to get those trivial > fixes into the XSD. > Thanks -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] MCHANGES-421: Fix typos in changes.mdo [maven-changes-plugin]
ottlinger commented on PR #30: URL: https://github.com/apache/maven-changes-plugin/pull/30#issuecomment-1890989518 @michael-o is there a chance to publish the new XSD? Thanks for your help and sorry to hear about the project's state. -- 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] (MPMD-391) Log what developers care about and not what they don't
Elliotte Rusty Harold created MPMD-391: -- Summary: Log what developers care about and not what they don't Key: MPMD-391 URL: https://issues.apache.org/jira/browse/MPMD-391 Project: Maven PMD Plugin Issue Type: Improvement Reporter: Elliotte Rusty Harold Here's output from a recent PMD plugin run that failed: [INFO] >>> maven-pmd-plugin:3.21.2:check (default-cli) > :pmd @ commons-io >>> [INFO] [INFO] --- maven-pmd-plugin:3.21.2:pmd (pmd) @ commons-io --- [INFO] PMD version: 6.55.0 [INFO] Rendering content with org.apache.maven.skins:maven-default-skin:jar:1.3 skin. [INFO] [INFO] <<< maven-pmd-plugin:3.21.2:check (default-cli) < :pmd @ commons-io <<< [INFO] [INFO] [INFO] --- maven-pmd-plugin:3.21.2:check (default-cli) @ commons-io --- [INFO] PMD version: 6.55.0 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 05:22 min [INFO] Finished at: 2024-01-14T14:11:30Z [INFO] Error: Failed to execute goal org.apache.maven.plugins:maven-pmd-plugin:3.21.2:check (default-cli) on project commons-io: You have 1 PMD violation. For more details see: /home/runner/work/commons-io/commons-io/target/pmd.xml -> [Help 1] Error: Error: To see the full stack trace of the errors, re-run Maven with the -e switch. Error: Re-run Maven using the -X switch to enable full debug logging. Error: Error: For more information about the errors and possible solutions, please read the following articles: Error: [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException Error: Process completed with exit code 1. Things I don't care about that are printed: * PMD version * Doxia skin * Blank lines * Total time * Timestamp when it finished * Generic information about Mojo failures * Exit code from Mojo The one thing I care about: * The actual error that caused the failure Everything in the first list can be hidden in some random log file no one will ever look at. Everything in the second list should be front and center. Instead Maven gets this exactly backwards, -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.codehaus.plexus:plexus-interactivity-api from 1.1 to 1.2 [maven-javadoc-plugin]
elharo commented on PR #258: URL: https://github.com/apache/maven-javadoc-plugin/pull/258#issuecomment-1890962766 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.codehaus.plexus:plexus-archiver from 4.9.0 to 4.9.1 [maven-javadoc-plugin]
elharo merged PR #263: URL: https://github.com/apache/maven-javadoc-plugin/pull/263 -- 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] (MCLEAN-116) Create interface method to catch exceptions
[
https://issues.apache.org/jira/browse/MCLEAN-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806461#comment-17806461
]
ASF GitHub Bot commented on MCLEAN-116:
---
Bukama commented on PR #37:
URL:
https://github.com/apache/maven-clean-plugin/pull/37#issuecomment-1890940989
Additional note aside the commit message: Spotless reformatted a lot in the
Cleaner file
> Create interface method to catch exceptions
> ---
>
> Key: MCLEAN-116
> URL: https://issues.apache.org/jira/browse/MCLEAN-116
> Project: Maven Clean Plugin
> Issue Type: Improvement
>Affects Versions: 3.3.2
>Reporter: Matthias Bünger
>Priority: Minor
>
> As stated multiple times in the {{Cleaner}} class, the {{Logger}} interface
> of this class does not provide a method to log exceptions and needs a
> refactoring
> {code:java}
> // ...
> if (logDebug != null) {
> // TODO: this Logger interface cannot log exceptions and
> needs refactoring
> logDebug.log("Unable to fast delete directory: " + e);
> }
> // ...
> private interface Logger {
> void log(CharSequence message);
> }
> {code}
> However: Many plugins, e.g. the javadoc-plugin or the pmg-plugin use the
> {{org.apache.maven.plugin.logging.Log}} interface. Therefor using this
> interface instead an own could be a better solution than adding a new method
> to the interface in the {{Cleaner}} class.
> _This ticket was created to have this task in the issue tracker_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MCLEAN-116] Use default Log interface [maven-clean-plugin]
Bukama commented on PR #37: URL: https://github.com/apache/maven-clean-plugin/pull/37#issuecomment-1890940989 Additional note aside the commit message: Spotless reformatted a lot in the Cleaner file -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump version.maven-plugin-tools from 3.10.2 to 3.11.0 [maven-apache-parent]
slawekjaranowski commented on PR #187: URL: https://github.com/apache/maven-apache-parent/pull/187#issuecomment-1890937717 Wrong property was updated -- 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] (MCLEAN-116) Create interface method to catch exceptions
[
https://issues.apache.org/jira/browse/MCLEAN-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806460#comment-17806460
]
ASF GitHub Bot commented on MCLEAN-116:
---
Bukama opened a new pull request, #37:
URL: https://github.com/apache/maven-clean-plugin/pull/37
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/MCLEAN) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [x] Format the pull request title like `[MCLEAN-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MCLEAN-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).
--
Provided commit message for squashing
```
[MCLEAN-116] Use default Log interface
Submitted by: Matthias Bünger
The logging interface of the Cleaner class was not able to log exceptions in
a suitable way.
So it was replaced by the default logging interface provided by the
AbstractMojo class.
As the AbstractMojo always returns a log instance (therefore never null) the
null checks were removed and the same Systemlogger was used in the tests.
```
As changes are more than 20 lines I will file the icla later the day.
> Create interface method to catch exceptions
> ---
>
> Key: MCLEAN-116
> URL: https://issues.apache.org/jira/browse/MCLEAN-116
> Project: Maven Clean Plugin
> Issue Type: Improvement
>Affects Versions: 3.3.2
>Reporter: Matthias Bünger
>Priority: Minor
>
> As stated multiple times in the {{Cleaner}} class, the {{Logger}} interface
> of this class does not provide a method to log exceptions and needs a
> refactoring
> {code:java}
> // ...
> if (logDebug != null) {
> // TODO: this Logger interface cannot log exceptions and
> needs refactoring
> logDebug.log("Unable to fast delete directory: " + e);
> }
> // ...
> private interface Logger {
> void log(CharSequence message);
> }
> {code}
> However: Many plugins, e.g. the javadoc-plugin or the pmg-plugin use the
> {{org.apache.maven.plugin.logging.Log}} interface. Therefor using this
> interface instead an own could be a better solution than adding a new method
> to the interface in the {{Cleaner}} class.
> _This ticket was created to have this task in the issue tracker_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MCLEAN-116] Use default Log interface [maven-clean-plugin]
Bukama opened a new pull request, #37: URL: https://github.com/apache/maven-clean-plugin/pull/37 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/MCLEAN) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [x] Format the pull request title like `[MCLEAN-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MCLEAN-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). -- Provided commit message for squashing ``` [MCLEAN-116] Use default Log interface Submitted by: Matthias Bünger The logging interface of the Cleaner class was not able to log exceptions in a suitable way. So it was replaced by the default logging interface provided by the AbstractMojo class. As the AbstractMojo always returns a log instance (therefore never null) the null checks were removed and the same Systemlogger was used in the tests. ``` As changes are more than 20 lines I will file the icla later the day. -- 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] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806457#comment-17806457 ] Abel Salgado Romero edited comment on DOXIA-725 at 1/14/24 11:40 AM: - Thanks, [~kwin] but I am sorry to say that doesn't help me. I create a SiteRendererSink for tests only, that's where I found the incompatibility; because my tests cannot run now. My module contains a parser module [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,|https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,m] that what it's not being detected past `asciidoctor-maven-site 4.0.0-M4` because I see no logs and the associated parser [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParser.java] does not run at all. I suspect Modules need to be defined in a different way now? was (Author: abel s.romero): Thanks, [~kwin] but I am sorry to say that doesn't help me. I create a SiteRendererSink for tests only, that's where I found the incompatibility; because my tests cannot run now. My module contains a parser module [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,|https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,m] that what it's not being detected past `asciidoctor-maven-site 4.0.0-M4` because I see no logs and the associated parser [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParser.java] does not run at all. > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[ https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806457#comment-17806457 ] Abel Salgado Romero commented on DOXIA-725: --- Thanks, [~kwin] but I am sorry to say that doesn't help me. I create a SiteRendererSink for tests only, that's where I found the incompatibility; because my tests cannot run now. My module contains a parser module [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,|https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParserModule.java,m] that what it's not being detected past `asciidoctor-maven-site 4.0.0-M4` because I see no logs and the associated parser [https://github.com/abelsromero/asciidoctor-maven-plugin/blob/issue-578-experimental-maven-site-4.x.x/asciidoctor-parser-doxia-module/src/main/java/org/asciidoctor/maven/site/ast/AsciidoctorAstDoxiaParser.java] does not run at all. > Latest Doxia Core is not compatible with doxia-sitetools > > > Key: DOXIA-725 > URL: https://issues.apache.org/jira/browse/DOXIA-725 > Project: Maven Doxia > Issue Type: Improvement >Affects Versions: 2.0.0-M9 >Reporter: Abel Salgado Romero >Priority: Major > Fix For: waiting-for-feedback > > > Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with > `doxia-sitetools`. > This commit > [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f] > final methods where added to `AbstractSink` class, those are still present > in sub-classes like `SiteRendererSink` which now fail instantiation with: > ``` > java.lang.IncompatibleClassChangeError: class > org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final > method org.apache.maven.doxia.sink.impl.AbstractSink.head( > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DOXIA-725) Latest Doxia Core is not compatible with doxia-sitetools
[
https://issues.apache.org/jira/browse/DOXIA-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806456#comment-17806456
]
Konrad Windszus commented on DOXIA-725:
---
[~Abel S.Romero] Look at https://issues.apache.org/jira/browse/DOXIA-709 for
details. Sink implementations must only implement the Doxia 1.1/2.0 methods
taking an additional {{SinkEventAttributes}} argument. I clarified this also in
https://cwiki.apache.org/confluence/display/MAVEN/Towards+Doxia+2.0.0+Stack#TowardsDoxia2.0.0Stack-Doxia2.0.0
(affects only Doxia sink implementations).
> Latest Doxia Core is not compatible with doxia-sitetools
>
>
> Key: DOXIA-725
> URL: https://issues.apache.org/jira/browse/DOXIA-725
> Project: Maven Doxia
> Issue Type: Improvement
>Affects Versions: 2.0.0-M9
>Reporter: Abel Salgado Romero
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Testing Milestones I found `doxia-core` 4.0.0-M9 is not compatible with
> `doxia-sitetools`.
> This commit
> [https://github.com/apache/maven-doxia/commit/0dfe227b6603151b8b460d2b7cacc8953a512f4f]
> final methods where added to `AbstractSink` class, those are still present
> in sub-classes like `SiteRendererSink` which now fail instantiation with:
> ```
> java.lang.IncompatibleClassChangeError: class
> org.apache.maven.doxia.siterenderer.sink.SiteRendererSink overrides final
> method org.apache.maven.doxia.sink.impl.AbstractSink.head(
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-724) Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
[
https://issues.apache.org/jira/browse/DOXIA-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806455#comment-17806455
]
Konrad Windszus commented on DOXIA-724:
---
bq. This means that M9 is void?
Of course not, this bug only affects usages where the order of multiple sink
wrappers matter.
> Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
>
>
> Key: DOXIA-724
> URL: https://issues.apache.org/jira/browse/DOXIA-724
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> According to the javadoc the SinkWrapperFactory should be ordered according
> to their priority from highest to lowest. However in
> {{AbstractParser.getWrappedSink()}} a pipeline is returned which has no
> predictable order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-724) Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
[
https://issues.apache.org/jira/browse/DOXIA-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806454#comment-17806454
]
ASF GitHub Bot commented on DOXIA-724:
--
kwin commented on code in PR #195:
URL: https://github.com/apache/maven-doxia/pull/195#discussion_r1451704784
##
doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java:
##
@@ -95,11 +95,12 @@ public interface Parser {
void addSinkWrapperFactory(SinkWrapperFactory factory);
/**
- *
- * @return all sink wrapper factories in the correct order (both
registered automatically and manually)
+ * Returns all sink wrapper factories (both registered automatically and
manually). The collection is ordered in a way that
+ * the factories having the lowest priority come first (i.e. in reverse
order).
+ * @return all sink wrapper factories in the reverse order
* @since 2.0.0
*/
-Collection getSinkWrapperFactories();
+List getSinkWrapperFactories();
Review Comment:
I think it was a mistake exposing that via `Parser`. This is clearly SPI
only and therefore only belongs to `AbstractParser`. There it should be a
protected method. `List` as return value makes sense for usages which try to
retrieve the last element only. For me M-builds should allow to modify API.
> Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
>
>
> Key: DOXIA-724
> URL: https://issues.apache.org/jira/browse/DOXIA-724
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> According to the javadoc the SinkWrapperFactory should be ordered according
> to their priority from highest to lowest. However in
> {{AbstractParser.getWrappedSink()}} a pipeline is returned which has no
> predictable order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-724] Fix order of sink wrappers in pipeline [maven-doxia]
kwin commented on code in PR #195:
URL: https://github.com/apache/maven-doxia/pull/195#discussion_r1451704784
##
doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java:
##
@@ -95,11 +95,12 @@ public interface Parser {
void addSinkWrapperFactory(SinkWrapperFactory factory);
/**
- *
- * @return all sink wrapper factories in the correct order (both
registered automatically and manually)
+ * Returns all sink wrapper factories (both registered automatically and
manually). The collection is ordered in a way that
+ * the factories having the lowest priority come first (i.e. in reverse
order).
+ * @return all sink wrapper factories in the reverse order
* @since 2.0.0
*/
-Collection getSinkWrapperFactories();
+List getSinkWrapperFactories();
Review Comment:
I think it was a mistake exposing that via `Parser`. This is clearly SPI
only and therefore only belongs to `AbstractParser`. There it should be a
protected method. `List` as return value makes sense for usages which try to
retrieve the last element only. For me M-builds should allow to modify API.
--
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] (DOXIA-724) Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
[
https://issues.apache.org/jira/browse/DOXIA-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806453#comment-17806453
]
ASF GitHub Bot commented on DOXIA-724:
--
kwin commented on code in PR #195:
URL: https://github.com/apache/maven-doxia/pull/195#discussion_r1451704784
##
doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java:
##
@@ -95,11 +95,12 @@ public interface Parser {
void addSinkWrapperFactory(SinkWrapperFactory factory);
/**
- *
- * @return all sink wrapper factories in the correct order (both
registered automatically and manually)
+ * Returns all sink wrapper factories (both registered automatically and
manually). The collection is ordered in a way that
+ * the factories having the lowest priority come first (i.e. in reverse
order).
+ * @return all sink wrapper factories in the reverse order
* @since 2.0.0
*/
-Collection getSinkWrapperFactories();
+List getSinkWrapperFactories();
Review Comment:
I think it was a mistake exposing that via `Parser`. This is clearly SPI
only and therefore only belongs to `AbstractParser`. There it should be a
protected method. `List` as return value makes sense for usages which try to
retrieve the last element only.
> Sink pipeline returned by AbstractParser.getWrappedSink(...) has wrong order
>
>
> Key: DOXIA-724
> URL: https://issues.apache.org/jira/browse/DOXIA-724
> Project: Maven Doxia
> Issue Type: Bug
>Affects Versions: 2.0.0-M9
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> According to the javadoc the SinkWrapperFactory should be ordered according
> to their priority from highest to lowest. However in
> {{AbstractParser.getWrappedSink()}} a pipeline is returned which has no
> predictable order.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-724] Fix order of sink wrappers in pipeline [maven-doxia]
kwin commented on code in PR #195:
URL: https://github.com/apache/maven-doxia/pull/195#discussion_r1451704784
##
doxia-core/src/main/java/org/apache/maven/doxia/parser/Parser.java:
##
@@ -95,11 +95,12 @@ public interface Parser {
void addSinkWrapperFactory(SinkWrapperFactory factory);
/**
- *
- * @return all sink wrapper factories in the correct order (both
registered automatically and manually)
+ * Returns all sink wrapper factories (both registered automatically and
manually). The collection is ordered in a way that
+ * the factories having the lowest priority come first (i.e. in reverse
order).
+ * @return all sink wrapper factories in the reverse order
* @since 2.0.0
*/
-Collection getSinkWrapperFactories();
+List getSinkWrapperFactories();
Review Comment:
I think it was a mistake exposing that via `Parser`. This is clearly SPI
only and therefore only belongs to `AbstractParser`. There it should be a
protected method. `List` as return value makes sense for usages which try to
retrieve the last element 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
