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-1891520373 @laeubi ok, so if I rephrase the questions are IMHO: 1. Do we want to let people go a prefix they didn't anticipate since it will fully be part of the exposed UI to the end user (mvn foo:bar) - the fact you said you didn't know what to put whereas it was in your doc kind of corroborate that part? 2. For tempting cases where you flag your plugin "plugin", "maven-plugin" you were getting an empty prefix which was wrong and must fail by design - it really happent (happens :(). So discussion is mainly about 1, I think a warning wouldnt help and an error is the right thing to do - warnings tend to be ignored or avoided as an error so both cases make it useless so it is either considered ok - half of the cases are not as mentionned - so I think error is better for that reason even if it means some people will have to explicit the prefix even if the heuristic was ok-ish for them (note that rat is one example it was not ok, the `rat` vs `apache-rat` prefix is still an issue for most users and highlights point 1 too). Hope it helps to follow my reasoning a bit. -- 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&focusedCommentId=17806676#comment-17806676 ] ASF GitHub Bot commented on MPLUGIN-450: rmannibucau commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891520373 @laeubi ok, so if I rephrase the questions are IMHO: 1. Do we want to let people go a prefix they didn't anticipate since it will fully be part of the exposed UI to the end user (mvn foo:bar) - the fact you said you didn't know what to put whereas it was in your doc kind of corroborate that part? 2. For tempting cases where you flag your plugin "plugin", "maven-plugin" you were getting an empty prefix which was wrong and must fail by design - it really happent (happens :(). So discussion is mainly about 1, I think a warning wouldnt help and an error is the right thing to do - warnings tend to be ignored or avoided as an error so both cases make it useless so it is either considered ok - half of the cases are not as mentionned - so I think error is better for that reason even if it means some people will have to explicit the prefix even if the heuristic was ok-ish for them (note that rat is one example it was not ok, the `rat` vs `apache-rat` prefix is still an issue for most users and highlights point 1 too). Hope it helps to follow my reasoning a bit. > 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] [MARCHETYPES-82] generate comments for maven.compiler.release [maven-archetypes]
judovana commented on code in PR #28: URL: https://github.com/apache/maven-archetypes/pull/28#discussion_r1452039881 ## maven-archetype-quickstart/src/test/resources/projects/it-java-7-junit-4.12/reference/pom.xml: ## @@ -15,6 +15,7 @@ UTF-8 1.7 1.7 + Review Comment: Looks like forgotten 1.7? -- 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] (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&focusedCommentId=17806681#comment-17806681 ] ASF GitHub Bot commented on MARCHETYPES-82: --- judovana commented on code in PR #28: URL: https://github.com/apache/maven-archetypes/pull/28#discussion_r1452039881 ## maven-archetype-quickstart/src/test/resources/projects/it-java-7-junit-4.12/reference/pom.xml: ## @@ -15,6 +15,7 @@ UTF-8 1.7 1.7 + Review Comment: Looks like forgotten 1.7? > 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)
[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&focusedCommentId=17806683#comment-17806683 ] ASF GitHub Bot commented on MPLUGIN-450: laeubi commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891535779 As mentioned, I never used that prefix, and no one has ever complained it is wrong/to long / ... so it simply wasn't an issue before. I now learned it shows up in the docs, and I probably could have omitted some infos in the rare cases where I called a mojo from CLI. So for (1) it seems a lot of users where happy with that, for (2) as said it seams reasonable to give an error as it is obviously not getting anything useful here. > note that rat is one example it was not ok, the rat vs apache-rat prefix is still an issue for most users But why don't these user ever complained so the prefix was added before this change? why is `apache-rat` "wrong" and `rat` right? of course shorter is more convenient but again, no one has complained, so it was convenient enough as it seems. Also the shorter the higher the risk of name-clashes can maven handle this if two plugins use the same prefix or will it make these two plugins incompatible to be used in the same build? Or will it even be "random" (maybe by some ordering in the pom) what is chosen? > 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] [MARCHETYPES-82] generate comments for maven.compiler.release [maven-archetypes]
judovana commented on PR #28:
URL: https://github.com/apache/maven-archetypes/pull/28#issuecomment-1891540458
I still think the
```
${javaCompilerVersionLocal}
${javaCompilerVersionLocal}
+
```
is misplaced, and should be at
https://github.com/apache/maven-archetypes/blob/master/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L49
Generally I think this commit is not helpful, as it will just confuse any
future grep/sed and generally any maven user/java developer should be able to
bump 8 to 11, or generally to anything they need.
I had missed reasoning why you actually proposed this changeset.
Thanx for merging #27 . As for this, I'm -1, but I do not have any
permissions of any weight :) Good luck!
--
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] (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&focusedCommentId=17806684#comment-17806684
]
ASF GitHub Bot commented on MARCHETYPES-82:
---
judovana commented on PR #28:
URL: https://github.com/apache/maven-archetypes/pull/28#issuecomment-1891540458
I still think the
```
${javaCompilerVersionLocal}
${javaCompilerVersionLocal}
+
```
is misplaced, and should be at
https://github.com/apache/maven-archetypes/blob/master/maven-archetype-quickstart/src/main/resources-filtered/archetype-resources/pom.xml#L49
Generally I think this commit is not helpful, as it will just confuse any
future grep/sed and generally any maven user/java developer should be able to
bump 8 to 11, or generally to anything they need.
I had missed reasoning why you actually proposed this changeset.
Thanx for merging #27 . As for this, I'm -1, but I do not have any
permissions of any weight :) Good luck!
> 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] [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-1891553087 > So for (1) it seems a lot of users where happy with that I assume you mean for tycho case but it is really done under the carpet so 50-50 IMHO (implicit case is actually rare from what I saw so not sure it is numerous enough to do stats :D). > But why don't these user ever complained so the prefix was added before this change? You mix two things there: the producer and consumer sides. There is *no* change for consumers (users), it only changes the way the producer sets the prefix. > why is apache-rat "wrong" and rat right Don't think it is what you mean but didn't say `apache-rat` is wrong, what I meant is that the concurrent prefix is an issue for users cause they don't know which one to use. It is common to see an user using the wrong prefix on rat failure and not getting the expected result. > no one has complained This is not true, not sure why you say that. > Also the shorter the higher the risk of name-clashes can maven handle this if two plugins use the same prefix or will it make these two plugins incompatible to be used in the same build Only if referenced from the prefix, not in all other cases. -- 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&focusedCommentId=17806686#comment-17806686 ] ASF GitHub Bot commented on MPLUGIN-450: rmannibucau commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891553087 > So for (1) it seems a lot of users where happy with that I assume you mean for tycho case but it is really done under the carpet so 50-50 IMHO (implicit case is actually rare from what I saw so not sure it is numerous enough to do stats :D). > But why don't these user ever complained so the prefix was added before this change? You mix two things there: the producer and consumer sides. There is *no* change for consumers (users), it only changes the way the producer sets the prefix. > why is apache-rat "wrong" and rat right Don't think it is what you mean but didn't say `apache-rat` is wrong, what I meant is that the concurrent prefix is an issue for users cause they don't know which one to use. It is common to see an user using the wrong prefix on rat failure and not getting the expected result. > no one has complained This is not true, not sure why you say that. > Also the shorter the higher the risk of name-clashes can maven handle this if two plugins use the same prefix or will it make these two plugins incompatible to be used in the same build Only if referenced from the prefix, not in all other cases. > 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-1891564489 > You mix two things there: the producer and consumer sides. There is no change for consumers (users), it only changes the way the producer sets the prefix. I don't mix anything, but that's actually the point, now the _producer_ is forced to set something so it stays as before, because _consumers_ before have never complained obviously that they want some change. So neither _producer_ nor _consumer_ requested for such feature / change, but now are facing to take actions e.g. producer needs to replicate previously automatic info, _consumer_ might need to change because producer has decided to if setting the prefix it should be changed to something else (like for rat vs apache-rat) -- 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] (MNG-8018) Maven creates local repo at wrong path
Jörg Hohwiller created MNG-8018:
---
Summary: Maven creates local repo at wrong path
Key: MNG-8018
URL: https://issues.apache.org/jira/browse/MNG-8018
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories, Command Line
Affects Versions: 3.9.6
Environment: {code}
$ mvn -v
Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: D:\projects\mmm\software\mvn
Java version: 21.0.1, vendor: Eclipse Adoptium, runtime:
D:\projects\mmm\software\java
Default locale: en_US, platform encoding: UTF-8
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
{code}
Reporter: Jörg Hohwiller
I am hunting bugs with maven for years now that is creating a new local
repository in an odd location (something like {{D:\d\...}} but before also
{{$PWD/${M2_REPO}}} - see https://github.com/devonfw/ide/issues/706). Now I was
finally able to become able to effectively reproduce it:
I created an empty {{d}} folder on my {{D:}} drive but removed all permissions
on it even for myself to force errors in case maven will ever try to populate
this directory again.
This now happened when maven is executed from {{maven-exec-plugin}} and the
nested maven tries to resolve the local repository in that context it seems to
consider the path to the local repository as relative even though it is
absolute.
Here are some more detailed circumstances when this error is happening:
* I am on Windows
* I am working in git-bash when I invoke maven ({{mvn install}}).
* To relocate the local repository, I used this "hack": {{export MAVEN_OPTS=
-Duser.home=/d/projects/mmm/conf}}. This works to make my repo be at
{{/d/projects/mmm/conf/.m2/repository}} (git-bash syntax) or
{{D:\projects\mmm\conf\\.m2\\repository}} at least for the top-level {{mvn}}
process.
* Now when I did run {{mvn install}} the project was executing {{mvn install}}
in a test folder via {{exec-maven-plugin}}. See
https://github.com/m-m-m/code/blob/238899e2b2525081b39f59932e093d5c331a2864/java/impl/pom.xml#L64
This results in the following error:
{code}
[INFO] --- exec:3.1.0:exec (Install test project) @ mmm-code-java-impl ---
[ERROR] Could not create local repository at
D:\d\projects\mmm\conf\.m2\repository -> [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/LocalRepositoryNotAccessibleException
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit
value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal
(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute
(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:1000)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:947)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
{code}
I was already hunting down the source-code of maven-exec plugin if it contains
any code related to this problem. But it seems not to explicitly handle or
tweak any related environment variables or do anything different where {{mvn}}
is executed or any other program.
So my assumption is that maven core itself has some logic to resolve the local
maven repo and decide if something is a relative or an absolute path. As this
is working for paths in git-bash syntax for the top-level {{mvn}} process, I
would guess that there is some magic detection of git-bash/MSYS that however,
stops working if {{mvn}} is then again executed but not directly from git-bash
but from a Java-process (maven itself) within.
I know this is kind of an edge-case but as I was searching for this for a long
time, I decided to report this. As I could not see it is a bug of
{{maven-exec-plugin}} itself, I finally filed it here. I would be very pleased,
if you have any further ideas on this.
In case I should try anything special please let me know and I will do and
provide results.
You could however easily reproduce this by creating a simple project with again
a very simple maven project in {{src/main/resources//maven.project}}
such pom section:
{code}
...
org.codehaus.mojo
exec-maven-plugin
[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&focusedCommentId=17806691#comment-17806691 ] ASF GitHub Bot commented on MPLUGIN-450: laeubi commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891564489 > You mix two things there: the producer and consumer sides. There is no change for consumers (users), it only changes the way the producer sets the prefix. I don't mix anything, but that's actually the point, now the _producer_ is forced to set something so it stays as before, because _consumers_ before have never complained obviously that they want some change. So neither _producer_ nor _consumer_ requested for such feature / change, but now are facing to take actions e.g. producer needs to replicate previously automatic info, _consumer_ might need to change because producer has decided to if setting the prefix it should be changed to something else (like for rat vs apache-rat) > 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] [Updated] (MNG-8018) Maven creates local repo at wrong path
[
https://issues.apache.org/jira/browse/MNG-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Hohwiller updated MNG-8018:
Description:
I am hunting bugs with maven for years now that is creating a new local
repository in an odd location (something like {{D:\d\...}} but before also
{{$PWD/${M2_REPO}}} - see https://github.com/devonfw/ide/issues/706). Now I was
finally able to become able to effectively reproduce it:
I created an empty {{d}} folder on my {{D:}} drive but removed all permissions
on it even for myself to force errors in case maven will ever try to populate
this directory again.
This now happened when maven is executed from {{maven-exec-plugin}} and the
nested maven tries to resolve the local repository in that context it seems to
consider the path to the local repository as relative even though it is
absolute.
Here are some more detailed circumstances when this error is happening:
* I am on Windows
* I am working in git-bash when I invoke maven ({{mvn install}}).
* To relocate the local repository, I used this "hack": {{export MAVEN_OPTS=
-Duser.home=/d/projects/mmm/conf}}. This works to take the settings from
{{/d/projects/mmm/conf/.m2/settings.xml}} what in my case relocates my repo to
be at {{/d/projects/mmm/conf/.m2/repository}} (git-bash syntax) or
{{D:\projects\mmm\conf\\.m2\\repository}} (Windows syntax) at least for the
top-level {{mvn}} process.
* Now when I did run {{mvn install}} the project was executing {{mvn install}}
in a test folder via {{exec-maven-plugin}}. See
https://github.com/m-m-m/code/blob/238899e2b2525081b39f59932e093d5c331a2864/java/impl/pom.xml#L64
This results in the following error:
{code}
[INFO] --- exec:3.1.0:exec (Install test project) @ mmm-code-java-impl ---
[ERROR] Could not create local repository at
D:\d\projects\mmm\conf\.m2\repository -> [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/LocalRepositoryNotAccessibleException
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit
value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal
(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute
(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:1000)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:947)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
{code}
I was already hunting down the source-code of maven-exec plugin if it contains
any code related to this problem. But it seems not to explicitly handle or
tweak any related environment variables or do anything different where {{mvn}}
is executed or any other program.
So my assumption is that maven core itself has some logic to resolve the local
maven repo and decide if something is a relative or an absolute path. As this
is working for paths in git-bash syntax for the top-level {{mvn}} process, I
would guess that there is some magic detection of git-bash/MSYS that however,
stops working if {{mvn}} is then again executed but not directly from git-bash
but from a Java-process (maven itself) within.
I know this is kind of an edge-case but as I was searching for this for a long
time, I decided to report this. As I could not see it is a bug of
{{maven-exec-plugin}} itself, I finally filed it here. I would be very pleased,
if you have any further ideas on this.
In case I should try anything special please let me know and I will do and
provide results.
You could however easily reproduce this by creating a simple project with again
a very simple maven project in {{src/main/resources//maven.project}}
such pom section:
{code}
...
org.codehaus.mojo
exec-maven-plugin
3.1.0
Install test project
test-compile
exec
mvn
target/test-classes/maven.project
install
...
{code}
Then in {{git-bash}} run {{export MAVEN_OPTS="-Duser.home=$HOME" && mvn
install}}. The secondary {{mvn}} process should then create a repo in something
like
[jira] [Updated] (MNG-8018) Maven creates local repo at wrong path
[
https://issues.apache.org/jira/browse/MNG-8018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jörg Hohwiller updated MNG-8018:
Description:
I am hunting bugs with maven for years now that is creating a new local
repository in an odd location (something like {{D:\d\...}} but before also
{{$PWD/${M2_REPO}}} - see https://github.com/devonfw/ide/issues/706). Now I was
finally able to become able to effectively reproduce it:
I created an empty {{d}} folder on my {{D:}} drive but removed all permissions
on it even for myself to force errors in case maven will ever try to populate
this directory again.
This now happened when maven is executed from {{maven-exec-plugin}} and the
nested maven tries to resolve the local repository in that context it seems to
consider the path to the local repository as relative even though it is
absolute.
Here are some more detailed circumstances when this error is happening:
* I am on Windows
* I am working in git-bash when I invoke maven ({{mvn install}}).
* To relocate the local repository, I used this "hack": {{export MAVEN_OPTS=
-Duser.home=/d/projects/mmm/conf}}. This works to take the settings from
{{/d/projects/mmm/conf/.m2/settings.xml}} what in my case configures my repo to
be at {{/c/Users/hohwille/conf/.m2/repository}} (git-bash syntax) or
{{C:\Users\hohwille\\.m2\\repository}} (Windows syntax) at least for the
top-level {{mvn}} process.
* Now when I did run {{mvn install}} the project was executing {{mvn install}}
in a test folder via {{exec-maven-plugin}}. See
https://github.com/m-m-m/code/blob/238899e2b2525081b39f59932e093d5c331a2864/java/impl/pom.xml#L64
This results in the following error:
{code}
[INFO] --- exec:3.1.0:exec (Install test project) @ mmm-code-java-impl ---
[ERROR] Could not create local repository at
D:\d\projects\mmm\conf\.m2\repository -> [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/LocalRepositoryNotAccessibleException
[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit
value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal
(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute
(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:1000)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:947)
at org.codehaus.mojo.exec.ExecMojo.execute (ExecMojo.java:471)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:126)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:328)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:316)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:212)
{code}
I was already hunting down the source-code of maven-exec plugin if it contains
any code related to this problem. But it seems not to explicitly handle or
tweak any related environment variables or do anything different where {{mvn}}
is executed or any other program.
So my assumption is that maven core itself has some logic to resolve the local
maven repo and decide if something is a relative or an absolute path. As this
is working for paths in git-bash syntax for the top-level {{mvn}} process, I
would guess that there is some magic detection of git-bash/MSYS that however,
stops working if {{mvn}} is then again executed but not directly from git-bash
but from a Java-process (maven itself) within.
BTW: With the path treated wrongly as relative it can not find the
{{settings.xml}} and hence computes the path to the local repository in the
"default location" what is inside my tweaked home directory causing the
difference between {{C}} and {{D}} drive.
I know this is kind of an edge-case but as I was searching for this for a long
time, I decided to report this. As I could not see it is a bug of
{{maven-exec-plugin}} itself, I finally filed it here. I would be very pleased,
if you have any further ideas on this.
In case I should try anything special please let me know and I will do and
provide results.
You could however easily reproduce this by creating a simple project with again
a very simple maven project in {{src/main/resources//maven.project}}
such pom section:
{code}
...
org.codehaus.mojo
exec-maven-plugin
3.1.0
Install test project
test-compile
exec
mvn
target/test-
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-1891626872 > I don't mix anything, but that's actually the point, now the producer is forced to set something so it stays as before, because consumers before have never complained obviously that they want some change. I don't understand what you mean, I read it like "because [consumers] are not impacted they would have to be impacted", so not sure the point. The key in what you said is _now the producer is forced to set something so it stays as before_ which is exactly that, keep in mind part of the producers were not controlling at all that part and another part were setting invalid values so overall validating it the hard way is the safest solution for maven and we keep backward compatibility for consumers by explaining the producer to set the goal prefix so nobody is broken. > So neither producer nor consumer requested for such feature / change Isn't it always the case when there was a design issue in a tool and it gets fixed? Nobody asked to configure a filter for RMI serialization, it is the same there. > e.g. for the tycho case I now need to add 24 useless duplication in the config that was previously perfectly derived without a problem and users never where unhappy enough to open an issue > 10 years: on the user point please see previous comment, it is *normal* they never complained since this fix does *not* impact them > https://github.com/eclipse-tycho/tycho/pull/3363/files Looks good and now you control your produced plugin and you will not break your command lines (ci) even if you refactor your gav to comply to maven recommended pattern (x-maven-plugin, not x-plugin), this sounds way better to me. -- 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&focusedCommentId=17806702#comment-17806702 ] ASF GitHub Bot commented on MPLUGIN-450: rmannibucau commented on PR #240: URL: https://github.com/apache/maven-plugin-tools/pull/240#issuecomment-1891626872 > I don't mix anything, but that's actually the point, now the producer is forced to set something so it stays as before, because consumers before have never complained obviously that they want some change. I don't understand what you mean, I read it like "because [consumers] are not impacted they would have to be impacted", so not sure the point. The key in what you said is _now the producer is forced to set something so it stays as before_ which is exactly that, keep in mind part of the producers were not controlling at all that part and another part were setting invalid values so overall validating it the hard way is the safest solution for maven and we keep backward compatibility for consumers by explaining the producer to set the goal prefix so nobody is broken. > So neither producer nor consumer requested for such feature / change Isn't it always the case when there was a design issue in a tool and it gets fixed? Nobody asked to configure a filter for RMI serialization, it is the same there. > e.g. for the tycho case I now need to add 24 useless duplication in the config that was previously perfectly derived without a problem and users never where unhappy enough to open an issue > 10 years: on the user point please see previous comment, it is *normal* they never complained since this fix does *not* impact them > https://github.com/eclipse-tycho/tycho/pull/3363/files Looks good and now you control your produced plugin and you will not break your command lines (ci) even if you refactor your gav to comply to maven recommended pattern (x-maven-plugin, not x-plugin), this sounds way better to me. > 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] (DOXIA-723) Optionally expose document location in Sink
[
https://issues.apache.org/jira/browse/DOXIA-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806709#comment-17806709
]
ASF GitHub Bot commented on DOXIA-723:
--
michael-o commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452110659
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractLocator.java:
##
@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import org.apache.maven.doxia.sink.Locator;
+
+/**
+ * @since 2.0.0
+ */
+public abstract class AbstractLocator implements Locator {
+
+private String reference;
+
+protected AbstractLocator(String reference) {
+super();
+this.reference = reference;
+}
+
+@Override
+public String getReference() {
+return reference;
+}
+
+@Override
+public String getLogPrefix() {
+return formatLocation(this);
+}
+
+/**
+ * Creates a string with line/column information. Inspired by
+ * {@code o.a.m.model.building.ModelProblemUtils.formatLocation(...)}.
+ *
+ * @param locator The locator must not be {@code null}.
+ * @return The formatted location or an empty string if unknown, never
{@code null}.
+ */
+public static String formatLocation(Locator locator) {
Review Comment:
I believe that both `formatLocation` and `getLogPrefix` are misplaced here.
This class is expected to contain on the four datapoints, formatting should be
done else where, by the client cod, e.g. `AbstractParser` or so.
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractSink.java:
##
@@ -420,4 +424,17 @@ protected static String unifyEOLs(String text) {
protected void init() {
// nop
}
+
+@Override
+public void setDocumentLocator(Locator locator) {
+this.locator = locator;
+}
+
+@Override
+public Locator getDocumentLocator() {
Review Comment:
It is weird that one needs a locator for a sink...
> Optionally expose document location in Sink
> ---
>
> Key: DOXIA-723
> URL: https://issues.apache.org/jira/browse/DOXIA-723
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to http://www.saxproject.org/apidoc/org/xml/sax/Locator.html the Sink
> API should provide means to figure out the document location. This should be
> available whenever the Sink events are emitted from parsing a file.
> The locator should expose file name, line number and column number.
> This can be used enhance warning/errors as otherwise it is very hard to
> figure out the root cause of messages like
> https://github.com/apache/maven-doxia/blob/e01880801ca1283b86205e2f7064b9b4dbc84d54/doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/Xhtml5BaseSink.java#L930.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [DOXIA-723] Expose document location in Sink [maven-doxia]
michael-o commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452110659
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractLocator.java:
##
@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import org.apache.maven.doxia.sink.Locator;
+
+/**
+ * @since 2.0.0
+ */
+public abstract class AbstractLocator implements Locator {
+
+private String reference;
+
+protected AbstractLocator(String reference) {
+super();
+this.reference = reference;
+}
+
+@Override
+public String getReference() {
+return reference;
+}
+
+@Override
+public String getLogPrefix() {
+return formatLocation(this);
+}
+
+/**
+ * Creates a string with line/column information. Inspired by
+ * {@code o.a.m.model.building.ModelProblemUtils.formatLocation(...)}.
+ *
+ * @param locator The locator must not be {@code null}.
+ * @return The formatted location or an empty string if unknown, never
{@code null}.
+ */
+public static String formatLocation(Locator locator) {
Review Comment:
I believe that both `formatLocation` and `getLogPrefix` are misplaced here.
This class is expected to contain on the four datapoints, formatting should be
done else where, by the client cod, e.g. `AbstractParser` or so.
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractSink.java:
##
@@ -420,4 +424,17 @@ protected static String unifyEOLs(String text) {
protected void init() {
// nop
}
+
+@Override
+public void setDocumentLocator(Locator locator) {
+this.locator = locator;
+}
+
+@Override
+public Locator getDocumentLocator() {
Review Comment:
It is weird that one needs a locator for a sink...
--
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
[PR] Clarify default values for repositories [maven-site]
kwin opened a new pull request, #485: URL: https://github.com/apache/maven-site/pull/485 Clean up example snippet for repositories -- 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
[PR] Bump org.codehaus.plexus:plexus-archiver from 4.9.0 to 4.9.1 [maven-ear-plugin]
dependabot[bot] opened a new pull request, #106: URL: https://github.com/apache/maven-ear-plugin/pull/106 Bumps [org.codehaus.plexus:plexus-archiver](https://github.com/codehaus-plexus/plexus-archiver) from 4.9.0 to 4.9.1. Release notes Sourced from https://github.com/codehaus-plexus/plexus-archiver/releases";>org.codehaus.plexus:plexus-archiver's releases. 4.9.1 🚀 New features and improvements https://redirect.github.com/codehaus-plexus/plexus-archiver/issues/311";>#311 - provide fluent setter for usingDefaultExcludes flag in Abstrac… (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/312";>#312) https://github.com/redzi";>@redzi 📦 Dependency updates Bump org.codehaus.plexus:plexus from 15 to 16 (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/316";>#316) https://github.com/dependabot";>@dependabot Bump com.github.luben:zstd-jni from 1.5.5-10 to 1.5.5-11 (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/314";>#314) https://github.com/dependabot";>@dependabot Bump commons-io:commons-io from 2.15.0 to 2.15.1 (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/313";>#313) https://github.com/dependabot";>@dependabot Bump org.apache.commons:commons-compress from 1.24.0 to 1.25.0 (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/309";>#309) https://github.com/dependabot";>@dependabot 👻 Maintenance Reuse plexus-pom action for CI (https://redirect.github.com/codehaus-plexus/plexus-archiver/pull/315";>#315) https://github.com/slachiewicz";>@slachiewicz Commits https://github.com/codehaus-plexus/plexus-archiver/commit/fb02b02a78d4adecef4e32f304f9f6d3ab7b9861";>fb02b02 [maven-release-plugin] prepare release plexus-archiver-4.9.1 https://github.com/codehaus-plexus/plexus-archiver/commit/d953f322ccbb38479b04abbde3645f77eafd489a";>d953f32 Bump org.codehaus.plexus:plexus from 15 to 16 https://github.com/codehaus-plexus/plexus-archiver/commit/54c42c20e531b9e642a3c70c215814b5a4d61a3b";>54c42c2 Bump com.github.luben:zstd-jni from 1.5.5-10 to 1.5.5-11 https://github.com/codehaus-plexus/plexus-archiver/commit/cb4b6668a8dde2d04aaac37e8265b3e009cb2ca9";>cb4b666 Reuse plexus-pom action for CI https://github.com/codehaus-plexus/plexus-archiver/commit/20cf65421aacbb133a9fe228dbe9fc06000def7a";>20cf654 Bump commons-io:commons-io from 2.15.0 to 2.15.1 https://github.com/codehaus-plexus/plexus-archiver/commit/fca25e56461394a6d34af8e018ec0348885cbad8";>fca25e5 https://redirect.github.com/codehaus-plexus/plexus-archiver/issues/311";>#311 - provide fluent setter for usingDefaultExcludes flag in AbstractFileSet. https://github.com/codehaus-plexus/plexus-archiver/commit/9c0e021ab9d58dd8b05a74a5ba6c82f8070c8d93";>9c0e021 Bump org.apache.commons:commons-compress from 1.24.0 to 1.25.0 https://github.com/codehaus-plexus/plexus-archiver/commit/b353ae3240cfda1c23ec8c1d80e719af40698b66";>b353ae3 [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/codehaus-plexus/plexus-archiver/compare/plexus-archiver-4.9.0...plexus-archiver-4.9.1";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this m
Re: [PR] [DOXIA-723] Expose document location in Sink [maven-doxia]
kwin commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452150977
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractSink.java:
##
@@ -420,4 +424,17 @@ protected static String unifyEOLs(String text) {
protected void init() {
// nop
}
+
+@Override
+public void setDocumentLocator(Locator locator) {
+this.locator = locator;
+}
+
+@Override
+public Locator getDocumentLocator() {
Review Comment:
Any proposal on how to rename? Sinks are either used from a parser or
manually. Obviously the locator primarily makes sense to the former. But the
whole point of this PR and the related issue is that this should be available
in sinks.
--
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] [DOXIA-723] Expose document location in Sink [maven-doxia]
kwin commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452152264
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractLocator.java:
##
@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import org.apache.maven.doxia.sink.Locator;
+
+/**
+ * @since 2.0.0
+ */
+public abstract class AbstractLocator implements Locator {
+
+private String reference;
+
+protected AbstractLocator(String reference) {
+super();
+this.reference = reference;
+}
+
+@Override
+public String getReference() {
+return reference;
+}
+
+@Override
+public String getLogPrefix() {
+return formatLocation(this);
+}
+
+/**
+ * Creates a string with line/column information. Inspired by
+ * {@code o.a.m.model.building.ModelProblemUtils.formatLocation(...)}.
+ *
+ * @param locator The locator must not be {@code null}.
+ * @return The formatted location or an empty string if unknown, never
{@code null}.
+ */
+public static String formatLocation(Locator locator) {
Review Comment:
This is used in `Sink` (not in `Parser`), therefore the only option would be
to move to `AbstractSink`.
--
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-723) Optionally expose document location in Sink
[
https://issues.apache.org/jira/browse/DOXIA-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806721#comment-17806721
]
ASF GitHub Bot commented on DOXIA-723:
--
kwin commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452150977
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractSink.java:
##
@@ -420,4 +424,17 @@ protected static String unifyEOLs(String text) {
protected void init() {
// nop
}
+
+@Override
+public void setDocumentLocator(Locator locator) {
+this.locator = locator;
+}
+
+@Override
+public Locator getDocumentLocator() {
Review Comment:
Any proposal on how to rename? Sinks are either used from a parser or
manually. Obviously the locator primarily makes sense to the former. But the
whole point of this PR and the related issue is that this should be available
in sinks.
> Optionally expose document location in Sink
> ---
>
> Key: DOXIA-723
> URL: https://issues.apache.org/jira/browse/DOXIA-723
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to http://www.saxproject.org/apidoc/org/xml/sax/Locator.html the Sink
> API should provide means to figure out the document location. This should be
> available whenever the Sink events are emitted from parsing a file.
> The locator should expose file name, line number and column number.
> This can be used enhance warning/errors as otherwise it is very hard to
> figure out the root cause of messages like
> https://github.com/apache/maven-doxia/blob/e01880801ca1283b86205e2f7064b9b4dbc84d54/doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/Xhtml5BaseSink.java#L930.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DOXIA-723) Optionally expose document location in Sink
[
https://issues.apache.org/jira/browse/DOXIA-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806722#comment-17806722
]
ASF GitHub Bot commented on DOXIA-723:
--
kwin commented on code in PR #194:
URL: https://github.com/apache/maven-doxia/pull/194#discussion_r1452152264
##
doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/AbstractLocator.java:
##
@@ -0,0 +1,69 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.doxia.sink.impl;
+
+import org.apache.maven.doxia.sink.Locator;
+
+/**
+ * @since 2.0.0
+ */
+public abstract class AbstractLocator implements Locator {
+
+private String reference;
+
+protected AbstractLocator(String reference) {
+super();
+this.reference = reference;
+}
+
+@Override
+public String getReference() {
+return reference;
+}
+
+@Override
+public String getLogPrefix() {
+return formatLocation(this);
+}
+
+/**
+ * Creates a string with line/column information. Inspired by
+ * {@code o.a.m.model.building.ModelProblemUtils.formatLocation(...)}.
+ *
+ * @param locator The locator must not be {@code null}.
+ * @return The formatted location or an empty string if unknown, never
{@code null}.
+ */
+public static String formatLocation(Locator locator) {
Review Comment:
This is used in `Sink` (not in `Parser`), therefore the only option would be
to move to `AbstractSink`.
> Optionally expose document location in Sink
> ---
>
> Key: DOXIA-723
> URL: https://issues.apache.org/jira/browse/DOXIA-723
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> Similar to http://www.saxproject.org/apidoc/org/xml/sax/Locator.html the Sink
> API should provide means to figure out the document location. This should be
> available whenever the Sink events are emitted from parsing a file.
> The locator should expose file name, line number and column number.
> This can be used enhance warning/errors as otherwise it is very hard to
> figure out the root cause of messages like
> https://github.com/apache/maven-doxia/blob/e01880801ca1283b86205e2f7064b9b4dbc84d54/doxia-core/src/main/java/org/apache/maven/doxia/sink/impl/Xhtml5BaseSink.java#L930.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[
https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806748#comment-17806748
]
ASF GitHub Bot commented on MSHARED-1351:
-
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452231849
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
classical value is `.`, isn't it?
> Confusing message when copying resources from project's baseDir
> ---
>
> Key: MSHARED-1351
> URL: https://issues.apache.org/jira/browse/MSHARED-1351
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When the project base dir is used as the origin path, the relativize in
> https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259
> resolves to empty string, resulting in nothing being displayed path after
> "from" in the console:
> ```
> Copying 118 resources from to target/generated-docs
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452231849
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
classical value is `.`, isn't it?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452232812
##
src/main/java/org/apache/maven/shared/filtering/ConsoleHolder.java:
##
@@ -0,0 +1,88 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.shared.filtering;
+
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.io.PrintStream;
+
+/**
+ * Helping class to capture console input and output for tests.
+ *
+ * @author abelsromero
+ * @since 3.3.2
+ */
+class ConsoleHolder {
Review Comment:
better in `src/test/java` than `src/main/java`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[
https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806750#comment-17806750
]
ASF GitHub Bot commented on MSHARED-1351:
-
hboutemy commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452232812
##
src/main/java/org/apache/maven/shared/filtering/ConsoleHolder.java:
##
@@ -0,0 +1,88 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.shared.filtering;
+
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.io.PrintStream;
+
+/**
+ * Helping class to capture console input and output for tests.
+ *
+ * @author abelsromero
+ * @since 3.3.2
+ */
+class ConsoleHolder {
Review Comment:
better in `src/test/java` than `src/main/java`
> Confusing message when copying resources from project's baseDir
> ---
>
> Key: MSHARED-1351
> URL: https://issues.apache.org/jira/browse/MSHARED-1351
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When the project base dir is used as the origin path, the relativize in
> https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259
> resolves to empty string, resulting in nothing being displayed path after
> "from" in the console:
> ```
> Copying 118 resources from to target/generated-docs
> ```
--
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 merged PR #404: URL: https://github.com/apache/maven-resolver/pull/404 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-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&focusedCommentId=17806757#comment-17806757 ] ASF GitHub Bot commented on MRESOLVER-463: -- cstamas merged PR #404: URL: https://github.com/apache/maven-resolver/pull/404 > 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] [Assigned] (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 reassigned MRESOLVER-463: - Assignee: Romain Manni-Bucau > 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 >Assignee: 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] [Closed] (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 closed MRESOLVER-463. - Resolution: Fixed > 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 >Assignee: 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] (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:comment-tabpanel&focusedCommentId=17806760#comment-17806760 ] Tamas Cservenak commented on MRESOLVER-243: --- Conflict resolver change is quite confined, while DependencyNode is straight forward. The other uses were fixed with new checksum api... so unsure do we really want to do anything in here... > 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)
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
abelsromero commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452265164
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
Are you suggesting to put "." in the message?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[
https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806764#comment-17806764
]
ASF GitHub Bot commented on MSHARED-1351:
-
abelsromero commented on code in PR #93:
URL: https://github.com/apache/maven-filtering/pull/93#discussion_r1452265164
##
src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java:
##
@@ -254,9 +255,15 @@ private File getTargetFile(File file) throws
MavenFilteringException {
Path destination = getDestinationFile(outputDirectory,
targetPath, "", mavenResourcesExecution)
.getAbsoluteFile()
.toPath();
+String origin = basedir.relativize(
+resourceDirectory.getAbsoluteFile().toPath())
+.toString();
+if (StringUtils.isEmpty(origin)) {
+origin = "base directory";
Review Comment:
Are you suggesting to put "." in the message?
> Confusing message when copying resources from project's baseDir
> ---
>
> Key: MSHARED-1351
> URL: https://issues.apache.org/jira/browse/MSHARED-1351
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-filtering
>Affects Versions: maven-filtering-3.3.1
>Reporter: Abel Salgado Romero
>Priority: Minor
>
> When the project base dir is used as the origin path, the relativize in
> https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259
> resolves to empty string, resulting in nothing being displayed path after
> "from" in the console:
> ```
> Copying 118 resources from to target/generated-docs
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MRESOLVER-334] Align spec with implementation [maven-site]
cstamas opened a new pull request, #486: URL: https://github.com/apache/maven-site/pull/486 The spec page had some edge case issues that were actually spec errors (as implementations were rightfully not doing this same). Note: generic version in resolver is authoritative in Maven4 as maven-artifact versions are to be killed off. --- https://issues.apache.org/jira/browse/MRESOLVER-334 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=17806765#comment-17806765
]
ASF GitHub Bot commented on MRESOLVER-334:
--
cstamas opened a new pull request, #486:
URL: https://github.com/apache/maven-site/pull/486
The spec page had some edge case issues that were actually spec errors (as
implementations were rightfully not doing this same).
Note: generic version in resolver is authoritative in Maven4 as
maven-artifact versions are to be killed off.
---
https://issues.apache.org/jira/browse/MRESOLVER-334
> 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] [Assigned] (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 reassigned MRESOLVER-334:
-
Assignee: Tamas Cservenak
> 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
>Assignee: Tamas Cservenak
>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] [Created] (MNG-8019) Streamline update policy of pluginRepository/repository of Maven Central
Konrad Windszus created MNG-8019:
Summary: Streamline update policy of pluginRepository/repository
of Maven Central
Key: MNG-8019
URL: https://issues.apache.org/jira/browse/MNG-8019
Project: Maven
Issue Type: Improvement
Components: Artifacts and Repositories
Reporter: Konrad Windszus
Assignee: Konrad Windszus
Fix For: 3.9.x-candidate
The update policy is set to {{never}} for the Maven Central
{{pluginRepository}}
(https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
while it is the default (= {{daily}}) for the regular repository.
Although it would be nice to set both to {{never}} this does not work with
Resolver 1.x as that treats metadata and artifacts the same (but in fact
metadata is constantly changing even for release repositories like Maven
Central). This situation should improve with Resolver 2.x (Maven 4)
(https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8019) Streamline update policy of pluginRepository/repository of Maven Central in Super POM
[
https://issues.apache.org/jira/browse/MNG-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated MNG-8019:
-
Summary: Streamline update policy of pluginRepository/repository of Maven
Central in Super POM (was: Streamline update policy of
pluginRepository/repository of Maven Central)
> Streamline update policy of pluginRepository/repository of Maven Central in
> Super POM
> -
>
> Key: MNG-8019
> URL: https://issues.apache.org/jira/browse/MNG-8019
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.x-candidate
>
>
> The update policy is set to {{never}} for the Maven Central
> {{pluginRepository}}
> (https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
> while it is the default (= {{daily}}) for the regular repository.
> Although it would be nice to set both to {{never}} this does not work with
> Resolver 1.x as that treats metadata and artifacts the same (but in fact
> metadata is constantly changing even for release repositories like Maven
> Central). This situation should improve with Resolver 2.x (Maven 4)
> (https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] MNG-8019 streamline central update policy [maven]
kwin opened a new pull request, #1381: URL: https://github.com/apache/maven/pull/1381 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8019) Streamline update policy of pluginRepository/repository of Maven Central in Super POM
[
https://issues.apache.org/jira/browse/MNG-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806770#comment-17806770
]
ASF GitHub Bot commented on MNG-8019:
-
kwin opened a new pull request, #1381:
URL: https://github.com/apache/maven/pull/1381
(no comment)
> Streamline update policy of pluginRepository/repository of Maven Central in
> Super POM
> -
>
> Key: MNG-8019
> URL: https://issues.apache.org/jira/browse/MNG-8019
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.x-candidate
>
>
> The update policy is set to {{never}} for the Maven Central
> {{pluginRepository}}
> (https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
> while it is the default (= {{daily}}) for the regular repository.
> Although it would be nice to set both to {{never}} this does not work with
> Resolver 1.x as that treats metadata and artifacts the same (but in fact
> metadata is constantly changing even for release repositories like Maven
> Central). This situation should improve with Resolver 2.x (Maven 4)
> (https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8014] Workaround for deadlocks in model building [maven]
gnodet merged PR #1376: URL: https://github.com/apache/maven/pull/1376 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8014) Maven concurrent model builder deadlocks
[ https://issues.apache.org/jira/browse/MNG-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806778#comment-17806778 ] ASF GitHub Bot commented on MNG-8014: - gnodet merged PR #1376: URL: https://github.com/apache/maven/pull/1376 > Maven concurrent model builder deadlocks > > > Key: MNG-8014 > URL: https://issues.apache.org/jira/browse/MNG-8014 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-10 >Reporter: Guillaume Nodet >Priority: Major > > Building [https://github.com/gnodet/quarkus/tree/maven-deadlock] with Maven > 4.0.0-alpha-12 deadlocks. -- 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&focusedCommentId=17806788#comment-17806788
]
Guillaume Nodet commented on MNG-8017:
--
There's another hidden problem I think.
JLine is supposed to support natively the FreeBSD / x86_64, so if JLine ends up
using the {{exec}} provider, it means the \{{native}} one failed to load, which
is unexpected.
> 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] (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&focusedCommentId=17806796#comment-17806796
]
Guillaume Nodet commented on MNG-8017:
--
The problem is that the JLine bundle does not include the native libraries
anymore. I've raised [https://github.com/jline/jline3/issues/927]
> 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-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:
--
Component/s: Resolver
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>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] [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&focusedCommentId=17806834#comment-17806834 ] Elliotte Rusty Harold commented on MPMD-391: I want less logs, not more. "Running PMD version 6.55.0 to target/pmd.xml" is not info the developer needs or cares about. It is not actionable. Neither is the skin. Neither is the version of the plugin. These are at most, debugging info for plugin developers. They should not be shown to normal end users who just want to build their project. > 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] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806848#comment-17806848
]
Tamas Cservenak commented on MRESOLVER-336:
---
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>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] [Assigned] (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 reassigned MRESOLVER-336:
-
Assignee: Tamas Cservenak
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>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] [Comment Edited] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806848#comment-17806848
]
Tamas Cservenak edited comment on MRESOLVER-336 at 1/15/24 2:23 PM:
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers, IF must, ideally avoid
them.
was (Author: cstamas):
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>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] [Comment Edited] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806848#comment-17806848
]
Tamas Cservenak edited comment on MRESOLVER-336 at 1/15/24 2:24 PM:
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers, IF must, but ideally
avoid them.
was (Author: cstamas):
These two cases (as this issue is about two issues: original description is
about "ga" qualifier, while 1st comment is about "foo" string) are such a
corner cases, that we agree that those are more "undefined" (than
"undocumented"), and both can be circumvented if you use documented versioning
scheme, so basically I am keen to close this issue as "won't fix", as none of
the examples fit under "normal" versioning schemes (they are more like
stretching those).
For start:
* please do not start versions with qualifier or strings, make them start with
number
* stick with documented (and recommended) qualifiers, IF must, ideally avoid
them.
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>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-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 closed MRESOLVER-336.
-
Resolution: Won't Fix
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
>
> 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] [Reopened] (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 reopened MRESOLVER-336:
---
Reopening, to give some time for reporter to respond.
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
>
> 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] [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: (was: 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
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
>
> 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)
[PR] [MRESOLVER-264] Make file locking the default [maven-resolver]
cstamas opened a new pull request, #405: URL: https://github.com/apache/maven-resolver/pull/405 Make file lock factory and file-hgav mapper the default. --- https://issues.apache.org/jira/browse/MRESOLVER-264 -- 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] (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 closed MRESOLVER-243. - Fix Version/s: (was: 2.0.0) Resolution: Not A Problem > 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 > > 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] [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-alpha-7
> 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, 2.0.0-alpha-7
>
>
> 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] [Commented] (MRESOLVER-264) Make file-lock the default locking
[
https://issues.apache.org/jira/browse/MRESOLVER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806853#comment-17806853
]
ASF GitHub Bot commented on MRESOLVER-264:
--
cstamas opened a new pull request, #405:
URL: https://github.com/apache/maven-resolver/pull/405
Make file lock factory and file-hgav mapper the default.
---
https://issues.apache.org/jira/browse/MRESOLVER-264
> 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] [Assigned] (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
]
Guillaume Nodet reassigned MNG-8017:
Assignee: Guillaume Nodet
> 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
>Assignee: Guillaume Nodet
>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] (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
]
Guillaume Nodet updated MNG-8017:
-
Affects Version/s: 4.0.0-alpha-12
(was: 4.0.0-alpha-13)
> 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-12
> 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
>Assignee: Guillaume Nodet
>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] (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
]
Guillaume Nodet updated MNG-8017:
-
Fix Version/s: 4.0.0-alpha-13
> 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-12
> 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
>Assignee: Guillaume Nodet
>Priority: Critical
> Fix For: 4.0.0-alpha-13
>
>
> 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-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:comment-tabpanel&focusedCommentId=17806871#comment-17806871
]
Tamas Cservenak commented on MRESOLVER-233:
---
I disagree with this change (the original PR): the type of the new instance
some methods return contextually depend on current type. For example
SubArtifact.setVersion should NOT return (unmodified) subArtifact with modified
mainArtifact, as in that case we do not talk about subArtifact anymore, but
completely different GAVCE.
In essence, these types are ONLY to help you construct coordinates, it is _very
very rare_ when actual type is needed (only example I know is
RelocatedArtifact, that is cast in core only to get message).
> 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-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: (was: 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
>
> 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-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: (was: 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 > > 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] [Assigned] (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:all-tabpanel
]
Konrad Windszus reassigned MPOM-264:
Assignee: Konrad Windszus
> 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
>Assignee: 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)
[PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin opened a new pull request, #188: URL: https://github.com/apache/maven-apache-parent/pull/188 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188#issuecomment-1892476653 FTR: This is a simplified version of #48 which was declined back then. Nowadays the profile is even used within Maven Parent: https://issues.apache.org/jira/browse/MPOM-447 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[ https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806909#comment-17806909 ] Tamas Cservenak commented on MNG-7539: -- What Maven version you use? When you say "validate snapshot" you mean "resolve snapshot"? You say that one reactor build can download two distinct (timestamped) versions of same -SNAPSHOT dependency? Can you provide a reproducer for this? > Validate/Download SNAPSHOT dependencies once > > > Key: MNG-7539 > URL: https://issues.apache.org/jira/browse/MNG-7539 > Project: Maven > Issue Type: Improvement > Components: Dependencies >Reporter: Adrian Tarau >Priority: Major > > Building an unreleased multi-module project (30-40 modules) that depends on > various other unreleased modules puts significant pressure on the Maven > Repository (a local Nexus instance), and artifact resolution could slow down > the build 2x-3x. > I do acknowledge that it is the job of the repository to cache and serve > those responses fast, and for some reason, sometimes it slows down without an > apparent reason. > However, the whole build process will be faster if Maven validates a SNAPSHOT > once for multi-module (when the dependency is reached the first time) and > then use that version. Even if Maven Repository is relative fast, there is > still network traffic done. Outside the fact that it should not be done, it > might also introduce flaky behaviors: > * one module downloads a version of artifact A, works with it, and > everything is fine > * 10 minutes later, another module needs artifact A and gets a newer > version, which has some issues, and various (test) failures will be raised > For consistency, on a multi-module build, all modules should _see_ the same > version of a SNAPSHOT artifact. It will be faster, and it will be consistent > (which is very important). > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7539) Validate/Download SNAPSHOT dependencies once
[
https://issues.apache.org/jira/browse/MNG-7539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806909#comment-17806909
]
Tamas Cservenak edited comment on MNG-7539 at 1/15/24 4:46 PM:
---
What Maven version you use? When you say "validate snapshot" you mean "resolve
snapshot"? You say that one reactor build can download two distinct
(timestamped) versions of same -SNAPSHOT dependency? Can you provide a
reproducer for this? I can imagine this under very uncommon build settings,
like using {{-U}} per each invocation and having new snapshots deployed (but
even then, one artifact is "refreshed" only once).
was (Author: cstamas):
What Maven version you use? When you say "validate snapshot" you mean "resolve
snapshot"? You say that one reactor build can download two distinct
(timestamped) versions of same -SNAPSHOT dependency? Can you provide a
reproducer for this?
> Validate/Download SNAPSHOT dependencies once
>
>
> Key: MNG-7539
> URL: https://issues.apache.org/jira/browse/MNG-7539
> Project: Maven
> Issue Type: Improvement
> Components: Dependencies
>Reporter: Adrian Tarau
>Priority: Major
>
> Building an unreleased multi-module project (30-40 modules) that depends on
> various other unreleased modules puts significant pressure on the Maven
> Repository (a local Nexus instance), and artifact resolution could slow down
> the build 2x-3x.
> I do acknowledge that it is the job of the repository to cache and serve
> those responses fast, and for some reason, sometimes it slows down without an
> apparent reason.
> However, the whole build process will be faster if Maven validates a SNAPSHOT
> once for multi-module (when the dependency is reached the first time) and
> then use that version. Even if Maven Repository is relative fast, there is
> still network traffic done. Outside the fact that it should not be done, it
> might also introduce flaky behaviors:
> * one module downloads a version of artifact A, works with it, and
> everything is fine
> * 10 minutes later, another module needs artifact A and gets a newer
> version, which has some issues, and various (test) failures will be raised
> For consistency, on a multi-module build, all modules should _see_ the same
> version of a SNAPSHOT artifact. It will be faster, and it will be consistent
> (which is very important).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8020) Support new Resolve 2.0 split policies
Tamas Cservenak created MNG-8020: Summary: Support new Resolve 2.0 split policies Key: MNG-8020 URL: https://issues.apache.org/jira/browse/MNG-8020 Project: Maven Issue Type: Task Affects Versions: 4.0.x-candidate Reporter: Tamas Cservenak The MRESOLVER-377 in resolver 2.0 did split policies, Maven should use this. But, this requires model and many other changes, so consider when to do this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8020) Support new Resolve 2.0 split policies
[ https://issues.apache.org/jira/browse/MNG-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8020: - Description: The MRESOLVER-377 in resolver 2.0 did split policies, Maven should use this. But, this requires model and many other changes, so consider when to do this. Current Maven4 code works in same way as Maven3 does, as Resolver 2.0 handles this (policy Maven sets is applied to both). (was: The MRESOLVER-377 in resolver 2.0 did split policies, Maven should use this. But, this requires model and many other changes, so consider when to do this.) > Support new Resolve 2.0 split policies > -- > > Key: MNG-8020 > URL: https://issues.apache.org/jira/browse/MNG-8020 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.x-candidate >Reporter: Tamas Cservenak >Priority: Major > > The MRESOLVER-377 in resolver 2.0 did split policies, Maven should use this. > But, this requires model and many other changes, so consider when to do this. > Current Maven4 code works in same way as Maven3 does, as Resolver 2.0 handles > this (policy Maven sets is applied to both). -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Simplify graph [maven]
gnodet merged PR #1380: URL: https://github.com/apache/maven/pull/1380 -- 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] MNG-8019 streamline central update policy [maven]
cstamas commented on PR #1381: URL: https://github.com/apache/maven/pull/1381#issuecomment-1892507041 @gnodet was working on this or similar change not so long time ago... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8019) Streamline update policy of pluginRepository/repository of Maven Central in Super POM
[
https://issues.apache.org/jira/browse/MNG-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806912#comment-17806912
]
ASF GitHub Bot commented on MNG-8019:
-
cstamas commented on PR #1381:
URL: https://github.com/apache/maven/pull/1381#issuecomment-1892507041
@gnodet was working on this or similar change not so long time ago...
> Streamline update policy of pluginRepository/repository of Maven Central in
> Super POM
> -
>
> Key: MNG-8019
> URL: https://issues.apache.org/jira/browse/MNG-8019
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.x-candidate
>
>
> The update policy is set to {{never}} for the Maven Central
> {{pluginRepository}}
> (https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
> while it is the default (= {{daily}}) for the regular repository.
> Although it would be nice to set both to {{never}} this does not work with
> Resolver 1.x as that treats metadata and artifacts the same (but in fact
> metadata is constantly changing even for release repositories like Maven
> Central). This situation should improve with Resolver 2.x (Maven 4)
> (https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Publish Maven 4.0.0-alpha-12 [maven-site]
gnodet opened a new pull request, #487: URL: https://github.com/apache/maven-site/pull/487 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Publish Maven 4.0.0-alpha-12 [maven-site]
gnodet merged PR #487: URL: https://github.com/apache/maven-site/pull/487 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (SUREFIRE-2233) Unable to create file for report (File name too long)
Filipe Roque created SUREFIRE-2233:
--
Summary: Unable to create file for report (File name too long)
Key: SUREFIRE-2233
URL: https://issues.apache.org/jira/browse/SUREFIRE-2233
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 3.2.5
Environment: Linux with encripted home using ecryptfs
Reporter: Filipe Roque
surefire tries to create report files where the filename includes the package.
On Linux with eCryptfs, it easily fails with _File name too long_ ([What is the
maximum allowed filename (and folder) size with
eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
without failing the maven build.
* Should this error fail the build ?
* What is the solution for this, besides shorter packages and file names, or
non encrypted file systems ?
** Maybe create sub directories under target/surefire-reports matching the
packages
** shorten the filename like logback
(https://logback.qos.ch/manual/layouts.html#conversionWord)
*pom.xml*
{code:java}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
org.example
long-filenames
1.0-SNAPSHOT
21
21
UTF-8
org.junit.jupiter
junit-jupiter-api
5.10.1
test
org.apache.maven.plugins
maven-surefire-plugin
3.2.5
{code}
{*}src/test/java/package1/subpackage2/subpackage3/subpackage4/subpackage5/subpackage6/subpackage7/TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.java{*}{*}{*}
{code:java}
{code}
*package
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
public class
TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName \{
@Test
public void test() {
Assertions.assertTrue(true);
}
}*
{code:java}
{code}
*❯ /opt/maven/apache-maven-3.9.5/bin/mvn clean package
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.example:long-filenames >-
[INFO] Building long-filenames 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- clean:3.2.0:clean (default-clean) @ long-filenames ---
[INFO] Deleting /home/froque/workspace/testes/long-filenames/target
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ long-filenames ---
[INFO] Copying 0 resource from src/main/resources to target/classes
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ long-filenames ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @
long-filenames ---
[INFO] skip non existing resourceDirectory
/home/froque/workspace/testes/long-filenames/src/test/resources
[INFO]
[INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ long-filenames
---
[INFO] Changes detected - recompiling the module! :source
[INFO] Compiling 1 source file with javac [debug target 21] to
target/test-classes
[INFO]
[INFO] --- surefire:3.2.5:test (default-test) @ long-filenames ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
[WARNING] ForkStarter IOException: Unable to create file for report:
/home/froque/workspace/testes/long-filenames/target/surefire-reports/package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.txt
(File name too long). See the dump file
/home/froque/workspace/testes/long-filenames/target/surefire-reports/2024-01-15T16-58-22_070-jvmRun1.dumpstream
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] --- jar:3.3.0:jar (default-jar) @ long-filenames ---
[INFO] Building jar:
/home/froque/workspace/testes/long-filenames/target/long-filenames-1.0-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.523 s
[INFO] Finished at: 2024-01-15T16:58:22Z
[INFO]
*
--
This message w
[jira] [Updated] (SUREFIRE-2233) Unable to create file for report (File name too long)
[
https://issues.apache.org/jira/browse/SUREFIRE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Roque updated SUREFIRE-2233:
---
Description:
surefire tries to create report files where the filename includes the package.
On Linux with eCryptfs, it easily fails with _File name too long_ ([What is the
maximum allowed filename (and folder) size with
eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
without failing the maven build.
* Should this error fail the build ?
* What is the solution for this, besides shorter packages and file names, or
non encrypted file systems ?
** Maybe create sub directories under target/surefire-reports matching the
packages
** shorten the filename like logback
([https://logback.qos.ch/manual/layouts.html#conversionWord])
*pom.xml*
{code:java}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
org.example
long-filenames
1.0-SNAPSHOT
21
21
UTF-8
org.junit.jupiter
junit-jupiter-api
5.10.1
test
org.apache.maven.plugins
maven-surefire-plugin
3.2.5
{code}
{*}src/test/java/package1/subpackage2/subpackage3/subpackage4/subpackage5/subpackage6/subpackage7/TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.java{*}{*}{{*}}
{code:java}
package
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
public class
TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName {
@Test
public void test() {
Assertions.assertTrue(true);
}
}
{code}
{code:java}
/opt/maven/apache-maven-3.9.5/bin/mvn clean test
[INFO] Scanning for projects...
[INFO]
[INFO] -< org.example:long-filenames >-
[INFO] Building long-filenames 1.0-SNAPSHOT
[INFO] from pom.xml
[INFO] [ jar ]-
[INFO]
[INFO] --- clean:3.2.0:clean (default-clean) @ long-filenames ---
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ long-filenames ---
[INFO] Copying 0 resource from src/main/resources to target/classes
[INFO]
[INFO] --- compiler:3.11.0:compile (default-compile) @ long-filenames ---
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @
long-filenames ---
[INFO] skip non existing resourceDirectory
/home/froque/workspace/testes/long-filenames/src/test/resources
[INFO]
[INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ long-filenames
---
[INFO] Changes detected - recompiling the module! :source
[INFO] Compiling 1 source file with javac [debug target 21] to
target/test-classes
[INFO]
[INFO] --- surefire:3.2.5:test (default-test) @ long-filenames ---
[INFO] Using auto detected provider
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 s
-- in
package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.269 s
[INFO] Finished at: 2024-01-15T17:14:48Z
[INFO]
{code}
was:
surefire tries to create report files where the filename includes the package.
On Linux with eCryptfs, it easily fails with _File name too long_ ([What is the
maximum allowed filename (and folder) size with
eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
without failing the maven build.
* Should this error fail the build ?
* What is the solution for this, besides shorter packages and file names, or
non encrypted file systems ?
** Maybe create sub directories under target/surefire-reports matching the
packages
** shorten the filename like logback
(https://logback.qos.ch/manual/layouts.html#conversionWord)
[jira] [Commented] (MRESOLVER-336) Unexpected handling of qualifiers in GenericVersionScheme
[
https://issues.apache.org/jira/browse/MRESOLVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806925#comment-17806925
]
David M. Lloyd commented on MRESOLVER-336:
--
There are many thousand artifacts already in the wild using qualifiers, both
standard and custom, so I think that ship has sailed. But in any event, the
version syntax must be well-defined for all allowed cases, otherwise it's not
really a syntax. The behavior should be completely predictable.
Many of these bug reports came from me trying to determine or establish the
"true" syntactic rules of Maven versions. The code disagrees with itself every
place it is implemented, and the developers also seem to disagree with one
another on what these rules should be. But based on feedback from developers on
this and other issues, I think the most generally-accepted rules when
considering spec intent, existing usage, and existing code are as follows:
* Versions should be compared by segment, from left to right, where each
segment is defined and ordered as follows (from earliest to latest):
** The qualifier "alpha" == "a" (but only when "a" is immediately followed by
a number)
** The qualifier "beta" == "b" (but only when "b" is immediately followed by a
number)
** The qualifier "milestone" = "m" (but only when "m" is immediately followed
by a number)
** The qualifier "rc" == "cr"
** The qualifier "snapshot"
** The empty string == the number zero == "ga" == "final" == "release" (I call
these "zero segments" down below)
** The qualifier "sp"
** Any "custom" qualifier (i.e. non-empty letter sequence) sorted
lexicographically per {{ROOT}} locale, ascending
** Any positive integer sorted numerically ascending
* Segments can be explicitly separated by a single {{.}} (dot) or {{-}}
(hyphen) (one proposal also included {{_}} (underscore) as a separator)
* All qualifiers (not just custom qualifiers) are interpreted as being
case-insensitive in terms of the {{ROOT}} locale (that is, "FINAL" is equal to
"final", not "fınal")
* A zero-width segment separator also exists between any two segments when one
of the two segments is a number of any kind (including 0) and the other is a
alphabetical qualifier of any kind (including special qualifiers)
* Finally, any version can be considered to have an infinite number of
invisible *trailing* "zero" segments, for the purposes of comparison (in other
words, "1" == "1.0.0.0.0.0.0.0.0")
According to the above rules, I think that the example version I gave above
"0.0.0.ga.ga.foo" should *not* be equal to "foo" exactly as "0.0.1" should not
be equal to "1". It *should* be equal to "0.0.0.0.0.foo". The issue itself is
due to the {{ga}} qualifier being equal to zero *sometimes* but not other
times. This inconsistency is the problem and should be fixed as described above.
I don't think it is realistic to get all or even most Java devs to agree on one
version {*}scheme{*}. However I do think it is not only realistic but
*critical* that we all agree on one version {*}syntax{*}. And, I think the
above is it, more or less, since it seems to eliminate most (maybe all) of the
problem cases that I could find in existing artifacts.
> Unexpected handling of qualifiers in GenericVersionScheme
> -
>
> Key: MRESOLVER-336
> URL: https://issues.apache.org/jira/browse/MRESOLVER-336
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.5
>Reporter: David M. Lloyd
>Assignee: Tamas Cservenak
>Priority: Major
>
> 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 doe
[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&focusedCommentId=17806926#comment-17806926 ] Abel Salgado Romero commented on DOXIA-725: --- Thanks, wouldn't it make sense to merge all in the same repo under the same parent? Now that we have the chance to make breaking changes? > 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)
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452651203
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
should we enforce with
https://maven.apache.org/enforcer/enforcer-rules/requireProperty.html that this
property value does no longer start with "1."?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [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&focusedCommentId=17806931#comment-17806931 ] Konrad Windszus edited comment on DOXIA-725 at 1/15/24 6:14 PM: It makes sense to be able to release Doxia Sitetools alone (without Doxia), but is no that useful the other way around. To be able to have this flexibility it is reasonable to have them in dedicated repositories. Also it is a matter of effort, usually the Doxia changes are done first. Is there any reason why you cannot stick to Doxia M8 for the moment? was (Author: kwin): It makes sense to be able to release Doxia Sitetools alone (without Doxia), but is no that useful the other way around. To be able to have this flexibility it is reasonable to have them in dedicated repositories. Also it is a matter of effort, usually the Doxia changes are done first. Is there any reason why cannot stick to Doxia M8 for the moment? > 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&focusedCommentId=17806931#comment-17806931 ] Konrad Windszus commented on DOXIA-725: --- It makes sense to be able to release Doxia Sitetools alone (without Doxia), but is no that useful the other way around. To be able to have this flexibility it is reasonable to have them in dedicated repositories. Also it is a matter of effort, usually the Doxia changes are done first. Is there any reason why cannot stick to Doxia M8 for the moment? > 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)
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
slawekjaranowski commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452659630
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
I'm not sure if `7` is supported maybe it is time to switch it to `8`
--
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-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452660696
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
yes it is: back to 5 if javac 8 is used,
https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html#BHCDIFEE
--
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-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452661893
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
javac 17 still supports 7, only javac 21 only supports 8+.
--
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-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
kwin commented on code in PR #188:
URL:
https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452661893
##
pom.xml:
##
@@ -93,8 +93,9 @@ under the License.
true
3.6.3
1.8
+
${maven.compiler.target}
-1.7
+7
Review Comment:
javac 17 still supports 7, only javac21 only supports 8+.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-8019) Streamline update policy of pluginRepository/repository of Maven Central in Super POM
[
https://issues.apache.org/jira/browse/MNG-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806935#comment-17806935
]
ASF GitHub Bot commented on MNG-8019:
-
kwin commented on PR #1381:
URL: https://github.com/apache/maven/pull/1381#issuecomment-1892625986
For Maven 4 both are already at the default (=daily), being applied in
https://github.com/apache/maven/commit/fb612f5dbc89d8e268bc3581e538c392c1fff788.
So this is basically the backport of MNG-6112.
> Streamline update policy of pluginRepository/repository of Maven Central in
> Super POM
> -
>
> Key: MNG-8019
> URL: https://issues.apache.org/jira/browse/MNG-8019
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: 3.9.x-candidate
>
>
> The update policy is set to {{never}} for the Maven Central
> {{pluginRepository}}
> (https://github.com/apache/maven/blob/b23afbc9849d57b0a4ff0f2bdd3fff5520a95f7c/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L48)
> while it is the default (= {{daily}}) for the regular repository.
> Although it would be nice to set both to {{never}} this does not work with
> Resolver 1.x as that treats metadata and artifacts the same (but in fact
> metadata is constantly changing even for release repositories like Maven
> Central). This situation should improve with Resolver 2.x (Maven 4)
> (https://issues.apache.org/jira/browse/MRESOLVER-377).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] MNG-8019 streamline central update policy [maven]
kwin commented on PR #1381: URL: https://github.com/apache/maven/pull/1381#issuecomment-1892625986 For Maven 4 both are already at the default (=daily), being applied in https://github.com/apache/maven/commit/fb612f5dbc89d8e268bc3581e538c392c1fff788. So this is basically the backport of MNG-6112. -- 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] (MRESOLVER-464) JDK transport bug
Tamas Cservenak created MRESOLVER-464: - Summary: JDK transport bug Key: MRESOLVER-464 URL: https://issues.apache.org/jira/browse/MRESOLVER-464 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-7 JDK transport seems can be plagued by https://bugs.openjdk.org/browse/JDK-8225647 Try to do something about this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPOM-450) Prevent the SCM elements from being inherited
[ https://issues.apache.org/jira/browse/MPOM-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus closed MPOM-450. Resolution: Won't Fix > Prevent the SCM elements from being inherited > - > > Key: MPOM-450 > URL: https://issues.apache.org/jira/browse/MPOM-450 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-31 >Reporter: Konrad Windszus >Priority: Major > > Currently the SCM elements are not encapsulated in a profile, i.e. they are > automatically inherited by all derived projects. As those never share > anything with the SCM URLs of the ASF parent it would make sense to only > conditionally set those SCM elements (in a profile). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPOM-450) Prevent the SCM elements from being inherited
[
https://issues.apache.org/jira/browse/MPOM-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806938#comment-17806938
]
Konrad Windszus commented on MPOM-450:
--
The {{scm}} element cannot be set within a profile
(https://maven.apache.org/pom.html#Profiles).
> Prevent the SCM elements from being inherited
> -
>
> Key: MPOM-450
> URL: https://issues.apache.org/jira/browse/MPOM-450
> Project: Maven POMs
> Issue Type: Bug
> Components: asf
>Affects Versions: ASF-31
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently the SCM elements are not encapsulated in a profile, i.e. they are
> automatically inherited by all derived projects. As those never share
> anything with the SCM URLs of the ASF parent it would make sense to only
> conditionally set those SCM elements (in a profile).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPOM-255) Enforce local property "project.build.outputTimestamp" for reproducible builds
[ https://issues.apache.org/jira/browse/MPOM-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806939#comment-17806939 ] Konrad Windszus commented on MPOM-255: -- FTR: change has been reverted in MPOM-265. > Enforce local property "project.build.outputTimestamp" for reproducible builds > -- > > Key: MPOM-255 > URL: https://issues.apache.org/jira/browse/MPOM-255 > Project: Maven POMs > Issue Type: Improvement > Components: asf >Affects Versions: ASF-23 >Reporter: Konrad Windszus >Assignee: Michael Osipov >Priority: Major > Fix For: ASF-24 > > > In case the release's root pom.xml doesn't overwrite > "project.build.outputTimestamp" it takes the value from > [https://github.com/apache/maven-apache-parent/blob/4813409e6a1ecfea11c8eb22a5f0443f790f1454/pom.xml#L95.] > Instead of the fallback an enforcer rule should be added to require a > property "project.build.outputTimestamp" to be set in the right format for > reproducible builds to work > ([https://maven.apache.org/guides/mini/guide-reproducible-builds.html#how-do-i-configure-my-maven-build]) > for every pom.xml locally. > Only that way the timestamps are automatically adjusted with each release > (https://issues.apache.org/jira/browse/MRELEASE-1029) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [MPOM-365] Remove no longer used ".maven-apache-parent.marker" file [maven-apache-parent]
kwin opened a new pull request, #189: URL: https://github.com/apache/maven-apache-parent/pull/189 This has been introduced in MPOM-255 for enabling a profile only when building the ASF parent itself. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-2233) Unable to create file for report (File name too long)
[
https://issues.apache.org/jira/browse/SUREFIRE-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17806942#comment-17806942
]
Michael Osipov commented on SUREFIRE-2233:
--
Where is the failure?
> Unable to create file for report (File name too long)
> --
>
> Key: SUREFIRE-2233
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2233
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.2.5
> Environment: Linux with encripted home using ecryptfs
>Reporter: Filipe Roque
>Priority: Major
>
> surefire tries to create report files where the filename includes the package.
> On Linux with eCryptfs, it easily fails with _File name too long_ ([What is
> the maximum allowed filename (and folder) size with
> eCryptfs?|https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs/32834]),
> without failing the maven build.
>
> * Should this error fail the build ?
> * What is the solution for this, besides shorter packages and file names, or
> non encrypted file systems ?
> ** Maybe create sub directories under target/surefire-reports matching the
> packages
> ** shorten the filename like logback
> ([https://logback.qos.ch/manual/layouts.html#conversionWord])
>
> *pom.xml*
> {code:java}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> org.example
> long-filenames
> 1.0-SNAPSHOT
>
>21
>21
>UTF-8
>
>
>
> org.junit.jupiter
> junit-jupiter-api
> 5.10.1
> test
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 3.2.5
>
>
>
>
> {code}
> {*}src/test/java/package1/subpackage2/subpackage3/subpackage4/subpackage5/subpackage6/subpackage7/TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName.java{*}{*}{{*}}
>
> {code:java}
> package
> package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7;
> import org.junit.jupiter.api.Assertions;
> import org.junit.jupiter.api.Test;
> public class
> TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName {
> @Test
> public void test() {
>Assertions.assertTrue(true);
> }
> }
> {code}
>
>
>
>
> {code:java}
> /opt/maven/apache-maven-3.9.5/bin/mvn clean test
> [INFO] Scanning for projects...
> [INFO]
> [INFO] -< org.example:long-filenames
> >-
> [INFO] Building long-filenames 1.0-SNAPSHOT
> [INFO] from pom.xml
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- clean:3.2.0:clean (default-clean) @ long-filenames ---
> [INFO]
> [INFO] --- resources:3.3.1:resources (default-resources) @ long-filenames ---
> [INFO] Copying 0 resource from src/main/resources to target/classes
> [INFO]
> [INFO] --- compiler:3.11.0:compile (default-compile) @ long-filenames ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- resources:3.3.1:testResources (default-testResources) @
> long-filenames ---
> [INFO] skip non existing resourceDirectory
> /home/froque/workspace/testes/long-filenames/src/test/resources
> [INFO]
> [INFO] --- compiler:3.11.0:testCompile (default-testCompile) @ long-filenames
> ---
> [INFO] Changes detected - recompiling the module! :source
> [INFO] Compiling 1 source file with javac [debug target 21] to
> target/test-classes
> [INFO]
> [INFO] --- surefire:3.2.5:test (default-test) @ long-filenames ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [INFO] Running
> package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031
> s -- in
> package1.subpackage2.subpackage3.subpackage4.subpackage5.subpackage6.subpackage7.TestWithAVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongFileName
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.269 s
> [INFO] Finished at: 2024-01-15T17:14:48Z
> [INFO]
>
[PR] Bump org.htmlunit:htmlunit from 3.9.0 to 3.10.0 [maven-surefire]
dependabot[bot] opened a new pull request, #717: URL: https://github.com/apache/maven-surefire/pull/717 Bumps [org.htmlunit:htmlunit](https://github.com/HtmlUnit/htmlunit) from 3.9.0 to 3.10.0. Release notes Sourced from https://github.com/HtmlUnit/htmlunit/releases";>org.htmlunit:htmlunit's releases. HtmlUnit 3.10.0 Highlights This release is not compatible with 2.xx versions - please read the https://www.htmlunit.org/migration.html";>migration info Chrome/Edge 120, Firefox 120 many fixes for the neko html parser, rewritten script tag content parsing and better comment handling, unknown elements are always moved to the body, and many more core-js tons of fixes and improvements String.includes/startsWith/endsWith no longer throws a TypeError when the first argument is a regex and Symbol.match of that regex has been set to false String.prototype.replaceAll implemented RegExp.dotAll flag implemented Symbol.iterator property is now available on CSSStyleDeclaration/ComputedCSSStyleDeclaration many more fixes and improvements Please have a look at the https://www.htmlunit.org/changes-report.html#a3.10.0";>full release notes for details about this release. 💕 Thank you to all who have contributed and to the sponsors (more sponsoring is welcome https://github.com/sponsors/rbri";>https://github.com/sponsors/rbri). Commits https://github.com/HtmlUnit/htmlunit/commit/48587149cb92dc79fb7c78b2ad0c78535b45263b";>4858714 version 3.10.0 https://github.com/HtmlUnit/htmlunit/commit/b997e79f11591af810da00aabe5800ff93b80f24";>b997e79 core-js release https://github.com/HtmlUnit/htmlunit/commit/d7daeefde0022268c4318ea26543767f4f10d3b0";>d7daeef link fixes https://github.com/HtmlUnit/htmlunit/commit/afef30981912417725f4420ea987ab6a26b7a6ce";>afef309 missing file https://github.com/HtmlUnit/htmlunit/commit/747f6443f4cfd3c686dcbd524f3bcd8e1593a67f";>747f644 ups https://github.com/HtmlUnit/htmlunit/commit/c7bfb7932a865af8a84f79a885c83d4222844753";>c7bfb79 use released versions https://github.com/HtmlUnit/htmlunit/commit/a68d16b3cf6c5bbb66ec97e66dfe45ef4cc86274";>a68d16b change timeout https://github.com/HtmlUnit/htmlunit/commit/b33447a0a42d4bdff9965e020730cab742da9ded";>b33447a fix https://github.com/HtmlUnit/htmlunit/commit/fb98a83118f05888982f4b6ec6da83a569d855f8";>fb98a83 fix tests for the new webClient setup https://github.com/HtmlUnit/htmlunit/commit/36bd5639609cf97c3eb000261beecd404b5c1b60";>36bd563 improve the code check for performance Additional commits viewable in https://github.com/HtmlUnit/htmlunit/compare/3.9.0...3.10.0";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@ma
Re: [PR] [MPOM-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
slawekjaranowski commented on code in PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452687769 ## pom.xml: ## @@ -403,6 +403,26 @@ under the License. + +enforce-maven.compiler.target-version + + enforce + + + + + maven.compiler.target + (?!1\.).* + The value of property maven.compiler.target must not start with "1.", use for example "8" instead of "1.8"! + + + maven.compiler.source + (?!1\.).* + The value of property maven.compiler.source must not start with "1.", use for example "8" instead of "1.8"! + + + + Review Comment: I would like to not add next execution, simply if user has wrong value build will fail. -- 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-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
michael-o commented on code in PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452689833 ## pom.xml: ## @@ -403,6 +403,26 @@ under the License. + +enforce-maven.compiler.target-version + + enforce + + + + + maven.compiler.target + (?!1\.).* + The value of property maven.compiler.target must not start with "1.", use for example "8" instead of "1.8"! + + + maven.compiler.source + (?!1\.).* + The value of property maven.compiler.source must not start with "1.", use for example "8" instead of "1.8"! + + + + Review Comment: I'll let it fail implicitly... -- 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-264] Set "maven.compiler.release" on JDK 9+ [maven-apache-parent]
michael-o commented on code in PR #188: URL: https://github.com/apache/maven-apache-parent/pull/188#discussion_r1452690304 ## pom.xml: ## @@ -525,6 +545,17 @@ under the License. + + jdk9ornewer Review Comment: Make is simple: `jdk9+`? -- 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
