[jira] [Commented] (MJAVADOC-815) Aggregate goal misses skipped reactor modules when resuming build
[
https://issues.apache.org/jira/browse/MJAVADOC-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884884#comment-17884884
]
Maarten Mulders commented on MJAVADOC-815:
--
Don't worry, I don't see it as a lame excuse.
If your finding is indeed an issue in Core, not in the Maven Javadoc Plugin -
as [~michael-o] and I are thinking - then there is, unfortunately, no way this
can be fixed in the Maven Javadoc Plugin.
Would it be possible for you to extract the problem from where you observe it
(probably a large, closed-source project?) to a minimal example which
illustrates the problem? It might be easier to run that minimal reproducer with
Maven 4 and observe if the problem is still there.
> Aggregate goal misses skipped reactor modules when resuming build
> -
>
> Key: MJAVADOC-815
> URL: https://issues.apache.org/jira/browse/MJAVADOC-815
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> When resuming a build using {{-rf}}, then the {{javadoc:aggregate}} goal is
> not injected with the reactor modules that are skipped (are before the module
> being resumed from).
> That means the JavaDoc for those skipped modules is not included in the
> aggregate.
> I can imagine that to happen when I build using {{-pl}} to build individual
> modules, but if I resume, I would expect all the reactor modules that have
> already been covered and are being resumed over to be part of the reactor
> modules that are provided to the javadoc plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MJAVADOC-815) Aggregate goal misses skipped reactor modules when resuming build
[
https://issues.apache.org/jira/browse/MJAVADOC-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17884881#comment-17884881
]
Maarten Mulders commented on MJAVADOC-815:
--
{quote}I wonder whether this is a plugin issue or rather a Maven Core issue.
[~gnodet], [~mthmulders], [~cstamas], WDYT?
{quote}
Try running the plugin with a Maven 4 beta and see if it behaves the same.
Given the major overhaul of the Reactor w.r.t. how {{-rf}} works, I guess that
this is an issue in Core that is resolved in Maven 4.
> Aggregate goal misses skipped reactor modules when resuming build
> -
>
> Key: MJAVADOC-815
> URL: https://issues.apache.org/jira/browse/MJAVADOC-815
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.10.0
>Reporter: Richard Eckart de Castilho
>Priority: Major
>
> When resuming a build using {{-rf}}, then the {{javadoc:aggregate}} goal is
> not injected with the reactor modules that are skipped (are before the module
> being resumed from).
> That means the JavaDoc for those skipped modules is not included in the
> aggregate.
> I can imagine that to happen when I build using {{-pl}} to build individual
> modules, but if I resume, I would expect all the reactor modules that have
> already been covered and are being resumed over to be part of the reactor
> modules that are provided to the javadoc plugin.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7344) Effective pom should contain more finegrained details regarding its content origin: track dependencyManagement import
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832592#comment-17832592 ] Maarten Mulders commented on MNG-7344: -- [~gnodet] agreed. I don't think backporting to Maven 3.x is worth the effort, seeing how much work has been necessary to get this to a working point. > Effective pom should contain more finegrained details regarding its content > origin: track dependencyManagement import > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > Fix For: 3.9.x-candidate, 4.0.x-candidate > > Attachments: MicrosoftTeams-image.png > > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the "resolution path" to that element. > Until now, only the usual pure inheritance is tracked though InputLocation, > as done in MNG-1803, later displayed by verbose help effective-pom with > MPH-160 > The following are known to add elements to the effective pom: > - BOMs dependencyManagement import > - [Tiles Maven Plugin|https://github.com/repaint-io/maven-tiles] by [~talios] > Without this feature, it is very hard to detect where these extra elements > are coming from. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8067) Refer to latest schema for extensions.xml
[ https://issues.apache.org/jira/browse/MNG-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders closed MNG-8067. Fix Version/s: 4.0.0-alpha-13 Resolution: Fixed Resolved with [73b0e40|https://github.com/apache/maven-site/commit/73b0e40bb16dcb1b9007e7d9ae3b020ac3539702]. > Refer to latest schema for extensions.xml > - > > Key: MNG-8067 > URL: https://issues.apache.org/jira/browse/MNG-8067 > Project: Maven > Issue Type: Task > Components: Documentation: Introductions > Environment: https://maven.apache.org/configure.html, retrieved March > 4, 2024 >Reporter: Maarten Mulders >Assignee: Maarten Mulders >Priority: Trivial > Fix For: 4.0.0-alpha-13 > > > The ["Configuring Apache Maven" page|https://maven.apache.org/configure.html] > refers to an older version of the *extensions.xml* schema: 1.0.0, while 1.1.0 > is out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8067) Refer to latest schema for extensions.xml
Maarten Mulders created MNG-8067: Summary: Refer to latest schema for extensions.xml Key: MNG-8067 URL: https://issues.apache.org/jira/browse/MNG-8067 Project: Maven Issue Type: Task Components: Documentation: Introductions Environment: https://maven.apache.org/configure.html, retrieved March 4, 2024 Reporter: Maarten Mulders Assignee: Maarten Mulders The ["Configuring Apache Maven" page|https://maven.apache.org/configure.html] refers to an older version of the *extensions.xml* schema: 1.0.0, while 1.1.0 is out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8065) Maven console's colored output does not work in 4.0.0-alpha12
[ https://issues.apache.org/jira/browse/MNG-8065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MNG-8065: - Attachment: (was: image-2024-03-03-15-11-48-742.png) > Maven console's colored output does not work in 4.0.0-alpha12 > - > > Key: MNG-8065 > URL: https://issues.apache.org/jira/browse/MNG-8065 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-12 > Environment: Windows 10 >Reporter: Matthias Bünger >Priority: Minor > Attachments: image-2024-03-03-15-12-39-711.png, nocolor.png > > > Today I mentioned that the colored output in the console does not work with > 4.0.0-alpha-12 anymore. > !nocolor.png! > This was already mentioned by [~atual] in #MNG-6380 but as that ticket is > closed I decided to open a new one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8065) Maven console's colored output does not work in 4.0.0-alpha12
[ https://issues.apache.org/jira/browse/MNG-8065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17822942#comment-17822942 ] Maarten Mulders commented on MNG-8065: -- Could it be something Windows-specific? I'm running macOS, and it seems to work: !image-2024-03-03-15-12-39-711.png! > Maven console's colored output does not work in 4.0.0-alpha12 > - > > Key: MNG-8065 > URL: https://issues.apache.org/jira/browse/MNG-8065 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-12 > Environment: Windows 10 >Reporter: Matthias Bünger >Priority: Minor > Attachments: image-2024-03-03-15-12-39-711.png, nocolor.png > > > Today I mentioned that the colored output in the console does not work with > 4.0.0-alpha-12 anymore. > !nocolor.png! > This was already mentioned by [~atual] in #MNG-6380 but as that ticket is > closed I decided to open a new one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8065) Maven console's colored output does not work in 4.0.0-alpha12
[ https://issues.apache.org/jira/browse/MNG-8065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MNG-8065: - Attachment: image-2024-03-03-15-12-39-711.png > Maven console's colored output does not work in 4.0.0-alpha12 > - > > Key: MNG-8065 > URL: https://issues.apache.org/jira/browse/MNG-8065 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-12 > Environment: Windows 10 >Reporter: Matthias Bünger >Priority: Minor > Attachments: image-2024-03-03-15-12-39-711.png, nocolor.png > > > Today I mentioned that the colored output in the console does not work with > 4.0.0-alpha-12 anymore. > !nocolor.png! > This was already mentioned by [~atual] in #MNG-6380 but as that ticket is > closed I decided to open a new one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8065) Maven console's colored output does not work in 4.0.0-alpha12
[ https://issues.apache.org/jira/browse/MNG-8065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MNG-8065: - Attachment: image-2024-03-03-15-11-48-742.png > Maven console's colored output does not work in 4.0.0-alpha12 > - > > Key: MNG-8065 > URL: https://issues.apache.org/jira/browse/MNG-8065 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-12 > Environment: Windows 10 >Reporter: Matthias Bünger >Priority: Minor > Attachments: image-2024-03-03-15-11-48-742.png, nocolor.png > > > Today I mentioned that the colored output in the console does not work with > 4.0.0-alpha-12 anymore. > !nocolor.png! > This was already mentioned by [~atual] in #MNG-6380 but as that ticket is > closed I decided to open a new one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MENFORCER-499) New Rule: Prohibit specific files to be checked in
[ https://issues.apache.org/jira/browse/MENFORCER-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818558#comment-17818558 ] Maarten Mulders commented on MENFORCER-499: --- I think there is one more alternative: use .gitignore / .hgignore / .bzrignore etc. I might be missing something, but what would this rule in Maven Enforcer add on top of that, other than failing a build if the rule is violated? > New Rule: Prohibit specific files to be checked in > -- > > Key: MENFORCER-499 > URL: https://issues.apache.org/jira/browse/MENFORCER-499 > Project: Maven Enforcer Plugin > Issue Type: New Feature > Components: Standard Rules >Reporter: Benjamin Marwell >Priority: Major > > This is a suggestion for yet another new standard rule. > "require Files not checked in" > While there are already rules "require files don't exist" and "require file > size", this one would check wether files are actually checked in or added > into the current VCS. > E.g. for each file in the pattern: > * check if they are added (git, bzr) or checked in (cvs, svn, bzr, git) > * If so, fail the build. > configurable options: > * files (like the other two checks, ant pattern) > * failOnAdd (git, bzr): true by default, can be set to false. Then the check > will only fail if files are currently in a commit. > * useDefaultExclusions: Read exclusion rules from VCS (git: .gitignore, svn: > svn:ignore, etc.). However, files could have been forcibly added in git. So > maybe this doesn't make much sense > * skip > * ..? > The idea is to prevent developers from accidentally check in big files (like > jar files, zip files) or other binary artifacts. While this could be spotted > in a PR, the repo might already be spoiled and enlarged by this size, which > is usually not feasible. > Alternatives: > * use "files don't exist" and exclude target (may not work for everyone) > * use a shell script > * don't implement this rule and leave the task to others. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8004) Enhance location tracking
[ https://issues.apache.org/jira/browse/MNG-8004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17805227#comment-17805227 ] Maarten Mulders commented on MNG-8004: -- I guess this relates to MNG-7344? Or maybe even duplicates it? > Enhance location tracking > - > > Key: MNG-8004 > URL: https://issues.apache.org/jira/browse/MNG-8004 > Project: Maven > Issue Type: Task > Components: Core >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-11 > > > So far location tracking gives us source file, line num and col num, which is > fine. > But historically, Maven2 had only parent POMs, Maven3 introduced import POMs, > while Maven4 will have things like XInclude as well. > It would be great if we could enhance location with 4th element: "why (or > how) did this element end up here". Was it from current POM, from parent > maybe? From import-pom? Or was it XIncluded? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7919) Missing .mvn directory is only reported in DEBUG mode
[
https://issues.apache.org/jira/browse/MNG-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779854#comment-17779854
]
Maarten Mulders commented on MNG-7919:
--
Agreed. I think it makes sense to log this at INFO level.
> Missing .mvn directory is only reported in DEBUG mode
> -
>
> Key: MNG-7919
> URL: https://issues.apache.org/jira/browse/MNG-7919
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Currently the alpha-8 version of Maven only reports the missing {{.mvn}}
> directory only if I activate the debugging output:
> {code}
> [DEBUG] Unable to find the root directory. Create a .mvn directory in the
> root directory or add the root="true" attribute on the root project's model
> to identify it.
> Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
> Maven home: /Users/khm/tools/maven
> Java version: 22-ea, vendor: Oracle Corporation, runtime:
> /Users/khm/.sdkman/candidates/java/22.ea.20-open
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
> {code}
> None debug output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> --
> [INFO] Reactor Build Order:
> ...
> {code}
> The question is: Should it be reported in usual output or not? Or only in
> debug mode? I would say report it not only in DEBUG mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7919) Missing .mvn directory is only reported in DEBUG mode
[
https://issues.apache.org/jira/browse/MNG-7919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7919:
-
Labels: up-for-grabs (was: )
> Missing .mvn directory is only reported in DEBUG mode
> -
>
> Key: MNG-7919
> URL: https://issues.apache.org/jira/browse/MNG-7919
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Affects Versions: 4.0.0-alpha-8
>Reporter: Karl Heinz Marbaise
>Priority: Minor
> Labels: up-for-grabs
> Fix For: 4.0.0, 4.0.0-alpha-9
>
>
> Currently the alpha-8 version of Maven only reports the missing {{.mvn}}
> directory only if I activate the debugging output:
> {code}
> [DEBUG] Unable to find the root directory. Create a .mvn directory in the
> root directory or add the root="true" attribute on the root project's model
> to identify it.
> Apache Maven 4.0.0-alpha-8 (a2cbf4873a99c1aca7e3908086fe53b17865f07a)
> Maven home: /Users/khm/tools/maven
> Java version: 22-ea, vendor: Oracle Corporation, runtime:
> /Users/khm/.sdkman/candidates/java/22.ea.20-open
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "aarch64", family: "mac"
> {code}
> None debug output:
> {code}
> [INFO] Scanning for projects...
> [INFO]
> --
> [INFO] Reactor Build Order:
> ...
> {code}
> The question is: Should it be reported in usual output or not? Or only in
> debug mode? I would say report it not only in DEBUG mode.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MCOMPILER-549) improve recompilation cause display
[ https://issues.apache.org/jira/browse/MCOMPILER-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders resolved MCOMPILER-549. --- Resolution: Fixed Fixed in [#628c3339|https://github.com/apache/maven-compiler-plugin/commit/628c33399cdfb4ea49dba580f98ddecdffdc3d20]. > improve recompilation cause display > --- > > Key: MCOMPILER-549 > URL: https://issues.apache.org/jira/browse/MCOMPILER-549 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Maarten Mulders >Priority: Major > Fix For: 3.11.1 > > > recompilation cause message has been implemented in MCOMPILER-499 > But message format is strange and some values are not clear: see last comment > in MCOMPILER-499 and users feedback > https://lists.apache.org/thread/on96m5fkngm43tppr67hxrjmk3wy2s79 > we need to improve the message a little bit -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MASSEMBLY-990) add system requirements history
[ https://issues.apache.org/jira/browse/MASSEMBLY-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774926#comment-17774926 ] Maarten Mulders commented on MASSEMBLY-990: --- Are we sure about Apache Maven Assembly Plugin 3.4.0? According to the pull request (and the generated website), it would work on Java 7, but if I look at the POM for that version, it mentions Java 8 already... > add system requirements history > --- > > Key: MASSEMBLY-990 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-990 > Project: Maven Assembly Plugin > Issue Type: Improvement > Components: site >Affects Versions: 3.5.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MCOMPILER-549) improve recompilation cause display
[ https://issues.apache.org/jira/browse/MCOMPILER-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders reassigned MCOMPILER-549: - Assignee: Maarten Mulders > improve recompilation cause display > --- > > Key: MCOMPILER-549 > URL: https://issues.apache.org/jira/browse/MCOMPILER-549 > Project: Maven Compiler Plugin > Issue Type: Improvement >Affects Versions: 3.11.0 >Reporter: Herve Boutemy >Assignee: Maarten Mulders >Priority: Major > Fix For: 3.11.1 > > > recompilation cause message has been implemented in MCOMPILER-499 > But message format is strange and some values are not clear: see last comment > in MCOMPILER-499 and users feedback > https://lists.apache.org/thread/on96m5fkngm43tppr67hxrjmk3wy2s79 > we need to improve the message a little bit -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6869) New flag to verify the status
[
https://issues.apache.org/jira/browse/MNG-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731488#comment-17731488
]
Maarten Mulders commented on MNG-6869:
--
Let's try to wrap up this topic and see if we can find some consensus moving
forward.
As far as I'm concerned:
* This is a helpful feature, as it supports people who want to troubleshoot
why "Maven doesn't work".
* It does not cover all possible cases, and I think that's perfectly fine. It
doesn't have to. It should detect a few common causes for problems that people
encounter with Maven.
* The code has been reviewed and all objections on code level have been
addressed and fixed.
* The functionality cannot be part of a plugin. If it were, users whould have
to download it, but they are having problems with Maven so they can't rely on
that.
* The functionality cannot be an extension. If it were, we cannot assign a CLI
flag ({{--status}}) to something that may or may not be present in the Maven
installation.
So my vote would be to embrace it, and if we find false positives in the
outcomes we could fix them.
WDYT?
> New flag to verify the status
> -
>
> Key: MNG-6869
> URL: https://issues.apache.org/jira/browse/MNG-6869
> Project: Maven
> Issue Type: New Feature
>Reporter: Robert Scholte
>Assignee: Maarten Mulders
>Priority: Major
>
> While working on INFRA-19861 we had issues with invalid changes in the
> settings.xml.
> This was detected too late. After installation {{mvn --version}} is called,
> but it will only show the version of Maven.
> It would be better to have a flag that verifies it a bit more:
> - can Maven read/write to the local repository
> - can Maven access all predefined repositories? (does the proxy work?)
> This gives a much better feedback if Maven can do its job.
> Current workaround: call something like {{mvn help:evaluate
> -Dexpression=settings.localRepository -q -DforceStdout}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7805) The modelVersion should be inferred from the namespace used
[ https://issues.apache.org/jira/browse/MNG-7805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729248#comment-17729248 ] Maarten Mulders commented on MNG-7805: -- Seems like an excellent use case for a POM transformations a.k.a. Build/Consumer POM decoupling. > The modelVersion should be inferred from the namespace used > --- > > Key: MNG-7805 > URL: https://issues.apache.org/jira/browse/MNG-7805 > Project: Maven > Issue Type: Improvement >Reporter: Guillaume Nodet >Priority: Major > > The model reader currently completely ignores the namespace, but it should be > quite easy to get it and, if the modelVersion is not set, derive it from the > namespace. > This would make modelVersion effectively optional. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6934) Suggest plugin upgrade in case of failure
[
https://issues.apache.org/jira/browse/MNG-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17721301#comment-17721301
]
Maarten Mulders commented on MNG-6934:
--
{quote}This is -1 from me: Maven in case of failure to go remote and look for
new plugin version?
{quote}
Yes, in case of _plugin_ failure, Maven would go remote and look for a new
plugin version - exactly as the original ticket description says:
{quote}Maven should look if there is a more recent version. [...] Make use of
the metadata to get the most recent version.
{quote}
[~cstamas], care to elaborate *why* you vote -1 on this idea?
> Suggest plugin upgrade in case of failure
> -
>
> Key: MNG-6934
> URL: https://issues.apache.org/jira/browse/MNG-6934
> Project: Maven
> Issue Type: Improvement
>Reporter: Robert Scholte
>Priority: Major
>
> In case a plugin fails, Maven should look if there is a more recent version.
> It is considered the best practice to verify the most recent version first
> before issueing a but, as it might already be solved.
> The be clear: if the most recent plugin is used, this message should not be
> shown.
> Make use of the metadata to get the most recent version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7444) Multiple optional non-existing projects not logged correctly
[
https://issues.apache.org/jira/browse/MNG-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders closed MNG-7444.
Fix Version/s: 4.0.0-alpha-6
Resolution: Fixed
> Multiple optional non-existing projects not logged correctly
>
>
> Key: MNG-7444
> URL: https://issues.apache.org/jira/browse/MNG-7444
> Project: Maven
> Issue Type: Bug
> Components: Reactor and Workspace
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (31193cbf0c93205a63c8c7b372b09200f60e69f4)
>Reporter: Maarten Mulders
>Priority: Trivial
> Labels: up-for-grabs
> Fix For: 4.0.0-alpha-6
>
> Attachments: image-2023-04-26-00-48-51-379.png
>
>
> Run {{mvn -pl \?:a,\?:b validate}} (escaping necessary on POSIX compliant
> shells, Windows doesn't need it) on a project that does not have a module
> {{:a}} and {{:b}}.
> Expected:
> {code}
> [INFO] Could not find the selected project(s) in the reactor: :a, :b
> {code}
> Actual:
> {code}
> [INFO] Could not find the selected project in the reactor: :a
> {code}
> The output of {{mvn -help}} with regards to {{-pl}}:
> {quote}Comma-delimited list of specified reactor projects to build instead of
> all projects. A project can be specified by [groupId]:artifactId or by its
> relative path. Prefixing a project with ! excludes it, and ? marks it as
> optional{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7444) Multiple optional non-existing projects not logged correctly
[
https://issues.apache.org/jira/browse/MNG-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17716380#comment-17716380
]
Maarten Mulders commented on MNG-7444:
--
[~crazyhzm] thanks for letting me know! Indeed, both issues seem to have been
resolved.
> Multiple optional non-existing projects not logged correctly
>
>
> Key: MNG-7444
> URL: https://issues.apache.org/jira/browse/MNG-7444
> Project: Maven
> Issue Type: Bug
> Components: Reactor and Workspace
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (31193cbf0c93205a63c8c7b372b09200f60e69f4)
>Reporter: Maarten Mulders
>Priority: Trivial
> Labels: up-for-grabs
> Attachments: image-2023-04-26-00-48-51-379.png
>
>
> Run {{mvn -pl \?:a,\?:b validate}} (escaping necessary on POSIX compliant
> shells, Windows doesn't need it) on a project that does not have a module
> {{:a}} and {{:b}}.
> Expected:
> {code}
> [INFO] Could not find the selected project(s) in the reactor: :a, :b
> {code}
> Actual:
> {code}
> [INFO] Could not find the selected project in the reactor: :a
> {code}
> The output of {{mvn -help}} with regards to {{-pl}}:
> {quote}Comma-delimited list of specified reactor projects to build instead of
> all projects. A project can be specified by [groupId]:artifactId or by its
> relative path. Prefixing a project with ! excludes it, and ? marks it as
> optional{quote}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7740) Target directory is flooded with consumer*pom files
[
https://issues.apache.org/jira/browse/MNG-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711845#comment-17711845
]
Maarten Mulders commented on MNG-7740:
--
{quote}Fixed by PR in MNG-7707?{quote}
Not sure, I'll have to check...
> Target directory is flooded with consumer*pom files
> ---
>
> Key: MNG-7740
> URL: https://issues.apache.org/jira/browse/MNG-7740
> Project: Maven
> Issue Type: Improvement
> Components: build/consumer, Core
>Affects Versions: 4.0.0-alpha-4
> Environment: Apache Maven 4.0.0-alpha-4
> (009cf4a7213aead8a7946a2397e2396c5927f30f)
> Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4
> Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_NL, platform encoding: UTF-8
> OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac"
>Reporter: Maarten Mulders
>Priority: Minor
> Labels: up-for-grabs
>
> After invoking Mavens {{validate}} or later lifecycle phase, there is a
> *consumerXXXpom* file left in the build directory. Here, XXX is a bunch of
> numbers.
> It is not harmful, but I dislike the fact that for every invocation of Maven,
> the file gets generated again and again. This can quickly lead to tens of
> files that are never used again anymore. I feel we should clean those files
> when we're done using them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7762) Show version and continue build
[
https://issues.apache.org/jira/browse/MNG-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711398#comment-17711398
]
Maarten Mulders edited comment on MNG-7762 at 4/12/23 1:53 PM:
---
You can achieve this with {{mvn -V verify}} (note the uppercase {{V}} rather
than the lowercase {{v}}). Does that address your use case?
was (Author: mthmulders):
You can achieve this with {{mvn -V verify}}. Does that address your use case?
> Show version and continue build
> ---
>
> Key: MNG-7762
> URL: https://issues.apache.org/jira/browse/MNG-7762
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-5
>Reporter: Delany
>Priority: Minor
>
> When Maven is called with '--version' the build stops. But sometimes its
> useful to have the version info displayed as part of the build output.
> I propose that when a goal is specified on the command line only (and not via
> defaultGoal) and the --version switch is used, the build should continue,
> e.g. `mvn --version clean install`
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7762) Show version and continue build
[
https://issues.apache.org/jira/browse/MNG-7762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711398#comment-17711398
]
Maarten Mulders commented on MNG-7762:
--
You can achieve this with {{mvn -V verify}}. Does that address your use case?
> Show version and continue build
> ---
>
> Key: MNG-7762
> URL: https://issues.apache.org/jira/browse/MNG-7762
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-5
>Reporter: Delany
>Priority: Minor
>
> When Maven is called with '--version' the build stops. But sometimes its
> useful to have the version info displayed as part of the build output.
> I propose that when a goal is specified on the command line only (and not via
> defaultGoal) and the --version switch is used, the build should continue,
> e.g. `mvn --version clean install`
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7740) Target directory is flooded with consumer*pom files
Maarten Mulders created MNG-7740:
Summary: Target directory is flooded with consumer*pom files
Key: MNG-7740
URL: https://issues.apache.org/jira/browse/MNG-7740
Project: Maven
Issue Type: Improvement
Components: build/consumer, Core
Affects Versions: 4.0.0-alpha-4
Environment: Apache Maven 4.0.0-alpha-4
(009cf4a7213aead8a7946a2397e2396c5927f30f)
Maven home: /Users/maarten/Tools/apache-maven-4.0.0-alpha-4
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_NL, platform encoding: UTF-8
OS name: "mac os x", version: "13.2.1", arch: "aarch64", family: "mac"
Reporter: Maarten Mulders
After invoking Mavens {{validate}} or later lifecycle phase, there is a
*consumerXXXpom* file left in the build directory. Here, XXX is a bunch of
numbers.
It is not harmful, but I dislike the fact that for every invocation of Maven,
the file gets generated again and again. This can quickly lead to tens of files
that are never used again anymore. I feel we should clean those files when
we're done using them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7646) Do not parse all projects in the reactor when building a subtree
[ https://issues.apache.org/jira/browse/MNG-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650822#comment-17650822 ] Maarten Mulders commented on MNG-7646: -- I am still very much in doubt about this topic. >From a user point-of-view, I would expect Maven to "understand" that the >subtree is part of a bigger project, and be able to at least resolve >dependencies that live inside the same project tree. The idea to resolve that >over a project-local repository (MNG-7629) sounds promising, but will that >still work if Maven only parses a selection of the root project? > Do not parse all projects in the reactor when building a subtree > > > Key: MNG-7646 > URL: https://issues.apache.org/jira/browse/MNG-7646 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-3 >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7646) Do not parse all projects in the reactor when building a subtree
[ https://issues.apache.org/jira/browse/MNG-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MNG-7646: - Summary: Do not parse all projects in the reactor when building a subtree (was: Do not parse all projects in the reactor) > Do not parse all projects in the reactor when building a subtree > > > Key: MNG-7646 > URL: https://issues.apache.org/jira/browse/MNG-7646 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-3 >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7629) Revert MNG-6118
[ https://issues.apache.org/jira/browse/MNG-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647546#comment-17647546 ] Maarten Mulders commented on MNG-7629: -- I don't like the idea of "reverting" things that obviously provide value by solving a particular user problem. If there are issues with the implementation of that issue, let's find, discuss and fix those issues. But reverting a solution without a plan of properly addressing the issue would generally get a -1 from my side: it swaps one problem for the other. Could we rephrase this issue, for example like "Improve resolution of modules within a multi-module build"? > Revert MNG-6118 > --- > > Key: MNG-7629 > URL: https://issues.apache.org/jira/browse/MNG-7629 > Project: Maven > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-4 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7604) Removal of pom.* interpolation makes some older plugins defunct
[
https://issues.apache.org/jira/browse/MNG-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642348#comment-17642348
]
Maarten Mulders commented on MNG-7604:
--
{quote}IMHO: rollback the change from master and we need alt fix for it, as
making Maven 4 unable to resolve transitive deps using pom.* placeholder
introduces a huge toll.
{quote}
Agreed it's a huge toll. I don't think we should be rolling back changes. I
would prefer to seek for a solution and implement it. Rolling back is bound to
give us a false feeling of "we're done", with the result of drag around the
{{pom.*}} placeholders for the whole Maven 4 lifecycle.
> Removal of pom.* interpolation makes some older plugins defunct
> ---
>
> Key: MNG-7604
> URL: https://issues.apache.org/jira/browse/MNG-7604
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 4.0.0-alpha-2
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-3
>
>
> The MNG-7244 removed completely the {{pom.*}} prefix interpolation, but IMHO
> intent was to do it for "currently built projects". The problem is that same
> interpolator is used in model builder to build transitive dependency models,
> and with the change Maven 4 lost it's ability to resolve artifacts like
> wagon-http 1.0-beta-6 (used by things like surefire 2.22.2 and so on).
> The implication is that Maven4 CANNOT resolve wagon-http 1.0-beta-6 (and
> implicitly surefire plugin 2.22.2 is defunct it seems as it uses it). Given
> we have NO 3.x release of surefire (just M releases), I bet many of users out
> there still use 2.22.2. Also, we have no idea how many other (used as
> transitive dependencies) artifact exists out there doing same/similar thing
> that wagon POM does.
> IMHO: rollback the change from master and we need alt fix for it, as making
> Maven 4 unable to resolve transitive deps using pom.* placeholder introduces
> a huge toll.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7244) Remove deprecated WARNING for usage of pom.X placeholders
[
https://issues.apache.org/jira/browse/MNG-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642347#comment-17642347
]
Maarten Mulders commented on MNG-7244:
--
{quote}[~cstamas], support it forever?
{quote}
Let's move that discussion to
[MNG-7604|https://issues.apache.org/jira/browse/MNG-7244], as this ticket is
already closed.
> Remove deprecated WARNING for usage of pom.X placeholders
> -
>
> Key: MNG-7244
> URL: https://issues.apache.org/jira/browse/MNG-7244
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.0-alpha-1
>Reporter: Karl Heinz Marbaise
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 4.0.0-alpha-2, 4.0.0
>
>
> Currently, we produce a {{WARNING}} in case of using {{pom.version}} or alike.
> We've been doing that for years so people have had enough time to update
> their projects. We can now remove the support and the accompanying warning,
> resorting to the default behaviour of not resolving the expression at all.
> {code}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for 'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
> [WARNING] The expression ${pom.version} is deprecated. Please use
> ${project.version} instead.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7604) Removal of pom.* interpolation makes some older plugins defunct
[
https://issues.apache.org/jira/browse/MNG-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7604:
-
Summary: Removal of pom.* interpolation makes some older plugins defunct
(was: The MNG-7244 makes some older plugins defunct)
> Removal of pom.* interpolation makes some older plugins defunct
> ---
>
> Key: MNG-7604
> URL: https://issues.apache.org/jira/browse/MNG-7604
> Project: Maven
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 4.0.0-alpha-2
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-3
>
>
> The MNG-7244 removed completely the {{pom.*}} prefix interpolation, but IMHO
> intent was to do it for "currently built projects". The problem is that same
> interpolator is used in model builder to build transitive dependency models,
> and with the change Maven 4 lost it's ability to resolve artifacts like
> wagon-http 1.0-beta-6 (used by things like surefire 2.22.2 and so on).
> The implication is that Maven4 CANNOT resolve wagon-http 1.0-beta-6 (and
> implicitly surefire plugin 2.22.2 is defunct it seems as it uses it). Given
> we have NO 3.x release of surefire (just M releases), I bet many of users out
> there still use 2.22.2. Also, we have no idea how many other (used as
> transitive dependencies) artifact exists out there doing same/similar thing
> that wagon POM does.
> IMHO: rollback the change from master and we need alt fix for it, as making
> Maven 4 unable to resolve transitive deps using pom.* placeholder introduces
> a huge toll.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7564) Potential NPE in MavenMetadataSource
[
https://issues.apache.org/jira/browse/MNG-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7564:
-
Fix Version/s: 3.9.0-candidate
> Potential NPE in MavenMetadataSource
>
>
> Key: MNG-7564
> URL: https://issues.apache.org/jira/browse/MNG-7564
> Project: Maven
> Issue Type: Bug
>Reporter: Michael Osipov
>Assignee: Maarten Mulders
>Priority: Major
> Labels: up-for-grabs
> Fix For: 3.9.0-candidate, 4.0.0, 4.0.0-alpha-3
>
>
> In here:
> https://github.com/apache/maven/blob/cb54aa429d9e63bf78c4c808898fbef1cc01ff33/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L198-L203
> {{LegacySupport#getSession()}} can be {{null}}, but never tested. If {{null}}
> an empty list should be returned.
> This was indirectly found by [~gnodet].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7564) Potential NPE in MavenMetadataSource
[
https://issues.apache.org/jira/browse/MNG-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626462#comment-17626462
]
Maarten Mulders commented on MNG-7564:
--
{quote}This likely also applies to 3.9.0.{quote}
Looking at the code, I think it's quite likely this issue also can occur in
3.9.x. The same call to {{LegacySupport#getSession()}} is there, too.
> Potential NPE in MavenMetadataSource
>
>
> Key: MNG-7564
> URL: https://issues.apache.org/jira/browse/MNG-7564
> Project: Maven
> Issue Type: Bug
>Reporter: Michael Osipov
>Assignee: Maarten Mulders
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.0, 4.0.0-alpha-3
>
>
> In here:
> https://github.com/apache/maven/blob/cb54aa429d9e63bf78c4c808898fbef1cc01ff33/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L198-L203
> {{LegacySupport#getSession()}} can be {{null}}, but never tested. If {{null}}
> an empty list should be returned.
> This was indirectly found by [~gnodet].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7564) Potential NPE in MavenMetadataSource
[
https://issues.apache.org/jira/browse/MNG-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626173#comment-17626173
]
Maarten Mulders commented on MNG-7564:
--
{quote}Where is the fix version? This likely also applies to 3.9.0.{quote}
Excuse me, forgot to add that. I've updated the ticket. Not sure if this also
applies to 3.9.0, I'd have to check.
> Potential NPE in MavenMetadataSource
>
>
> Key: MNG-7564
> URL: https://issues.apache.org/jira/browse/MNG-7564
> Project: Maven
> Issue Type: Bug
>Reporter: Michael Osipov
>Assignee: Maarten Mulders
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.0-alpha-3
>
>
> In here:
> https://github.com/apache/maven/blob/cb54aa429d9e63bf78c4c808898fbef1cc01ff33/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L198-L203
> {{LegacySupport#getSession()}} can be {{null}}, but never tested. If {{null}}
> an empty list should be returned.
> This was indirectly found by [~gnodet].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7564) Potential NPE in MavenMetadataSource
[
https://issues.apache.org/jira/browse/MNG-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7564:
-
Fix Version/s: 4.0.0-alpha-3
> Potential NPE in MavenMetadataSource
>
>
> Key: MNG-7564
> URL: https://issues.apache.org/jira/browse/MNG-7564
> Project: Maven
> Issue Type: Bug
>Reporter: Michael Osipov
>Assignee: Maarten Mulders
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.0-alpha-3
>
>
> In here:
> https://github.com/apache/maven/blob/cb54aa429d9e63bf78c4c808898fbef1cc01ff33/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L198-L203
> {{LegacySupport#getSession()}} can be {{null}}, but never tested. If {{null}}
> an empty list should be returned.
> This was indirectly found by [~gnodet].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MNG-7564) Potential NPE in MavenMetadataSource
[
https://issues.apache.org/jira/browse/MNG-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders resolved MNG-7564.
--
Resolution: Fixed
Fixed in
[{{bc8c6be}}|https://github.com/apache/maven/commit/bc8c6be269a97126dc13005c494d883f6713d6a6].
> Potential NPE in MavenMetadataSource
>
>
> Key: MNG-7564
> URL: https://issues.apache.org/jira/browse/MNG-7564
> Project: Maven
> Issue Type: Bug
>Reporter: Michael Osipov
>Assignee: Maarten Mulders
>Priority: Major
> Labels: up-for-grabs
>
> In here:
> https://github.com/apache/maven/blob/cb54aa429d9e63bf78c4c808898fbef1cc01ff33/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L198-L203
> {{LegacySupport#getSession()}} can be {{null}}, but never tested. If {{null}}
> an empty list should be returned.
> This was indirectly found by [~gnodet].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-6869) New flag to verify the status
[
https://issues.apache.org/jira/browse/MNG-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MNG-6869:
Assignee: Maarten Mulders
> New flag to verify the status
> -
>
> Key: MNG-6869
> URL: https://issues.apache.org/jira/browse/MNG-6869
> Project: Maven
> Issue Type: New Feature
>Reporter: Robert Scholte
>Assignee: Maarten Mulders
>Priority: Major
>
> While working on INFRA-19861 we had issues with invalid changes in the
> settings.xml.
> This was detected too late. After installation {{mvn --version}} is called,
> but it will only show the version of Maven.
> It would be better to have a flag that verifies it a bit more:
> - can Maven read/write to the local repository
> - can Maven access all predefined repositories? (does the proxy work?)
> This gives a much better feedback if Maven can do its job.
> Current workaround: call something like {{mvn help:evaluate
> -Dexpression=settings.localRepository -q -DforceStdout}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6869) New flag to verify the status
[
https://issues.apache.org/jira/browse/MNG-6869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626032#comment-17626032
]
Maarten Mulders commented on MNG-6869:
--
[~Giovds] is working on it, but I can't assign him.
> New flag to verify the status
> -
>
> Key: MNG-6869
> URL: https://issues.apache.org/jira/browse/MNG-6869
> Project: Maven
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
>
> While working on INFRA-19861 we had issues with invalid changes in the
> settings.xml.
> This was detected too late. After installation {{mvn --version}} is called,
> but it will only show the version of Maven.
> It would be better to have a flag that verifies it a bit more:
> - can Maven read/write to the local repository
> - can Maven access all predefined repositories? (does the proxy work?)
> This gives a much better feedback if Maven can do its job.
> Current workaround: call something like {{mvn help:evaluate
> -Dexpression=settings.localRepository -q -DforceStdout}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7578) Building Linux image on Windows impossible (patch incuded)
[
https://issues.apache.org/jira/browse/MNG-7578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MNG-7578:
Assignee: Maarten Mulders
> Building Linux image on Windows impossible (patch incuded)
> --
>
> Key: MNG-7578
> URL: https://issues.apache.org/jira/browse/MNG-7578
> Project: Maven
> Issue Type: Bug
> Components: Core, Toolchains
>Affects Versions: 3.8.6
>Reporter: Eugen Labun
>Assignee: Maarten Mulders
>Priority: Major
>
> If you try to find `javac` in a Linux JDK using `Toolchain.findTool()`
> method, this will fail when the build is running on Windows, since the
> implementation
> [JavaToolchainImpl#findTool()|https://github.com/apache/maven/blob/maven-3.8.6/maven-core/src/main/java/org/apache/maven/toolchain/java/JavaToolchainImpl.java#L74-L86]
> appends ".exe" to the toolName (causing `javac.exe` is not found):
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" ); //NOI18N
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName + ( Os.isFamily( "windows" )
> ? ".exe" : "" ) ); // NOI18N
> if ( tool.exists() )
> {
> return tool;
> }
> }
> return null;
>}
> {code}
> The current workaround is to manually add a fake `javac.exe` file to the JDK
> `bin` directory. See [tool chain issue (building linux image on windows
> machine)|https://github.com/moditect/moditect/issues/107] in moditect project.
> The `findTool` method could yet easily be changed to search for exact
> `toolName` as requested, with a fallback to `toolName.exe` for backward
> compatibility:
> {code:java}
> private static File findTool( String toolName, File installFolder )
> {
> File bin = new File( installFolder, "bin" );
> if ( bin.exists() )
> {
> File tool = new File( bin, toolName );
> if ( tool.exists() )
> {
> return tool;
> }
> File toolExe = new File( bin, toolName + ".exe" );
> if ( toolExe.exists() )
> {
> return toolExe;
> }
> }
> return null;
>}
> {code}
> This would solve the problem.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MPH-168) effective pom should support multi-module project
[
https://issues.apache.org/jira/browse/MPH-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MPH-168:
---
Assignee: Maarten Mulders
> effective pom should support multi-module project
> -
>
> Key: MPH-168
> URL: https://issues.apache.org/jira/browse/MPH-168
> Project: Maven Help Plugin
> Issue Type: Improvement
> Components: effective-pom
>Affects Versions: 3.2.0
>Reporter: Or Shachar
>Assignee: Maarten Mulders
>Priority: Major
>
> I need to get effective pom of all modules in my multi-module project. Today
> this requires me to discover all modules manually and run effective pom on
> each of them.
> For multi-module projects it would be great if I can run effective pom from
> top level and get an effective pom written to
> `${project.build.directory}/effective-pom.xml` of each module.
> Since effective-pom does not write to file by default maybe a reasonable
> usage would be to run:
> {code:java}
> mvn help:effective-pom -Doutput=target/effective.pom.xml{code}
>
> Maybe helpful: mvn dependency plugin lets you do it (with goals "list" or
> "collect").
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MNG-7378) neither the Core IT link in PR template nor contributor's guide tells new contributors how to run Core IT
[
https://issues.apache.org/jira/browse/MNG-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders resolved MNG-7378.
--
Resolution: Fixed
Fixed in
{{[0ffe25b|https://github.com/apache/maven-integration-testing/commit/0ffe25b7cc415ae79a7bd6a0946791bf96752c3b]}}.
> neither the Core IT link in PR template nor contributor's guide tells new
> contributors how to run Core IT
> -
>
> Key: MNG-7378
> URL: https://issues.apache.org/jira/browse/MNG-7378
> Project: Maven
> Issue Type: Bug
>Reporter: Jeff Hodges
>Assignee: Maarten Mulders
>Priority: Major
>
> There's a checkbox in the new pull request template for the maven repo that
> says the contributor should run the Core ITs.
> However, the page it links to doesn't say where to find them and the obvious
> thing to do (running `mvn clean test -Prun-its` in the maven repo proper)
> doesn't work because there's no `run-its` profile.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SUREFIRE-2122) Document how to develop on Surefire using IntelliJ
[
https://issues.apache.org/jira/browse/SUREFIRE-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders resolved SUREFIRE-2122.
---
Fix Version/s: 3.0.0-M8
Resolution: Fixed
Fixed in
{{[f6bc398|https://github.com/apache/maven-surefire/commit/f6bc398c4d5bc352967434ec6d0e7facccec7afe]}}.
> Document how to develop on Surefire using IntelliJ
> --
>
> Key: SUREFIRE-2122
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2122
> Project: Maven Surefire
> Issue Type: Task
> Components: documentation
>Reporter: Maarten Mulders
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 3.0.0-M8
>
>
> The README mentions how to contribute if you are using Eclipse IDE.
> It would be useful to new contributors to also know how to setup IntelliJ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7542) Wrong Information - multi-module project
[
https://issues.apache.org/jira/browse/MNG-7542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MNG-7542:
Assignee: Maarten Mulders
> Wrong Information - multi-module project
>
>
> Key: MNG-7542
> URL: https://issues.apache.org/jira/browse/MNG-7542
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-1
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (1ca65c79fa4e25c4b7da027c8f8eef1b95ceced4)
> Maven home: /Users/khm/tools/maven
> Java version: 17.0.4, vendor: Eclipse Adoptium, runtime:
> /Users/khm/.sdkman/candidates/java/17.0.4-tem
> Default locale: en_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "12.4", arch: "aarch64", family: "mac"
>Reporter: Karl Heinz Marbaise
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 4.0.0
>
>
> I have simple [single module spring boot project for testing
> purposes|https://github.com/khmarbaise/m4/tree/main/spring-boot-plus-spring-data]
> which produces during the build the following information at the beginning
> of the build:
> {code}
> [INFO] Scanning for projects...
> [INFO] Maven detected that the requested POM file is part of a multi-module
> project, but could not find a pom.xml file in the multi-module root directory
> '/Users/khm/ws-git-soebes'.
> [INFO] The reactor is limited to all projects under:
> /Users/khm/ws-git-soebes/examples/spring-boot-plus-spring-data
> [INFO]
> {code}
> If I put the same project into a different directory:
> {{/Users/khm/ws-git-bugs-maven/m4/spring-boot-plus-spring-data}} it does
> **NOT** produce the output.
> I have defined in the pom file the parent exactly like this:
> {code:xml}
>
> 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
> https://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
>
> org.springframework.boot
> spring-boot-starter-parent
> 3.0.0-M4
>
>
> com.soebes.spring.example
> employee
> 0.0.1-SNAPSHOT
> {code}
> Based on the configuration via {{}} it should never try to
> find a parent project...which means this is simple separated single module
> project... Unfortunately the given output is misleading here...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2122) Document how to develop on Surefire using IntelliJ
[ https://issues.apache.org/jira/browse/SUREFIRE-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625559#comment-17625559 ] Maarten Mulders commented on SUREFIRE-2122: --- The IntelliJ issue tracker mentions [a workaround|https://youtrack.jetbrains.com/issue/IDEA-126596]. > Document how to develop on Surefire using IntelliJ > -- > > Key: SUREFIRE-2122 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2122 > Project: Maven Surefire > Issue Type: Task > Components: documentation >Reporter: Maarten Mulders >Assignee: Maarten Mulders >Priority: Minor > > The README mentions how to contribute if you are using Eclipse IDE. > It would be useful to new contributors to also know how to setup IntelliJ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SUREFIRE-2122) Document how to develop on Surefire using IntelliJ
Maarten Mulders created SUREFIRE-2122: - Summary: Document how to develop on Surefire using IntelliJ Key: SUREFIRE-2122 URL: https://issues.apache.org/jira/browse/SUREFIRE-2122 Project: Maven Surefire Issue Type: Task Components: documentation Reporter: Maarten Mulders Assignee: Maarten Mulders The README mentions how to contribute if you are using Eclipse IDE. It would be useful to new contributors to also know how to setup IntelliJ. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7378) neither the Core IT link in PR template nor contributor's guide tells new contributors how to run Core IT
[ https://issues.apache.org/jira/browse/MNG-7378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders reassigned MNG-7378: Assignee: Maarten Mulders > neither the Core IT link in PR template nor contributor's guide tells new > contributors how to run Core IT > - > > Key: MNG-7378 > URL: https://issues.apache.org/jira/browse/MNG-7378 > Project: Maven > Issue Type: Bug >Reporter: Jeff Hodges >Assignee: Maarten Mulders >Priority: Major > > There's a checkbox in the new pull request template for the maven repo that > says the contributor should run the Core ITs. > However, the page it links to doesn't say where to find them and the obvious > thing to do (running `mvn clean test -Prun-its` in the maven repo proper) > doesn't work because there's no `run-its` profile. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SUREFIRE-1887) Test Failures should not dump stack.
[ https://issues.apache.org/jira/browse/SUREFIRE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders reassigned SUREFIRE-1887: - Assignee: Maarten Mulders > Test Failures should not dump stack. > - > > Key: SUREFIRE-1887 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1887 > Project: Maven Surefire > Issue Type: Bug >Reporter: Elliotte Rusty Harold >Assignee: Maarten Mulders >Priority: Major > > Typical failing test output from the Maven surefire plugin dumps a lot of > internal state. This is incorrect. > > The purpose of the surefire plugin is to run the user's tests. These tests > are expected to fail much of the time. This a normal state. The test failure > should be reported, but this is in no way a failure of surefire itself. There > is no reason surefire should print its own stack. Indeed, this simply > obscures the real failure in the user's own code. > > ``` > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test > (default-test) on project dependencies: There are test failures. > Please refer to > /home/runner/work/cloud-opensource-java/cloud-opensource-java/dependencies/target/surefire-reports > for the individual test results. > Please refer to dump files (if any exist) [date].dump, [date]-jvmRun[N].dump > and [date].dumpstream. > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:215) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:156) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute > (MojoExecutor.java:148) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:117) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject > (LifecycleModuleBuilder.java:81) > at > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build > (SingleThreadedBuilder.java:56) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute > (LifecycleStarter.java:128) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305) > at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192) > at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105) > at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956) > at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288) > at org.apache.maven.cli.MavenCli.main (MavenCli.java:192) > 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:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch > (Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode > (Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356) > 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.apache.maven.wrapper.BootstrapMainStarter.start > (BootstrapMainStarter.java:39) > at org.apache.maven.wrapper.WrapperExecutor.execute > (WrapperExecutor.java:122) > at org.apache.maven.wrapper.MavenWrapperMain.main (MavenWrapperMain.java:61) > Caused by: org.apache.maven.plugin.MojoFailureException: There are test > failures. > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SUREFIRE-1654) Remove deprecated parameter 'forkMode' and use only 'forkCount'
[ https://issues.apache.org/jira/browse/SUREFIRE-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders reassigned SUREFIRE-1654: - Assignee: Maarten Mulders > Remove deprecated parameter 'forkMode' and use only 'forkCount' > --- > > Key: SUREFIRE-1654 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1654 > Project: Maven Surefire > Issue Type: Dependency upgrade > Components: Maven Failsafe Plugin, Maven Surefire Plugin, process > forking >Reporter: Tibor Digana >Assignee: Maarten Mulders >Priority: Major > Fix For: 3.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-7564) Potential NPE in MavenMetadataSource
[
https://issues.apache.org/jira/browse/MNG-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MNG-7564:
Assignee: Maarten Mulders
> Potential NPE in MavenMetadataSource
>
>
> Key: MNG-7564
> URL: https://issues.apache.org/jira/browse/MNG-7564
> Project: Maven
> Issue Type: Bug
>Reporter: Michael Osipov
>Assignee: Maarten Mulders
>Priority: Major
> Labels: up-for-grabs
>
> In here:
> https://github.com/apache/maven/blob/cb54aa429d9e63bf78c4c808898fbef1cc01ff33/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L198-L203
> {{LegacySupport#getSession()}} can be {{null}}, but never tested. If {{null}}
> an empty list should be returned.
> This was indirectly found by [~gnodet].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7564) Potential NPE in MavenMetadataSource
[
https://issues.apache.org/jira/browse/MNG-7564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7564:
-
Labels: up-for-grabs (was: )
> Potential NPE in MavenMetadataSource
>
>
> Key: MNG-7564
> URL: https://issues.apache.org/jira/browse/MNG-7564
> Project: Maven
> Issue Type: Bug
>Reporter: Michael Osipov
>Priority: Major
> Labels: up-for-grabs
>
> In here:
> https://github.com/apache/maven/blob/cb54aa429d9e63bf78c4c808898fbef1cc01ff33/maven-core/src/main/java/org/apache/maven/project/artifact/MavenMetadataSource.java#L198-L203
> {{LegacySupport#getSession()}} can be {{null}}, but never tested. If {{null}}
> an empty list should be returned.
> This was indirectly found by [~gnodet].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7534) Maven fails without providing any meaningful error message with actionable details
[ https://issues.apache.org/jira/browse/MNG-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MNG-7534: - Labels: waiting-for-feedback (was: ) > Maven fails without providing any meaningful error message with actionable > details > -- > > Key: MNG-7534 > URL: https://issues.apache.org/jira/browse/MNG-7534 > Project: Maven > Issue Type: Bug > Components: Core >Affects Versions: 3.8.6 >Reporter: Yuri >Priority: Major > Labels: waiting-for-feedback > > Maven fails on the K project with the error message only saying that "exec > returned: 1" with no other details about the failure. > > See details > [here|https://github.com/runtimeverification/k/issues/2835#issuecomment-1231227100]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7534) Maven fails without providing any meaningful error message with actionable details
[
https://issues.apache.org/jira/browse/MNG-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17598203#comment-17598203
]
Maarten Mulders commented on MNG-7534:
--
I believe this should be logged against the Maven Antrun Plugin (MANTRUN) - but
I can't move this issue there.
However, the linked GitHub issue shows more details from the log:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.7:run (build-haskell) on project
haskell-backend: An Ant BuildException has occured: exec returned: 1
[ERROR] around Ant part .. @ 5:151 in
/disk-samsung/freebsd-ports/lang/k/work/k-5.3.178/haskell-backend/target/antrun/build-main.xml
{code}
In short: Maven invokes an Ant script, which fails around an {{}}
statement.
>From my limited knowledge of the K project, I would say this is not a bug in
>Maven or the Maven Antrun Plugin, but more likely to be a problem with the
>work that's done _from_ that Ant script.
> Maven fails without providing any meaningful error message with actionable
> details
> --
>
> Key: MNG-7534
> URL: https://issues.apache.org/jira/browse/MNG-7534
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.6
>Reporter: Yuri
>Priority: Major
>
> Maven fails on the K project with the error message only saying that "exec
> returned: 1" with no other details about the failure.
>
> See details
> [here|https://github.com/runtimeverification/k/issues/2835#issuecomment-1231227100].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7527) Resolving inter-module dependencies does not work like expected
[
https://issues.apache.org/jira/browse/MNG-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17584340#comment-17584340
]
Maarten Mulders commented on MNG-7527:
--
I believe it should even work with an initial {{mvn compile}} (rather than
{{mvn package}}. If the modules actually do contain code, a {{target/classes/}}
folder will get generated and Maven will pick that one up when compiling
{{dep1}} or {{dep2}}. This works as expected, as far as I can tell.
When there's no code (as in your example), you indeed need {{mvn package}} for
a {{target/}} folder to be generated. But a module without code would usually
have type {{pom}}. Out of curiosity, what is your use case for "empty" modules
as a dependency?
> Resolving inter-module dependencies does not work like expected
> ---
>
> Key: MNG-7527
> URL: https://issues.apache.org/jira/browse/MNG-7527
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-1
>Reporter: Andrey Panfilov
>Assignee: Maarten Mulders
>Priority: Major
> Attachments: MNG-7527.zip
>
>
> After resolving MNG-4660 ReactorReader picks up packaged main artifact only
> and ignores supplemental artifacts:
>
>
> {code:java}
> private Artifact findMatchingArtifact( MavenProject project, Artifact
> requestedArtifact )
> {
> String requestedRepositoryConflictId = ArtifactIdUtils.toVersionlessId(
> requestedArtifact );
> Artifact mainArtifact = RepositoryUtils.toArtifact( project.getArtifact()
> );
> if ( requestedRepositoryConflictId.equals(
> ArtifactIdUtils.toVersionlessId( mainArtifact ) ) )
> {
> return mainArtifact;
> }
>
> /*
> * if module is not a part of "build reactor",
> project.getAttachedArtifacts() always
> * returns empty list, it seems that it is plugins' responsibility to
> populate attached artifacts
> * however it seems no corresponding API has been introduced, which would
> allow to gather information
> * about supplemental artifacts without building module
> */
> return RepositoryUtils.toArtifacts( project.getAttachedArtifacts()
> ).stream()
> .filter( isRequestedArtifact( requestedArtifact ) )
> .findFirst()
> .orElse( null );
> } {code}
>
>
> {code:java}
> private File determinePreviouslyPackagedArtifactFile( MavenProject project,
> Artifact artifact )
> {
> if ( artifact == null )
>
> { return null; }
> /*
> * the implementation/signature of this method looks bit confusing: it
> accepts any artifact descriptor
> * but returns main artifact only, I do believe in some cases (if
> supplemental artifact got discovered)
> * it may return wrong file
> */
> String fileName = String.format( "%s.%s",
> project.getBuild().getFinalName(), artifact.getExtension() );
> return new File( project.getBuild().getDirectory(), fileName );
> } {code}
>
> That new behaviour causes following issues:
> * if extension of main artifact differs from classifier's (e.g. war/classes)
> ReactorReader fails to pick up artifact (gh link to demo project:
> [https://github.com/andreybpanfilov/MNG-7527])
> * if extension of main artifact does not differ from classifier's
> ReactorReader picks up wrong artifact
>
> I have discovered another issue - the `mvn package clean package` command
> might look insane, however, I do believe it reveals there are some issues
> with internal state of artifacts/dependencies:
>
> {code:java}
> MNG-7527 % ~/app/maven/4.0/bin/mvn package clean package -f mng7527-dep2
> [INFO] Building jar:
> MNG-7527/mng7527-dep2/target/mng7527-dep2-0.0.1-SNAPSHOT.jar
> [INFO]
> --
> [INFO] BUILD FAILURE
> [INFO]
> --
> [INFO] Total time: 1.063 s
> [INFO] Finished at: 2022-08-08T21:05:18+10:00
> [INFO]
> --
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-jar-plugin:3.2.0:jar (default-jar) on project
> mng7527-dep2: You have to use a classifier to attach supplemental artifacts
> to the project instead of replacing them. -> [Help 1]
> [ERROR] {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-7527) Resolving inter-module dependencies does not work like expected
[
https://issues.apache.org/jira/browse/MNG-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MNG-7527:
Assignee: Maarten Mulders
> Resolving inter-module dependencies does not work like expected
> ---
>
> Key: MNG-7527
> URL: https://issues.apache.org/jira/browse/MNG-7527
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-1
>Reporter: Andrey Panfilov
>Assignee: Maarten Mulders
>Priority: Major
> Attachments: MNG-7527.zip
>
>
> After resolving MNG-4660 ReactorReader
> ([https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/ReactorReader.java#L220])
> tries to pick up packaged main artifact without taking into account what
> classifier was actually requested:
>
> {code:java}
> private File determinePreviouslyPackagedArtifactFile( MavenProject project,
> Artifact artifact )
> {
> if ( artifact == null )
>
> { return null; }
> String fileName = String.format( "%s.%s",
> project.getBuild().getFinalName(), artifact.getExtension() );
> return new File( project.getBuild().getDirectory(), fileName );
> } {code}
>
> That new behaviour causes following issues:
> * if extension of main artifact differs from classifier's (e.g. war/classes)
> ReactorReader fails to pick up artifact (gh link to demo project:
> https://github.com/andreybpanfilov/MNG-7527)
> * if extension of main artifact does not differ from classifier's
> ReactorReader picks up wrong artifact
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7527) Resolving inter-module dependencies does not work like expected
[
https://issues.apache.org/jira/browse/MNG-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17576703#comment-17576703
]
Maarten Mulders commented on MNG-7527:
--
Sure thing!
> Resolving inter-module dependencies does not work like expected
> ---
>
> Key: MNG-7527
> URL: https://issues.apache.org/jira/browse/MNG-7527
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-1
>Reporter: Andrey Panfilov
>Priority: Major
> Attachments: MNG-7527.zip
>
>
> After resolving MNG-4660 ReactorReader
> ([https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/ReactorReader.java#L220])
> tries to pick up packaged main artifact without taking into account what
> classifier was actually requested:
>
> {code:java}
> private File determinePreviouslyPackagedArtifactFile( MavenProject project,
> Artifact artifact )
> {
> if ( artifact == null )
>
> { return null; }
> String fileName = String.format( "%s.%s",
> project.getBuild().getFinalName(), artifact.getExtension() );
> return new File( project.getBuild().getDirectory(), fileName );
> } {code}
>
> That new behaviour causes following issues:
> * if extension of main artifact differs from classifier's (e.g. war/classes)
> ReactorReader fails to pick up artifact (gh link to demo project:
> https://github.com/andreybpanfilov/MNG-7527)
> * if extension of main artifact does not differ from classifier's
> ReactorReader picks up wrong artifact
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPH-183) Effective-pom + verbose should show path to source
[
https://issues.apache.org/jira/browse/MPH-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17551120#comment-17551120
]
Maarten Mulders commented on MPH-183:
-
I am happy to report that I have a working proof of concept for this.
Old situation:
{code:xml}
org.example
mng-7344-dep-w
4
compile
org.example
mng-7344-dep-x
2
provided
org.example
mng-7344-dep-y
1.1
compile
org.example
mng-7344-dep-z
3
compile
{code}
Same project, new situation:
{code:xml}
org.example
mng-7344-dep-w
4
compile
org.example
mng-7344-dep-x
2
provided
org.example
mng-7344-dep-y
1.1
compile
org.example
mng-7344-dep-z
3
compile
{code}
I will soon publish a message on the mailing list to discuss if/how/when we can
incorporate this into Maven.
> Effective-pom + verbose should show path to source
> --
>
> Key: MPH-183
> URL: https://issues.apache.org/jira/browse/MPH-183
> Project: Maven Help Plugin
> Issue Type: Improvement
>Reporter: Robert Scholte
>Assignee: Maarten Mulders
>Priority: Major
> Attachments: mph-183-it.zip
>
>
> The popular spring-boot makes a lot of use of BOMs. Using BOMs is a good
> practice, but right now it is very hard to determine where dependencies and
> especially their versions are coming from.
> Instead of only showing the location, it should show the path from the
> current project to that specific pom. This way it will be easier to figure
> out which dependency needs to be upgraded.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2077) argLine with two spaces doesn't work
[
https://issues.apache.org/jira/browse/SUREFIRE-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541858#comment-17541858
]
Maarten Mulders commented on SUREFIRE-2077:
---
The PR to fix this has been open for one month now. I'd love to fix the issue
at hand since it means 3.0.0-M6 broke something that worked in 3.0.0-M5. Are
there any objections to the changes in the PR?
> argLine with two spaces doesn't work
>
>
> Key: SUREFIRE-2077
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2077
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Reporter: Maarten Mulders
>Priority: Minor
>
> Reported by [~marcphilipp]:
> The fix for SUREFIRE-2063 breaks valid but questionable use cases such as
> {code:xml}
> "-DpropertyKey=value with 2 spaces"{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MARCHETYPES-61) Update quickstart to use JUnit 5
[
https://issues.apache.org/jira/browse/MARCHETYPES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17541101#comment-17541101
]
Maarten Mulders commented on MARCHETYPES-61:
{quote} Archetype has been already updated in MARCHETYPES-70., but has not been
released yet.
{quote}
Does that mean we could close this one?
> Update quickstart to use JUnit 5
>
>
> Key: MARCHETYPES-61
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-61
> Project: Maven Archetype Bundles
> Issue Type: Improvement
> Components: Maven Quickstart Archetype
>Affects Versions: 1.3
>Reporter: Dmitry Timofeev
>Priority: Minor
>
> Update quickstart archetype to generate a project using JUnit 5, the next
> version of the most popular testing framework.
> Currently one has to include _at least_ two dependencies on JUnit 5 artefacts
> to enable surefire to run them: junit-jupiter-api and junit-jupiter-engine.
> Possible structure of dependencies:
> {code:java}
>
>
>
> org.junit
> junit-bom
> 5.3.1
> pom
> import
>
>
>
>
>
> org.junit.jupiter
> junit-jupiter-api
> test
>
>
> org.junit.jupiter
> junit-jupiter-engine
> test
>
>
>
> org.junit.jupiter
> junit-jupiter-params
> test
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MARCHETYPES-61) Update quickstart to use JUnit 5
[
https://issues.apache.org/jira/browse/MARCHETYPES-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17540782#comment-17540782
]
Maarten Mulders commented on MARCHETYPES-61:
I think with more recent versions of Surefire, the jupiter-engine doesn't have
to be a test scoped project dependency anymore. It must be a dependency of the
Surefire plugin if I recall correctly. Am I right, [~tibordigana]?
> Update quickstart to use JUnit 5
>
>
> Key: MARCHETYPES-61
> URL: https://issues.apache.org/jira/browse/MARCHETYPES-61
> Project: Maven Archetype Bundles
> Issue Type: Improvement
> Components: Maven Quickstart Archetype
>Affects Versions: 1.3
>Reporter: Dmitry Timofeev
>Priority: Minor
>
> Update quickstart archetype to generate a project using JUnit 5, the next
> version of the most popular testing framework.
> Currently one has to include _at least_ two dependencies on JUnit 5 artefacts
> to enable surefire to run them: junit-jupiter-api and junit-jupiter-engine.
> Possible structure of dependencies:
> {code:java}
>
>
>
> org.junit
> junit-bom
> 5.3.1
> pom
> import
>
>
>
>
>
> org.junit.jupiter
> junit-jupiter-api
> test
>
>
> org.junit.jupiter
> junit-jupiter-engine
> test
>
>
>
> org.junit.jupiter
> junit-jupiter-params
> test
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (MARCHETYPES-72) Include empty .mvn/jvm.config and .mvn/maven.config in all archetypes
[ https://issues.apache.org/jira/browse/MARCHETYPES-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders resolved MARCHETYPES-72. Fix Version/s: 1.5 Resolution: Fixed Resolved with [apache/maven-archetypes@d74f6b7|https://github.com/apache/maven-archetypes/commit/d74f6b790ca9be3649b8fa8d34e4b703e65f8ef8]. > Include empty .mvn/jvm.config and .mvn/maven.config in all archetypes > - > > Key: MARCHETYPES-72 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-72 > Project: Maven Archetype Bundles > Issue Type: Improvement >Reporter: Maarten Mulders >Assignee: Maarten Mulders >Priority: Minor > Labels: up-for-grabs > Fix For: 1.5 > > > All [Maven archetypes|https://maven.apache.org/archetypes/index.html] should > generate two empty files in the *.mvn* folder of the generated project: > *jvm.config* and *maven.config*. > There are two reasons for this: > # This points users to the fact that they can use those files to customise > their build. > # If the project is a multi-module project or is later converted to a > multi-module project, Maven will be able to reliably determine the root of > that multi-module project. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (MARCHETYPES-72) Include empty .mvn/jvm.config and .mvn/maven.config in all archetypes
[ https://issues.apache.org/jira/browse/MARCHETYPES-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders reassigned MARCHETYPES-72: -- Assignee: Maarten Mulders > Include empty .mvn/jvm.config and .mvn/maven.config in all archetypes > - > > Key: MARCHETYPES-72 > URL: https://issues.apache.org/jira/browse/MARCHETYPES-72 > Project: Maven Archetype Bundles > Issue Type: Improvement >Reporter: Maarten Mulders >Assignee: Maarten Mulders >Priority: Minor > Labels: up-for-grabs > > All [Maven archetypes|https://maven.apache.org/archetypes/index.html] should > generate two empty files in the *.mvn* folder of the generated project: > *jvm.config* and *maven.config*. > There are two reasons for this: > # This points users to the fact that they can use those files to customise > their build. > # If the project is a multi-module project or is later converted to a > multi-module project, Maven will be able to reliably determine the root of > that multi-module project. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MNG-7360) Can't parse project that has tag in plugin configuration
[
https://issues.apache.org/jira/browse/MNG-7360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538430#comment-17538430
]
Maarten Mulders commented on MNG-7360:
--
Unfortunately, even in the [original pull
request|https://github.com/apache/maven/pull/286] for build/consumer POM I
can't find a unit test specifically targeted at the {{FastForwardFilter}}. If I
understand you correctly [~rfscholte], you would expect the
{{FastForwardFilter}} to effectively "skip" the XML fragments that reside under
one of the 6 locations that are listed in that class.
Could it be that - due to refactoring from SaX to XML Pull Parser - the
ParentXmlFilter now "kicks in" where it previously didn't?
> Can't parse project that has tag in plugin configuration
> -
>
> Key: MNG-7360
> URL: https://issues.apache.org/jira/browse/MNG-7360
> Project: Maven
> Issue Type: Bug
> Components: build/consumer
>Affects Versions: 4.0.x-candidate
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (3a06530dbce82e2054afa3cc4c81631910474bd0)
> Maven home:
> /usr/local/Cellar/maven-snapshot/4.0.0-alpha-1-SNAPSHOT_290/libexec
> Java version: 17.0.1, vendor: Eclipse Adoptium, runtime:
> /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "mac os x", version: "11.5", arch: "x86_64", family: "mac"
>Reporter: Maarten Mulders
>Assignee: Guillaume Nodet
>Priority: Major
> Attachments: Screenshot 2021-12-13 at 13.45.01.png
>
>
> The Apache Camel project has the following snippet in their root POM:
> {code:xml}
>
> org.codehaus.mojo
> flatten-maven-plugin
> 1.2.5
>
>
> default-cli
> process-resources
>
> flatten
>
>
>
>
>
> expand
>
>
>
>
>
>
> {code}
> With Maven 4's "Build Consumer" feature enabled, parsing this plugin
> definition breaks with
> {code:none}
> [INFO] BuildTimeEventSpy is registered.
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [FATAL] Unable to transform pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project (/Users/maarten/Code/open-source/camel/pom.xml) has 1
> error
> [ERROR] Unable to transform pom: Not a regular file:
> /Users/maarten/Code/open-source/pom.xml
> [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 verbose output
> [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/ProjectBuildingException
> {code}
> I suspect that the {{}} tag is the culprit. It seems to me that it
> causes the {{ParentXMLFilter}} to think it needs to do its work. The attached
> screenshot shows the stacktrace that brought me to this idea. As the
> {{BufferingParser}} class processes its buffer of events, it encounters a
> situation of an "end {{parent}} tag". But that {{parent}} tag did not have
> child elements {{version}} and {{relativePath}} and so, it decides it needs
> to resolve the parent as {{../pom.xml}} against the project path
> ({{/Users/maarten/Code/open-source/camel/}} in my case), leading to the
> non-existing path of {{/Users/maarten/Code/open-source/pom.xml}}.
> I think the bug here is not that it resolves to a non-existing path (it's
> good to check that before actually reading the file). I think the bug is that
> the {{ParentXMLFilter}} is acting on the {{parent}} tag inside the plugin
> configuration.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (MNG-7404) Change from deprecated WARNING to FAIL the build for usage of {X} placeholders rather than ${project.X}
[
https://issues.apache.org/jira/browse/MNG-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders resolved MNG-7404.
--
Fix Version/s: 4.0.0-alpha-1
(was: 4.0.x-candidate)
Resolution: Fixed
Fixed in
{{[apache/maven@93196d4|https://github.com/apache/maven/commit/93196d4bb72d3bf434256111f294d5bd1dd09d11]}}.
> Change from deprecated WARNING to FAIL the build for usage of {X}
> placeholders rather than ${project.X}
> ---
>
> Key: MNG-7404
> URL: https://issues.apache.org/jira/browse/MNG-7404
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-1
>Reporter: Maarten Mulders
>Assignee: Maarten Mulders
>Priority: Minor
> Labels: must-be-in-4.0.0-alpha-1
> Fix For: 4.0.0-alpha-1
>
>
> Currently we produce a {{WARNING}} in case of using {{version}} or alike.
> I would suggest to change {{WARNING}} into a failing build in such use cases.
> {code}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for 'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
> [WARNING] The expression ${version} is deprecated. Please use
> ${project.version} instead.
> {code}
> WDYT?
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2063) Adding argLine with tab characters fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17527707#comment-17527707
]
Maarten Mulders commented on SUREFIRE-2063:
---
Moved to SUREFIRE-2077 - please share your thoughts, [~tibordigana] and
[~marcphilipp].
> Adding argLine with tab characters fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Assignee: Maarten Mulders
>Priority: Blocker
> Fix For: 3.0.0-M7
>
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (SUREFIRE-2077) argLine with two spaces doesn't work
Maarten Mulders created SUREFIRE-2077:
-
Summary: argLine with two spaces doesn't work
Key: SUREFIRE-2077
URL: https://issues.apache.org/jira/browse/SUREFIRE-2077
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Reporter: Maarten Mulders
Reported by [~marcphilipp]:
The fix for SUREFIRE-2063 breaks valid but questionable use cases such as
{code:xml}
"-DpropertyKey=value with 2 spaces"{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2063) Adding argLine with tab characters fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526808#comment-17526808
]
Maarten Mulders commented on SUREFIRE-2063:
---
{quote}Would it be sufficient to only replace tabs with spaces?
{quote}
I think the first implementation of the fix did just that, and then we decided
([pretty
last-minute|https://github.com/apache/maven-surefire/compare/14ab570030945063d774f73d731edab8796e55f1..71a173ddaf0a8dc9ee68e3720ca9f9c208492b65])
to go for the "replace all whitespace".
[~tibordigana], what do you think? Should we go back to the initial idea of
replacing {{"\n"}}, {{"\r"}} and {{"\t"}} only?
> Adding argLine with tab characters fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Assignee: Maarten Mulders
>Priority: Blocker
> Fix For: 3.0.0-M7
>
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (SUREFIRE-2063) Adding argLine with tab characters fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders resolved SUREFIRE-2063.
---
Fix Version/s: 3.0.0-M7
Assignee: Maarten Mulders
Resolution: Fixed
Fixed in
[{{apache/maven-surefire@0e08169}}|https://github.com/apache/maven-surefire/commit/0e08169214b78fc107c547728c5dd684b5d32d55].
> Adding argLine with tab characters fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Assignee: Maarten Mulders
>Priority: Blocker
> Fix For: 3.0.0-M7
>
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (SUREFIRE-2063) Adding argLine with tab characters fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated SUREFIRE-2063:
--
Summary: Adding argLine with tab characters fails (was: Adding
configuration using with --add-opens or --add-exports fails)
> Adding argLine with tab characters fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17524568#comment-17524568
]
Maarten Mulders commented on SUREFIRE-2063:
---
After digging into the integration test, it seems like the real problem is the
use of *tabs* rather than spaces. It consistently fails with anything inside
{{argLine}}, even when it's a simple {{-Dkey=value}} and not {{--add-opens}} or
{{--add-exports}}.
I'll update the issue title accordingly.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17523432#comment-17523432
]
Maarten Mulders edited comment on SUREFIRE-2063 at 4/17/22 7:15 PM:
I've run the project with {{mvn -X}}, and observed an interesting difference in
the output.
With Surefire 3.0.0-M5:
{code}[DEBUG] Forking command line: /bin/sh -c cd
/Users/maarten/Junk/surefire-bug/module1 &&
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java
--add-opens
org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
--add-opens
org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
@/Users/maarten/Junk/surefire-bug/module1/target/surefire/surefireargs3750425927935805323
/Users/maarten/Junk/surefire-bug/module1/target/surefire
2022-04-12T12-19-27_455-jvmRun1 surefire10840194083466728669tmp
surefire_017868848018900059027tmp
{code}
With Surefire 3.0.0-M6:
{code}[DEBUG] Forking command line: /bin/sh -c cd
'/Users/maarten/Junk/surefire-bug/module1' &&
'/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java'
'--add-opens'
'org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED' '
--add-opens'
'org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED'
'@/Users/maarten/Junk/surefire-bug/module1/target/surefire/surefireargs18068527077933644869'
'/Users/maarten/Junk/surefire-bug/module1/target/surefire'
'2022-04-12T12-15-39_065-jvmRun1' 'surefire5839325282694079238tmp'
'surefire_01690065092548918203tmp'
{code}
Note how, with M6, the spaces (or tabs) from the POM seem to get back into the
forked JVM argument list. I've manually tried to remove them and that made the
invocation succeed. I'll create a pull request to fix this.
was (Author: mthmulders):
I've run the project with {{mvn -X}}, and observed an interesting difference in
the output.
With Surefire 3.0.0-M5:
{code}[DEBUG] Forking command line: /bin/sh -c cd
/Users/maarten/Junk/surefire-bug/module1 &&
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java
--add-opens
org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
--add-opens
org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
@/Users/maarten/Junk/surefire-bug/module1/target/surefire/surefireargs3750425927935805323
/Users/maarten/Junk/surefire-bug/module1/target/surefire
2022-04-12T12-19-27_455-jvmRun1 surefire10840194083466728669tmp
surefire_017868848018900059027tmp
{code}
With Surefire 3.0.0-M6:
{code}[DEBUG] Forking command line: /bin/sh -c cd
'/Users/maarten/Junk/surefire-bug/module1' &&
'/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java'
'--add-opens'
'org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED' '
--add-opens'
'org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED'
'@/Users/maarten/Junk/surefire-bug/module1/target/surefire/surefireargs18068527077933644869'
'/Users/maarten/Junk/surefire-bug/module1/target/surefire'
'2022-04-12T12-15-39_065-jvmRun1' 'surefire5839325282694079238tmp'
'surefire_01690065092548918203tmp'
{code}
Note how, with M6, the spaces (or tabs) from the POM seem to get back into the
forked JVM argument list. I'll create a pull request to fix this.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
[jira] [Commented] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17523432#comment-17523432
]
Maarten Mulders commented on SUREFIRE-2063:
---
I've run the project with {{mvn -X}}, and observed an interesting difference in
the output.
With Surefire 3.0.0-M5:
{code}[DEBUG] Forking command line: /bin/sh -c cd
/Users/maarten/Junk/surefire-bug/module1 &&
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java
--add-opens
org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
--add-opens
org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
@/Users/maarten/Junk/surefire-bug/module1/target/surefire/surefireargs3750425927935805323
/Users/maarten/Junk/surefire-bug/module1/target/surefire
2022-04-12T12-19-27_455-jvmRun1 surefire10840194083466728669tmp
surefire_017868848018900059027tmp
{code}
With Surefire 3.0.0-M6:
{code}[DEBUG] Forking command line: /bin/sh -c cd
'/Users/maarten/Junk/surefire-bug/module1' &&
'/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home/bin/java'
'--add-opens'
'org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED' '
--add-opens'
'org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED'
'@/Users/maarten/Junk/surefire-bug/module1/target/surefire/surefireargs18068527077933644869'
'/Users/maarten/Junk/surefire-bug/module1/target/surefire'
'2022-04-12T12-15-39_065-jvmRun1' 'surefire5839325282694079238tmp'
'surefire_01690065092548918203tmp'
{code}
Note how, with M6, the spaces (or tabs) from the POM seem to get back into the
forked JVM argument list. I'll create a pull request to fix this.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520957#comment-17520957
]
Maarten Mulders edited comment on SUREFIRE-2063 at 4/12/22 7:44 AM:
Thank you, [~dsubel]!
If I did my {{git bisect}} magic correctly, this got introduced in
[{{2da8f9b3}}|https://github.com/apache/maven-surefire/commit/2da8f9b34da908b146e671d4b996a41bf81a9014].
That's a bit odd, as the commit seems to have _nothing_ to do with the module
system.
I'll see if I can do some more debugging.
was (Author: mthmulders):
Thank you, [~dsubel]!
If I did my {{git bisect}} magic correctly, this got introduced in
[{{2da8f9b3}}|https://github.com/apache/maven-surefire/commit/2da8f9b34da908b146e671d4b996a41bf81a9014].
That's a bit odd, as the commit seems to have _nothing_ to do with the module
system.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17520957#comment-17520957
]
Maarten Mulders commented on SUREFIRE-2063:
---
Thank you, [~dsubel]!
If I did my {{git bisect}} magic correctly, this got introduced in
[{{2da8f9b3}}|https://github.com/apache/maven-surefire/commit/2da8f9b34da908b146e671d4b996a41bf81a9014].
That's a bit odd, as the commit seems to have _nothing_ to do with the module
system.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17519708#comment-17519708
]
Maarten Mulders commented on SUREFIRE-2063:
---
[~dsubel], would it be possible for you to isolate the problem in a minimal
sample project? If it's indeed a bug, that sample could also serve as future
test case to prevent the bug from happening again.
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Blocker
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-2063) Adding configuration using with --add-opens or --add-exports fails
[
https://issues.apache.org/jira/browse/SUREFIRE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17518645#comment-17518645
]
Maarten Mulders commented on SUREFIRE-2063:
---
Maybe pointing out the obvious, but could it be related to this warning?
{code}
WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
{code}
> Adding configuration using with --add-opens or --add-exports fails
>
>
> Key: SUREFIRE-2063
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2063
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 3.0.0-M6
>Reporter: Daniel Subelman
>Priority: Major
>
> Since v3.3.0-M6 fails when using to export or open a package. The
> failure is produced when using --add-opens or --add-exports in .
> The execution doesn't fail with v3.3.0-M5 or earlier.
> As an example, it fails when using the following :
> {code:java}
>
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
>
> {code}
> The failure log:
> {code:java}
> [INFO] --- maven-surefire-plugin:3.0.0-M6:test (dev) @ testing ---
> [INFO] Using auto detected provider
> org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
> [INFO]
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> WARNING: Unknown module: org.junit.platform.commons specified to --add-opens
> Error: Could not find or load main class --add-opens
> Caused by: java.lang.ClassNotFoundException: --add-opens
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 9.157 s
> [INFO] Finished at: 2022-04-06T16:28:23-04:00
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M6:test (dev) on project
> testing:
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MSKINS-176) That Will Be Permalink As Well Done Bellow At Look
[ https://issues.apache.org/jira/browse/MSKINS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders closed MSKINS-176. -- Resolution: Invalid > That Will Be Permalink As Well Done Bellow At Look > -- > > Key: MSKINS-176 > URL: https://issues.apache.org/jira/browse/MSKINS-176 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin >Affects Versions: default-1.3, fluido-1.3.1, fluido-1.6, fluido-1.8 > Environment: Runners More Wait That Was Belong Of That Was I No More > Happy But away Are Trown own effect Are Bellow As Trips >Reporter: Swarup Patra >Priority: Minor > Labels: performance > Attachments: Screenshot_2022_0407_110912.png > > Original Estimate: 3,581h > Remaining Estimate: 3,581h > > That Will Be For Match Are Grow Up At Down More Looping At Sences That Will > Ready Us Called More Trips Are Belong That Was Troops Version Are Blood > Grought Complete Down Of Occos Are Looking More During Us Left Are More > Lighty Block More Success Figure That Was Left Are Brown Goal That Trips > Called More Down Runs That Way A Complete Ocvors Velocity Success During > Called Us More Rver Trips That Will Tooks Pond Questions Tolled Freelt Even > Buffer As Tooked Lokking Up Great Facualty Urban Trips That More Long Way > Havven No More Looking Us Craplote Upmaritions Yearly Takes More Lite Ly As > Figure Weed Have More Shortly Tht Was Copy Path Even More Looking Us Belong > As propratics That Remember Qre Head Or Body No More Left Us Hover That Was a > Block Peer To Long Read More Away Belong That Was Are Xcity. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7444) Multiple optional non-existing projects not logged correctly
[
https://issues.apache.org/jira/browse/MNG-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514039#comment-17514039
]
Maarten Mulders commented on MNG-7444:
--
Probably related: if my project has two modules, say {{mc}} and {{mt}}, and I
run {{mvn -pl \?:a,\?:mc,\?:mt}}, Maven only builds {{mc}}. That's not OK, it
should also build {{mt}}.
> Multiple optional non-existing projects not logged correctly
>
>
> Key: MNG-7444
> URL: https://issues.apache.org/jira/browse/MNG-7444
> Project: Maven
> Issue Type: Bug
> Components: Reactor and Workspace
> Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
> (31193cbf0c93205a63c8c7b372b09200f60e69f4)
>Reporter: Maarten Mulders
>Priority: Trivial
> Labels: up-for-grabs
>
> Run {{mvn -pl \?:a,\?:b validate}} (escaping necessary on POSIX compliant
> shells, Windows doesn't need it) on a project that does not have a module
> {{:a}} and {{:b}}.
> Expected:
> {code}
> [INFO] Could not find the selected project(s) in the reactor: :a, :b
> {code}
> Actual:
> {code}
> [INFO] Could not find the selected project in the reactor: :a
> {code}
> The output of {{mvn -help}} with regards to {{-pl}}:
> {quote}Comma-delimited list of specified reactor projects to build instead of
> all projects. A project can be specified by [groupId]:artifactId or by its
> relative path. Prefixing a project with ! excludes it, and ? marks it as
> optional{quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MNG-7444) Multiple optional non-existing projects not logged correctly
Maarten Mulders created MNG-7444:
Summary: Multiple optional non-existing projects not logged
correctly
Key: MNG-7444
URL: https://issues.apache.org/jira/browse/MNG-7444
Project: Maven
Issue Type: Bug
Components: Reactor and Workspace
Environment: Apache Maven 4.0.0-alpha-1-SNAPSHOT
(31193cbf0c93205a63c8c7b372b09200f60e69f4)
Reporter: Maarten Mulders
Run {{mvn -pl \?:a,\?:b validate}} (escaping necessary on POSIX compliant
shells, Windows doesn't need it) on a project that does not have a module
{{:a}} and {{:b}}.
Expected:
{code}
[INFO] Could not find the selected project(s) in the reactor: :a, :b
{code}
Actual:
{code}
[INFO] Could not find the selected project in the reactor: :a
{code}
The output of {{mvn -help}} with regards to {{-pl}}:
{quote}Comma-delimited list of specified reactor projects to build instead of
all projects. A project can be specified by [groupId]:artifactId or by its
relative path. Prefixing a project with ! excludes it, and ? marks it as
optional{quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MNG-7437) Optional profiles that are not found logs warning twice
[ https://issues.apache.org/jira/browse/MNG-7437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders closed MNG-7437. Fix Version/s: (was: wontfix-candidate) Resolution: Won't Fix > Optional profiles that are not found logs warning twice > --- > > Key: MNG-7437 > URL: https://issues.apache.org/jira/browse/MNG-7437 > Project: Maven > Issue Type: Bug > Components: Command Line, Core, Logging >Affects Versions: 4.0.0-alpha-1 >Reporter: Giovanni van der Schelde >Priority: Minor > Attachments: image-2022-03-21-21-50-55-930.png > > > Maven 4 (MNG-7051) introduced optional profiles, and if such profile could > not be found, the build continues and logs a warning. > Whenever I run this command I noticed the warning is logged twice. Once > before the build and once after the build. This seems unnecessary and is > inconsistent with the behaviour of optional projects. > !image-2022-03-21-21-50-55-930.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7430) mark MojoExecutionException as deprecated
[
https://issues.apache.org/jira/browse/MNG-7430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17506022#comment-17506022
]
Maarten Mulders commented on MNG-7430:
--
I think, to many of our users there's no big difference between build *error*
or build {*}failure{*}. I would be fine with (eventually) dropping the
difference, _unless_ we could make the difference very clear to end users, with
concrete advice on what to do in either situation.
> mark MojoExecutionException as deprecated
> -
>
> Key: MNG-7430
> URL: https://issues.apache.org/jira/browse/MNG-7430
> Project: Maven
> Issue Type: Task
> Components: Core
>Reporter: Olivier Lamy
>Priority: Major
>
> since the start of Maven 3.x there is no more difference in the build
> result/output between MojoFailureException and MojoExecutionException.
> Even the javadoc is wrong as it says
> {quote}Throwing this exception causes a "BUILD ERROR" message to be
> displayed.{quote}
>
> https://github.com/apache/maven/blob/14ca7234380f81e54a5643082816048f3b6b67cf/maven-plugin-api/src/main/java/org/apache/maven/plugin/MojoExecutionException.java#L24
> which definitely never happen see sample here
> https://github.com/olamy/maven-exception-plugin
> we could mark it as deprecated for 3.9.x onward.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Closed] (MPOM-301) mohands...@gmail.com
[ https://issues.apache.org/jira/browse/MPOM-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders closed MPOM-301. Resolution: Invalid > mohands...@gmail.com > > > Key: MPOM-301 > URL: https://issues.apache.org/jira/browse/MPOM-301 > Project: Maven POMs > Issue Type: Test >Reporter: mohandsedu >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7409) Improve exception message for VersionResolutionException thrown from o.a.m.repository.internal.DefaultVersionResolver
[
https://issues.apache.org/jira/browse/MNG-7409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17495040#comment-17495040
]
Maarten Mulders commented on MNG-7409:
--
I agree with you [~michael-o] that copying (an) exception message(s) seems like
a strange approach. It's similar to the construct we saw in the
[{{ProjectBuildingException}}|https://github.com/apache/maven/commit/0be5e406d78062b56b32644fefce2642f5eab650]
that we've recently removed.
I'd prefer dedicated Exceptions for the "predictable" error scenario's (e.g.
"local repo didn't have anything and remote lookup was not tried [etc.]"). It
would mean we could keep those Exception(s) in the {{VersionResult}} and only
print the details when needed (i.e., in the CLI). WDYT?
> Improve exception message for VersionResolutionException thrown from
> o.a.m.repository.internal.DefaultVersionResolver
> -
>
> Key: MNG-7409
> URL: https://issues.apache.org/jira/browse/MNG-7409
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 3.8.4
>Reporter: Konrad Windszus
>Priority: Minor
>
> I have seen the following exception message with Maven 3.8.4
> {code}
> [DEBUG] Skipped remote request for
> com.adobe.aem:aemanalyser-maven-plugin/maven-metadata.xml locally installed
> metadata up-to-date
>
> [ERROR]
> Caused by: org.eclipse.aether.resolution.VersionResolutionException: Failed
> to resolve version for com.adobe.aem:aemanalyser-maven-plugin:jar:RELEASE
> at
> org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion
> (DefaultVersionResolver.java:276)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveVersion
> (DefaultRepositorySystem.java:240)
> at com.adobe.aem.analyser.mojos.VersionUtil.getLatestVersion
> (VersionUtil.java:232)
> at com.adobe.aem.analyser.mojos.VersionUtil.checkPluginVersion
> (VersionUtil.java:253)
> at com.adobe.aem.analyser.mojos.AemAnalyseMojo.execute
> (AemAnalyseMojo.java:243)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:972)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> {code}
> (this was triggered in
> https://github.com/adobe/aemanalyser-maven-plugin/issues/138).
> The real cause is not visible in the stack trace as it seems that the
> {{VersionResult}} being passed to the constructor of
> {{VersionResolutionException}} in
> https://github.com/apache/maven/blob/6ca13af230e9a7c6dcb0bf629d9a2676d8f833ed/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/DefaultVersionResolver.java#L242
> does not contain enough information.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7244) Remove deprecated WARNING for usage of pom.X placeholders
[
https://issues.apache.org/jira/browse/MNG-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7244:
-
Description:
Currently, we produce a {{WARNING}} in case of using {{pom.version}} or alike.
We've been doing that for years so people have had enough time to update their
projects. We can now remove the support and the accompanying warning, resorting
to the default behaviour of not resolving the expression at all.
{code}
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
[WARNING] The expression ${pom.version} is deprecated. Please use
${project.version} instead.
{code}
was:
Currently we produce a {{WARNING}} in case of using {{pom.version}} or alike.
I would suggest to change {{WARNING}} into a failing build in such use cases.
{code}
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
[WARNING] The expression ${pom.version} is deprecated. Please use
${project.version} instead.
{code}
WDYT?
> Remove deprecated WARNING for usage of pom.X placeholders
> -
>
> Key: MNG-7244
> URL: https://issues.apache.org/jira/browse/MNG-7244
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-1
>Reporter: Karl Heinz Marbaise
>Assignee: Maarten Mulders
>Priority: Minor
> Labels: must-be-in-4.0.0-alpha-1
> Fix For: 4.0.x-candidate
>
>
> Currently, we produce a {{WARNING}} in case of using {{pom.version}} or alike.
> We've been doing that for years so people have had enough time to update
> their projects. We can now remove the support and the accompanying warning,
> resorting to the default behaviour of not resolving the expression at all.
> {code}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for 'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
> [WARNING] The expression ${pom.version} is deprecated. Please use
> ${project.version} instead.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7244) Remove deprecated WARNING for usage of pom.X placeholders
[
https://issues.apache.org/jira/browse/MNG-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7244:
-
Summary: Remove deprecated WARNING for usage of pom.X placeholders (was:
Change from deprecated WARNING to FAIL the build for usage of pom.X
placeholders)
> Remove deprecated WARNING for usage of pom.X placeholders
> -
>
> Key: MNG-7244
> URL: https://issues.apache.org/jira/browse/MNG-7244
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-1
>Reporter: Karl Heinz Marbaise
>Assignee: Maarten Mulders
>Priority: Minor
> Labels: must-be-in-4.0.0-alpha-1
> Fix For: 4.0.x-candidate
>
>
> Currently we produce a {{WARNING}} in case of using {{pom.version}} or alike.
> I would suggest to change {{WARNING}} into a failing build in such use cases.
> {code}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for 'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
> [WARNING] The expression ${pom.version} is deprecated. Please use
> ${project.version} instead.
> {code}
> WDYT?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (MNG-7406) Strange formatting of warning/errors from project building
[
https://issues.apache.org/jira/browse/MNG-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders resolved MNG-7406.
--
Resolution: Fixed
Fixed in
{{[apache/maven@0be5e40|https://github.com/apache/maven/commit/0be5e406d78062b56b32644fefce2642f5eab650]}}.
> Strange formatting of warning/errors from project building
> --
>
> Key: MNG-7406
> URL: https://issues.apache.org/jira/browse/MNG-7406
> Project: Maven
> Issue Type: Improvement
> Components: Errors
>Affects Versions: 4.0.x-candidate
>Reporter: Maarten Mulders
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 4.0.0-alpha-1
>
> Attachments: after.png, before.png, image.png
>
>
> If Maven finds an error while building the model, it throws a
> {{{}ProjectBuildingException{}}}. When that makes it to the CLI, it is
> printed in a bit strange way:
> !image.png!
> Note how the message reads:
> {code:java}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] The expression ${pom.organization.name} is no longer supported.
> Please use ${project.organization.name} instead.
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project foo:bar:1.0-SNAPSHOT (/private/tmp/ner/bar/pom.xml) has
> 1 error
> [ERROR] The expression ${pom.organization.name} is no longer supported.
> Please use ${project.organization.name} instead.
> [ERROR] {code}
> # It contains a severity marker *twice*
> # It repeats the error/warning message
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7329) Upgrade maven-enforcer-plugin to 3.0.0
[
https://issues.apache.org/jira/browse/MNG-7329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493339#comment-17493339
]
Maarten Mulders commented on MNG-7329:
--
{quote}[~gnodet], necessary for 3.9.0?
{quote}
Only if
[c3962c1a|https://github.com/apache/maven/commit/c3962c1a6c0b40abbfb12740253437f6431b234b]
is also in 3.9.0.
> Upgrade maven-enforcer-plugin to 3.0.0
> --
>
> Key: MNG-7329
> URL: https://issues.apache.org/jira/browse/MNG-7329
> Project: Maven
> Issue Type: Task
> Components: Core
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1, 3.9.0-candidate
>
>
> Upgrade to latest maven-enforcer-plugin to allow building master with maven 4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (SUREFIRE-1993) Failsafe fails to detect module dependencies
[
https://issues.apache.org/jira/browse/SUREFIRE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders resolved SUREFIRE-1993.
---
Resolution: Fixed
Fixed with
[{{6ea957e}}|https://github.com/apache/maven-surefire/commit/6ea957ef1f0be5321c5bef0f86e5003289fe8cd0].
> Failsafe fails to detect module dependencies
>
>
> Key: SUREFIRE-1993
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1993
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: Java 17
> Maven 4.0.0-alpha-SNAPSHOT and 3.8.4
>Reporter: Maarten Mulders
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 3.0.0-M6
>
> Attachments: reproducer.zip
>
>
> Please see the attached project. It has three Maven modules, each defining
> its own JPMS module. The *application* module depends on an interface from
> the *studentservice* module, and the implementation for that interface lives
> in {*}studentservice-provider{*}. The {{module-info.java}} for the
> *studentservice-provider* module declares the implementation of that
> interface.
> When you run the application using {{{}./manually.sh{}}}, it correctly loads
> the *studentservice-provider* module. When you run the IT, it does not.
> The application prints the module path to standard out.
> From the test script it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar
> studentservice-provider/target/studentservice-provider-1.jar{code}
> From the integration test, which starts the same application, it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar{code}
>
> Note how in the integration test the *studentservice-provider* is missing in
> the output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1993) Failsafe fails to detect module dependencies
[
https://issues.apache.org/jira/browse/SUREFIRE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489305#comment-17489305
]
Maarten Mulders commented on SUREFIRE-1993:
---
Thanks, running {{install}} rather than {{verify}} did the trick. Expect a PR
soonish™.
> Failsafe fails to detect module dependencies
>
>
> Key: SUREFIRE-1993
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1993
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: Java 17
> Maven 4.0.0-alpha-SNAPSHOT and 3.8.4
>Reporter: Maarten Mulders
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 3.0.0-M6
>
> Attachments: reproducer.zip
>
>
> Please see the attached project. It has three Maven modules, each defining
> its own JPMS module. The *application* module depends on an interface from
> the *studentservice* module, and the implementation for that interface lives
> in {*}studentservice-provider{*}. The {{module-info.java}} for the
> *studentservice-provider* module declares the implementation of that
> interface.
> When you run the application using {{{}./manually.sh{}}}, it correctly loads
> the *studentservice-provider* module. When you run the IT, it does not.
> The application prints the module path to standard out.
> From the test script it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar
> studentservice-provider/target/studentservice-provider-1.jar{code}
> From the integration test, which starts the same application, it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar{code}
>
> Note how in the integration test the *studentservice-provider* is missing in
> the output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1993) Failsafe fails to detect module dependencies
[
https://issues.apache.org/jira/browse/SUREFIRE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488982#comment-17488982
]
Maarten Mulders commented on SUREFIRE-1993:
---
[~tibordigana], I'm having a hard time getting the IT's to run locally. I tried
to run them with {{mvn verify -P run-its}} but even the existing ones (for
example {{JUnitPlatformIT.testMultipleEngines}}) fail with
{code}[ERROR] Caused by: java.lang.ClassNotFoundException:
org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
[ERROR] at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
[ERROR] at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
[ERROR] at
java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
[ERROR] at
org.apache.maven.surefire.api.util.ReflectionUtils.loadClass(ReflectionUtils.java:215)
[ERROR] ... 6 more
[ERROR] {code}
It's probably something stupid I'm missing - does it make a bell ring for you?
> Failsafe fails to detect module dependencies
>
>
> Key: SUREFIRE-1993
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1993
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: Java 17
> Maven 4.0.0-alpha-SNAPSHOT and 3.8.4
>Reporter: Maarten Mulders
>Priority: Minor
> Attachments: reproducer.zip
>
>
> Please see the attached project. It has three Maven modules, each defining
> its own JPMS module. The *application* module depends on an interface from
> the *studentservice* module, and the implementation for that interface lives
> in {*}studentservice-provider{*}. The {{module-info.java}} for the
> *studentservice-provider* module declares the implementation of that
> interface.
> When you run the application using {{{}./manually.sh{}}}, it correctly loads
> the *studentservice-provider* module. When you run the IT, it does not.
> The application prints the module path to standard out.
> From the test script it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar
> studentservice-provider/target/studentservice-provider-1.jar{code}
> From the integration test, which starts the same application, it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar{code}
>
> Note how in the integration test the *studentservice-provider* is missing in
> the output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1993) Failsafe fails to detect module dependencies
[
https://issues.apache.org/jira/browse/SUREFIRE-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488713#comment-17488713
]
Maarten Mulders commented on SUREFIRE-1993:
---
I'll happily provide a pull request with a reproducer project (integration
test) and a fix.
> Failsafe fails to detect module dependencies
>
>
> Key: SUREFIRE-1993
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1993
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 3.0.0-M5
> Environment: Java 17
> Maven 4.0.0-alpha-SNAPSHOT and 3.8.4
>Reporter: Maarten Mulders
>Priority: Minor
> Attachments: reproducer.zip
>
>
> Please see the attached project. It has three Maven modules, each defining
> its own JPMS module. The *application* module depends on an interface from
> the *studentservice* module, and the implementation for that interface lives
> in {*}studentservice-provider{*}. The {{module-info.java}} for the
> *studentservice-provider* module declares the implementation of that
> interface.
> When you run the application using {{{}./manually.sh{}}}, it correctly loads
> the *studentservice-provider* module. When you run the IT, it does not.
> The application prints the module path to standard out.
> From the test script it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar
> studentservice-provider/target/studentservice-provider-1.jar{code}
> From the integration test, which starts the same application, it prints:
> {code:java}
> application/target/application-1.jar
> studentservice/target/studentservice-1.jar{code}
>
> Note how in the integration test the *studentservice-provider* is missing in
> the output.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (MCOMPILER-460) Compiler doesn't show detailed information with the Maven Toolchains
[
https://issues.apache.org/jira/browse/MCOMPILER-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders reassigned MCOMPILER-460:
-
Assignee: Maarten Mulders
> Compiler doesn't show detailed information with the Maven Toolchains
>
>
> Key: MCOMPILER-460
> URL: https://issues.apache.org/jira/browse/MCOMPILER-460
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.8.1
> Environment: Windows Java 16
>Reporter: Johan Janssen
>Assignee: Maarten Mulders
>Priority: Major
>
> I've created an example to showcase the issue:
> [https://github.com/johanjanssen/mavenexample]
> When running without the Toolchains on Java 16
> {code:java}
> mvn compile or docker build -t mavenexample -f DockerfileJava16 .
> {code}
> Gives
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project broken: Fatal error compiling:
> java.lang.IllegalAccessError: class lombok.javac.apt.LombokProcessor (in
> unnamed module @0x21bd20ee) cannot access class
> com.sun.tools.javac.processing.JavacProcessingEnvironment (in module
> jdk.compiler) because module jdk.compiler does not export
> com.sun.tools.javac.processing to unnamed module @0x21bd20ee -> [Help 1]{code}
> When running with the Toolchains on Java 16
> {code:java}
> mvn compile -Ptoolchain or docker build -t mavenexample -f
> DockerfileJava16Toolchain .
> {code}
> Gives
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project broken: Compilation failure -> [Help 1]{code}
> So the Toolchain setup lacks quite some information about the compilation
> failure.
> Is it possible to get the same error information when using the toolchain?
> My usecase is having a quick way to build the same code with 2 different
> versions of Java. To show one version works and the other fails. It's also
> possible with Docker or setting the JAVA_HOME variable. But I was curious to
> see if it would work with toolchains as well.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7406) Strange formatting of warning/errors from project building
[
https://issues.apache.org/jira/browse/MNG-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Mulders updated MNG-7406:
-
Attachment: before.png
after.png
> Strange formatting of warning/errors from project building
> --
>
> Key: MNG-7406
> URL: https://issues.apache.org/jira/browse/MNG-7406
> Project: Maven
> Issue Type: Improvement
> Components: Errors
>Affects Versions: 4.0.x-candidate
>Reporter: Maarten Mulders
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 4.0.0-alpha-1
>
> Attachments: after.png, before.png, image.png
>
>
> If Maven finds an error while building the model, it throws a
> {{{}ProjectBuildingException{}}}. When that makes it to the CLI, it is
> printed in a bit strange way:
> !image.png!
> Note how the message reads:
> {code:java}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] The expression ${pom.organization.name} is no longer supported.
> Please use ${project.organization.name} instead.
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project foo:bar:1.0-SNAPSHOT (/private/tmp/ner/bar/pom.xml) has
> 1 error
> [ERROR] The expression ${pom.organization.name} is no longer supported.
> Please use ${project.organization.name} instead.
> [ERROR] {code}
> # It contains a severity marker *twice*
> # It repeats the error/warning message
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-7406) Strange formatting of warning/errors from project building
[
https://issues.apache.org/jira/browse/MNG-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17488643#comment-17488643
]
Maarten Mulders commented on MNG-7406:
--
Before: !before.png!
After: !after.png!
> Strange formatting of warning/errors from project building
> --
>
> Key: MNG-7406
> URL: https://issues.apache.org/jira/browse/MNG-7406
> Project: Maven
> Issue Type: Improvement
> Components: Errors
>Affects Versions: 4.0.x-candidate
>Reporter: Maarten Mulders
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 4.0.0-alpha-1
>
> Attachments: after.png, before.png, image.png
>
>
> If Maven finds an error while building the model, it throws a
> {{{}ProjectBuildingException{}}}. When that makes it to the CLI, it is
> printed in a bit strange way:
> !image.png!
> Note how the message reads:
> {code:java}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] The expression ${pom.organization.name} is no longer supported.
> Please use ${project.organization.name} instead.
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project foo:bar:1.0-SNAPSHOT (/private/tmp/ner/bar/pom.xml) has
> 1 error
> [ERROR] The expression ${pom.organization.name} is no longer supported.
> Please use ${project.organization.name} instead.
> [ERROR] {code}
> # It contains a severity marker *twice*
> # It repeats the error/warning message
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MRELEASE-1077) Support for prepare specific profiles
[ https://issues.apache.org/jira/browse/MRELEASE-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487722#comment-17487722 ] Maarten Mulders commented on MRELEASE-1077: --- Isn't generating or updating a file something you could do using a Release Strategy Interface (MRELEASE-956)? > Support for prepare specific profiles > - > > Key: MRELEASE-1077 > URL: https://issues.apache.org/jira/browse/MRELEASE-1077 > Project: Maven Release Plugin > Issue Type: New Feature > Components: prepare >Affects Versions: 3.0.0-M5 >Reporter: Niels Basjes >Priority: Minor > > In my projects I like to have the latest released version of the software > shown on the website (which is also in the source tree). I do this using the > exec plugin which runs a script to write the project version in a few places. > For this purpose I propose having the option to allow specifying one or more > profiles that are activated during the prepare phase. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7344) Effective pom should contain more finegrained details regarding its path.
[
https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17487101#comment-17487101
]
Maarten Mulders commented on MNG-7344:
--
Situation:
!MicrosoftTeams-image.png!
Thoughts so far
# We need a place in the Modello generated classes to keep track of "why we
loaded this model". Let's call it "referencing model"; it's a variable of type
{{InputLocation}}. *This requires a change in Modello*
# When we merge the model of an "intermediary" BOM ("bom-a" or "bom-b",
respectively), we make a copy of the elements that we take from BOM C and
overwrite in bom-a or bom-b, but we add the {{referencingModel}} (which is
"bom-a" or "bom-b", respectively) to the copy. *This requires a change in our
own "Model Merger" classes.*
# When we want to know the resolution path of a particular element in the
effective model, we can follow back the {{referencingModel}} to find the path
from "pom" to "bom-c", including the route that we took (either over "bom-a" or
"bom-b"). *This requires a change in the Maven Help Plugin (MPH-183).*
> Effective pom should contain more finegrained details regarding its path.
> -
>
> Key: MNG-7344
> URL: https://issues.apache.org/jira/browse/MNG-7344
> Project: Maven
> Issue Type: Improvement
> Components: Inheritance and Interpolation, POM
>Reporter: Robert Scholte
>Priority: Major
> Attachments: MicrosoftTeams-image.png
>
>
> To support MPH-183 some changes needs to be done in Maven Core.
> For every element that is not part of the raw model, it must be possible to
> get the resolution path to that element.
> The following are known to add elements to the effective pom without pure
> inheritance
> - BOMs
> - maven-tiles by [~talios]
> Without this feature, it is very hard to detect where elements are coming
> from.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7344) Effective pom should contain more finegrained details regarding its path.
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MNG-7344: - Attachment: MicrosoftTeams-image.png > Effective pom should contain more finegrained details regarding its path. > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > Attachments: MicrosoftTeams-image.png > > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the resolution path to that element. > The following are known to add elements to the effective pom without pure > inheritance > - BOMs > - maven-tiles by [~talios] > Without this feature, it is very hard to detect where elements are coming > from. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (MNG-7344) Effective pom should contain more finegrained details regarding its path.
[ https://issues.apache.org/jira/browse/MNG-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MNG-7344: - Description: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model, it must be possible to get the resolution path to that element. The following are known to add elements to the effective pom without pure inheritance - BOMs - maven-tiles by [~talios] Without this feature, it is very hard to detect where elements are coming from. was: To support MPH-183 some changes needs to be done in Maven Core. For every element that is not part of the raw model it must be possible to get the resolution path to that element. The following are known to add elements to the effective pom without pure inhertence - BOMs - maven-tiles by [~talios] Without this feature is is very hard to detect where elements are coming from. > Effective pom should contain more finegrained details regarding its path. > - > > Key: MNG-7344 > URL: https://issues.apache.org/jira/browse/MNG-7344 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation, POM >Reporter: Robert Scholte >Priority: Major > > To support MPH-183 some changes needs to be done in Maven Core. > For every element that is not part of the raw model, it must be possible to > get the resolution path to that element. > The following are known to add elements to the effective pom without pure > inheritance > - BOMs > - maven-tiles by [~talios] > Without this feature, it is very hard to detect where elements are coming > from. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7244) Change from deprecated WARNING to FAIL the build for usage of pom.X placeholders
[
https://issues.apache.org/jira/browse/MNG-7244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485872#comment-17485872
]
Maarten Mulders commented on MNG-7244:
--
Rather than failing the build, would it be OK to just continue silently? Just
like we would do when the user has an expression {{foo.bar.baz}} that can't be
resolved: we continue the build, and the expression ends up in the eventual
Project Object Model.
It would make the code a lot simpler if we could do that. Right now, there's
code especially crafted to see if {{pom.X}} would resolve against {{project}},
and then logging the warning. Getting rid of that would make the code base more
simple, especially when we combine it with MNG-7404.
> Change from deprecated WARNING to FAIL the build for usage of pom.X
> placeholders
>
>
> Key: MNG-7244
> URL: https://issues.apache.org/jira/browse/MNG-7244
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 4.0.0-alpha-1
>Reporter: Karl Heinz Marbaise
>Assignee: Maarten Mulders
>Priority: Minor
> Labels: must-be-in-4.0.0-alpha-1
> Fix For: 4.0.x-candidate
>
>
> Currently we produce a {{WARNING}} in case of using {{pom.version}} or alike.
> I would suggest to change {{WARNING}} into a failing build in such use cases.
> {code}
> [WARNING]
> [WARNING] Some problems were encountered while building the effective model
> for 'com.soebes.examples.j2ee:appasm:pom:1.0-SNAPSHOT'
> [WARNING] The expression ${pom.version} is deprecated. Please use
> ${project.version} instead.
> {code}
> WDYT?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MNG-7407) Allow core extensions to override default CI Friendly Versions handling
[ https://issues.apache.org/jira/browse/MNG-7407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Mulders updated MNG-7407: - Summary: Allow core extensions to override default CI Friendly Versions handling (was: Allow core extensions to override default CI Firendly Versions handling) > Allow core extensions to override default CI Friendly Versions handling > --- > > Key: MNG-7407 > URL: https://issues.apache.org/jira/browse/MNG-7407 > Project: Maven > Issue Type: Improvement >Reporter: Christoph Läubrich >Priority: Major > > Currently the handling for https://maven.apache.org/maven-ci-friendly.html is > hard wired into maven. > For Tycho we like to replace/extend the default handling for this to supply > the user with some automatic derived values for some of the variables. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MNG-7406) Strange formatting of warning/errors from project building
[
https://issues.apache.org/jira/browse/MNG-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485319#comment-17485319
]
Maarten Mulders commented on MNG-7406:
--
The issue is caused by two things:
# the {{ProjectBuildingException}} formats its contained information (a list of
{{ProjectBuildingResult}} objects) and stores it _in its message_
# the {{DefaultMaven}} prints the {{ProjectBuildingResult}} objects using
their {{toString}} (including severity and, when available, location info)
> Strange formatting of warning/errors from project building
> --
>
> Key: MNG-7406
> URL: https://issues.apache.org/jira/browse/MNG-7406
> Project: Maven
> Issue Type: Improvement
> Components: Errors
>Affects Versions: 4.0.x-candidate
>Reporter: Maarten Mulders
>Assignee: Maarten Mulders
>Priority: Minor
> Fix For: 4.0.0-alpha-1
>
> Attachments: image.png
>
>
> If Maven finds an error while building the model, it throws a
> {{{}ProjectBuildingException{}}}. When that makes it to the CLI, it is
> printed in a bit strange way:
> !image.png!
> Note how the message reads:
> {code:java}
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] The expression ${pom.organization.name} is no longer supported.
> Please use ${project.organization.name} instead.
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project foo:bar:1.0-SNAPSHOT (/private/tmp/ner/bar/pom.xml) has
> 1 error
> [ERROR] The expression ${pom.organization.name} is no longer supported.
> Please use ${project.organization.name} instead.
> [ERROR] {code}
> # It contains a severity marker *twice*
> # It repeats the error/warning message
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
