[jira] [Commented] (MPLUGIN-504) [regression] Goal prefix is required now
[ https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853127#comment-17853127 ] Romain Manni-Bucau commented on MPLUGIN-504: yes you are right, warnings were in two cases: # usage of maven "namespace" # misalignment between artifact name and prefix Now 2 is enabled since it is explicit so no misconfiguration to protect against as before since you still have to respect the convention x-maven-plugin. Guess we can have a toggle "useHeuristic" but since it will only apply to v3 - we don't want it anymore so for v4 it should be forbidden, I don't see much value about it this is why i think an temporary extension as workaround can not be that bad if you find it blocking. > [regression] Goal prefix is required now > > > Key: MPLUGIN-504 > URL: https://issues.apache.org/jira/browse/MPLUGIN-504 > Project: Maven Plugin Tools > Issue Type: Bug >Reporter: Christoph Läubrich >Priority: Major > > With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression > introduced that leads to previous working builds fail if the have not > configured a goalprefix, the error message is: > > You need to specify a goalPrefix as it can not be correctly computed > This has several issues: > # It does not explain why one "needs" a goalPrefix, nor what it is useful for > or why it can not be correctly computed. > # It is effectively a breaking change in a minor version increment > # The inital JIRA mentions that > a) in general, goal prefix is *+optional+*, but "good to have", and usually > is present. > b) we may want to have some option to turn off this feature > # Now it is required and there is no option to turn it off > Also the message is not true, the plugin has successfully computed a prefix > before without any issues: > * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the > my-cool was chosen > * If the artifact ends with -plugin as in my-cool-plugin the my-cool was > chosen > * otherwise the full artifact if was chosen as a prefix as in my-cool the > my-cool was chosen > From a users point of view I don't see any problem or "disambiguates" with > this approach that justifies a breaking change here, anyone who is concerned > about not using this default can and already could choose a prefix and seem > to been fine with it for a long time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-504) [regression] Goal prefix is required now
[ https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853053#comment-17853053 ] Romain Manni-Bucau commented on MPLUGIN-504: Well a warning should always be read and get an action and 10+ years of warn and proper doc are way sufficient for a change. Agree the versioning is not semver...but we dont use semver too so all good and maybe food for enhancements. About the extension just ensure your extension injects the prefix in the model and be it. > [regression] Goal prefix is required now > > > Key: MPLUGIN-504 > URL: https://issues.apache.org/jira/browse/MPLUGIN-504 > Project: Maven Plugin Tools > Issue Type: Bug >Reporter: Christoph Läubrich >Priority: Major > > With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression > introduced that leads to previous working builds fail if the have not > configured a goalprefix, the error message is: > > You need to specify a goalPrefix as it can not be correctly computed > This has several issues: > # It does not explain why one "needs" a goalPrefix, nor what it is useful for > or why it can not be correctly computed. > # It is effectively a breaking change in a minor version increment > # The inital JIRA mentions that > a) in general, goal prefix is *+optional+*, but "good to have", and usually > is present. > b) we may want to have some option to turn off this feature > # Now it is required and there is no option to turn it off > Also the message is not true, the plugin has successfully computed a prefix > before without any issues: > * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the > my-cool was chosen > * If the artifact ends with -plugin as in my-cool-plugin the my-cool was > chosen > * otherwise the full artifact if was chosen as a prefix as in my-cool the > my-cool was chosen > From a users point of view I don't see any problem or "disambiguates" with > this approach that justifies a breaking change here, anyone who is concerned > about not using this default can and already could choose a prefix and seem > to been fine with it for a long time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-504) [regression] Goal prefix is required now
[ https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852932#comment-17852932 ] Romain Manni-Bucau commented on MPLUGIN-504: Yes sometimes the heuristic works and you can see it sad it is not kept, that said I always got a warning not setting the prefix since I started to write maven plugin 10+ years ago so not sure we speak of much cases there. That said an extension is trivial to get back previous behavior if so critical? > [regression] Goal prefix is required now > > > Key: MPLUGIN-504 > URL: https://issues.apache.org/jira/browse/MPLUGIN-504 > Project: Maven Plugin Tools > Issue Type: Bug >Reporter: Christoph Läubrich >Priority: Major > > With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression > introduced that leads to previous working builds fail if the have not > configured a goalprefix, the error message is: > > You need to specify a goalPrefix as it can not be correctly computed > This has several issues: > # It does not explain why one "needs" a goalPrefix, nor what it is useful for > or why it can not be correctly computed. > # It is effectively a breaking change in a minor version increment > # The inital JIRA mentions that > a) in general, goal prefix is *+optional+*, but "good to have", and usually > is present. > b) we may want to have some option to turn off this feature > # Now it is required and there is no option to turn it off > Also the message is not true, the plugin has successfully computed a prefix > before without any issues: > * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the > my-cool was chosen > * If the artifact ends with -plugin as in my-cool-plugin the my-cool was > chosen > * otherwise the full artifact if was chosen as a prefix as in my-cool the > my-cool was chosen > From a users point of view I don't see any problem or "disambiguates" with > this approach that justifies a breaking change here, anyone who is concerned > about not using this default can and already could choose a prefix and seem > to been fine with it for a long time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7266) Remove maven-compat module
[ https://issues.apache.org/jira/browse/MNG-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837200#comment-17837200 ] Romain Manni-Bucau commented on MNG-7266: - Let's drop it, worse case we compensate it later if really bothering for some plugin but shouldnt now. > Remove maven-compat module > -- > > Key: MNG-7266 > URL: https://issues.apache.org/jira/browse/MNG-7266 > Project: Maven > Issue Type: Sub-task >Reporter: Guillaume Nodet >Priority: Major > Fix For: 4.0.x-candidate > > > Maven-core does not depend on maven-compat anymore (runtime or compile time). > Do we want to carry it over up to 4.0.0 and delete it in 4.1.0, or do we > want to drop it before 4.0.0 ? > [~cstamas] [~olamy] [~romain.manni-bucau] [~sjaranowski] and others... ? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MARTIFACT-59) artifact plugin should tolerate injected project.build.outputTimestamp
[
https://issues.apache.org/jira/browse/MARTIFACT-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated MARTIFACT-59:
Description:
Goal is to not log
{code:java}
Reproducible Build not activated by project.build.outputTimestamp property: see
https://maven.apache.org/guides/mini/guide-reproducible-builds.html {code}
when the project is actually set but computed from another property and not
fail (check mojo) when the setup is the same.
> artifact plugin should tolerate injected project.build.outputTimestamp
> --
>
> Key: MARTIFACT-59
> URL: https://issues.apache.org/jira/browse/MARTIFACT-59
> Project: Maven Artifact Plugin
> Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Priority: Minor
> Labels: pull-request-available
>
> Goal is to not log
> {code:java}
> Reproducible Build not activated by project.build.outputTimestamp property:
> see https://maven.apache.org/guides/mini/guide-reproducible-builds.html {code}
> when the project is actually set but computed from another property and not
> fail (check mojo) when the setup is the same.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-8077) artifact plugin should tolerate injected project.build.outputTimestamp
Romain Manni-Bucau created MNG-8077: --- Summary: artifact plugin should tolerate injected project.build.outputTimestamp Key: MNG-8077 URL: https://issues.apache.org/jira/browse/MNG-8077 Project: Maven Issue Type: Task Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MCOMPILER-580) Remove all properties overlapping with args
Romain Manni-Bucau created MCOMPILER-580: Summary: Remove all properties overlapping with args Key: MCOMPILER-580 URL: https://issues.apache.org/jira/browse/MCOMPILER-580 Project: Maven Compiler Plugin Issue Type: Task Reporter: Romain Manni-Bucau We tend to have duplicated compiler options as properties but we don't validate the presence in both leading to broken setups if user prefer to use args for consistency (evertything configured at the same location rather than spread accross levels). Goal of this ticket is to revisit that for v4.0.0 and drop all custom properties to 100% leverage the compilerArgs only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-467) Dependency-reduced POM with missing exclusions in concurrent build
[
https://issues.apache.org/jira/browse/MSHADE-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17809416#comment-17809416
]
Romain Manni-Bucau commented on MSHADE-467:
---
Fixed for 3.5.2 but I don't have Jira perms to flag it, if anyone can do it
would be welcomed.
> Dependency-reduced POM with missing exclusions in concurrent build
> --
>
> Key: MSHADE-467
> URL: https://issues.apache.org/jira/browse/MSHADE-467
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.4.1, 3.5.0, 3.5.1
>Reporter: Alexander Kriegisch
>Priority: Major
>
> As discussed in [this maven-users
> thread|https://lists.apache.org/thread/ljdbh9h0lqs1qsf9o8bnm35mtr85y4vr],
> when running Maven builds for [this
> reproducer|https://github.com/stl543/shadeMT] concurrently, some dependency
> exclusions are missing from the generated dependency-reduced POMs. Run the
> reproducer like this:
> {code:none}
> $ mvn clean package -T 4 | grep 'BUILD SUCCESS' && find . -name
> "dependency-reduced-pom.xml" -exec bash -c 'cat $0 | grep exclu | wc -l ' {}
> \;
> [INFO] BUILD SUCCESS
> 12
> 12
> 12
> 12
> {code}
> When running with {{-T 1}}, however, the correct result is 20.
> This concurrency issue might have been introduced by the MSHADE-413 fix, but
> I am not sure.
> I have a local fix, synchronising on the injected mojo parameter
> {{MavenSession session}} in the lower section of
> {{ShadeMojo::rewriteDependencyReducedPomIfWeHaveReduction}}. There might be a
> better way to fix the problem, but I it leave that up to the PR reviewers to
> come up with one, if any.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPLUGIN-504) [regression] Goal prefix is required now
[ https://issues.apache.org/jira/browse/MPLUGIN-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17806517#comment-17806517 ] Romain Manni-Bucau commented on MPLUGIN-504: +1 to enhance the error message with a sample of the actual conf to inject in the plugin and keep the error to ensure any plugin owns its prefix, ideally the sample would log the heuristic goal prefix mentionning it can be customized if needed IMHO. > [regression] Goal prefix is required now > > > Key: MPLUGIN-504 > URL: https://issues.apache.org/jira/browse/MPLUGIN-504 > Project: Maven Plugin Tools > Issue Type: Bug >Reporter: Christoph Läubrich >Priority: Major > > With https://issues.apache.org/jira/browse/MPLUGIN-450 there was a regression > introduced that leads to previous working builds fail if the have not > configured a goalprefix, the error message is: > > You need to specify a goalPrefix as it can not be correctly computed > This has several issues: > # It does not explain why one "needs" a goalPrefix, nor what it is useful for > or why it can not be correctly computed. > # It is effectively a breaking change in a minor version increment > # The inital JIRA mentions that > a) in general, goal prefix is *+optional+*, but "good to have", and usually > is present. > b) we may want to have some option to turn off this feature > # Now it is required and there is no option to turn it off > Also the message is not true, the plugin has successfully computed a prefix > before without any issues: > * If the artifact ends with -maven-plugin as in my-cool-maven-plugin the > my-cool was chosen > * If the artifact ends with -plugin as in my-cool-plugin the my-cool was > chosen > * otherwise the full artifact if was chosen as a prefix as in my-cool the > my-cool was chosen > From a users point of view I don't see any problem or "disambiguates" with > this approach that justifies a breaking change here, anyone who is concerned > about not using this default can and already could choose a prefix and seem > to been fine with it for a long time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-463) Ensure checksum record file (summary fie) is sorted by artifact relative path and not checksum
Romain Manni-Bucau created MRESOLVER-463: Summary: Ensure checksum record file (summary fie) is sorted by artifact relative path and not checksum Key: MRESOLVER-463 URL: https://issues.apache.org/jira/browse/MRESOLVER-463 Project: Maven Resolver Issue Type: Task Affects Versions: 2.0.0-alpha-6 Reporter: Romain Manni-Bucau Goal is to navigate in the file manually more easily - tools don't need to navigate from vi anyway. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSOURCES-143) Can't create a source and test jar in Commons using commons-parent
[ https://issues.apache.org/jira/browse/MSOURCES-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804795#comment-17804795 ] Romain Manni-Bucau commented on MSOURCES-143: - [~rvesse] yes, if you check the output you see that attach-sources is done twice, one being explicit in the project pom, dropping it solves it and still enable to complete the release "as expected". (side note: for the setup using a local repo is easier than your github where we don't have perms - for good - so switched to scm:git:file:///tmp/repo to test). I think it is cause of default binding of source plugin and you don't override it but append your execution. Agree a help mojo could simplify the visualisation of the flows/pipelines too. > Can't create a source and test jar in Commons using commons-parent > -- > > Key: MSOURCES-143 > URL: https://issues.apache.org/jira/browse/MSOURCES-143 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Gary D. Gregory >Priority: Major > > Steps to reproduce: > # git clone https://gitbox.apache.org/repos/asf/commons-parent.git > # cd commons-parent > # git checkout 8d886ce8382f7a79f06d51a3afc386b8a37d0473 > # mvn clean install > # cd .. > # git clone https://gitbox.apache.org/repos/asf/commons-cli.git > # cd commons-cli > # git checkout 08f8c5034a8492be6db65b2086341c292489ee53 > # mvn clean package > [INFO] --- source:3.3.0:jar-no-fork (create-source-jar) @ commons-cli --- > [ERROR] We have duplicated artifacts attached. > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 15.233 s > [INFO] Finished at: 2023-08-15T15:39:45-04:00 > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork > (create-source-jar) on project commons-cli: Presumably you have configured > maven-source-plugn to execute twice times in your build. You have to > configure a classifier for at least on of them. -> [Help 1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSOURCES-143) Can't create a source and test jar in Commons using commons-parent
[ https://issues.apache.org/jira/browse/MSOURCES-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804731#comment-17804731 ] Romain Manni-Bucau commented on MSOURCES-143: - [~ggregory] well the only thing which is sure is that one artifact (plugin/execution) is ran twice, then cause can be due to multiple factors, either you consider spdx is buggy or that commons-parent is wrong - no judgement from my side on which one is the most accurate. But conclusion is the project "pipeline" must be reworked to sanitize that. Normally debug logs should give enough info about that, if not then we would have to enhance the attachements debug logs. > Can't create a source and test jar in Commons using commons-parent > -- > > Key: MSOURCES-143 > URL: https://issues.apache.org/jira/browse/MSOURCES-143 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Gary D. Gregory >Priority: Major > > Steps to reproduce: > # git clone https://gitbox.apache.org/repos/asf/commons-parent.git > # cd commons-parent > # git checkout 8d886ce8382f7a79f06d51a3afc386b8a37d0473 > # mvn clean install > # cd .. > # git clone https://gitbox.apache.org/repos/asf/commons-cli.git > # cd commons-cli > # git checkout 08f8c5034a8492be6db65b2086341c292489ee53 > # mvn clean package > [INFO] --- source:3.3.0:jar-no-fork (create-source-jar) @ commons-cli --- > [ERROR] We have duplicated artifacts attached. > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 15.233 s > [INFO] Finished at: 2023-08-15T15:39:45-04:00 > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork > (create-source-jar) on project commons-cli: Presumably you have configured > maven-source-plugn to execute twice times in your build. You have to > configure a classifier for at least on of them. -> [Help 1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSOURCES-143) Can't create a source and test jar in Commons using commons-parent
[ https://issues.apache.org/jira/browse/MSOURCES-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804702#comment-17804702 ] Romain Manni-Bucau commented on MSOURCES-143: - [~rvesse] probably linked to the fact the bug is not on maven plugin side but the project setup, if you look your build output you will see multiple executions attaching the same binary for sources which was a bug in earlier versions, using it is no more supported (for goods) but can break builds which were abusing this bug. You can see it earlier binding source plugin to an earlier stage - this is mainly dependent your project setup. So while I understand it is bothering it also show you have a bug in your maven usage so it is good. Side note: you'll get the same kind of validation with maven 4 upgrade which will start to fail with missing enabled profiles instead of ignoring it and all that for a better usage and enforce the control of the build instead of faking build was fine when it was not. > Can't create a source and test jar in Commons using commons-parent > -- > > Key: MSOURCES-143 > URL: https://issues.apache.org/jira/browse/MSOURCES-143 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Gary D. Gregory >Priority: Major > > Steps to reproduce: > # git clone https://gitbox.apache.org/repos/asf/commons-parent.git > # cd commons-parent > # git checkout 8d886ce8382f7a79f06d51a3afc386b8a37d0473 > # mvn clean install > # cd .. > # git clone https://gitbox.apache.org/repos/asf/commons-cli.git > # cd commons-cli > # git checkout 08f8c5034a8492be6db65b2086341c292489ee53 > # mvn clean package > [INFO] --- source:3.3.0:jar-no-fork (create-source-jar) @ commons-cli --- > [ERROR] We have duplicated artifacts attached. > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 15.233 s > [INFO] Finished at: 2023-08-15T15:39:45-04:00 > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork > (create-source-jar) on project commons-cli: Presumably you have configured > maven-source-plugn to execute twice times in your build. You have to > configure a classifier for at least on of them. -> [Help 1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSOURCES-143) Can't create a source and test jar in Commons using commons-parent
[ https://issues.apache.org/jira/browse/MSOURCES-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755662#comment-17755662 ] Romain Manni-Bucau commented on MSOURCES-143: - [~ggregory] was not really "do whatever fixes the problem" was more "whatever you judge right" - on my side I find commons-parent way too fat and overkill and I don't know spdx plugin enough so I would be keen to drop most of the first and make spdx not rerun what is configured in cli but it can not be the best for the project. You probably don't do something unusual but you have a legacy which was hidden and is not shown - which is good on maven side I think. > Can't create a source and test jar in Commons using commons-parent > -- > > Key: MSOURCES-143 > URL: https://issues.apache.org/jira/browse/MSOURCES-143 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Gary D. Gregory >Priority: Major > > Steps to reproduce: > # git clone https://gitbox.apache.org/repos/asf/commons-parent.git > # cd commons-parent > # git checkout 8d886ce8382f7a79f06d51a3afc386b8a37d0473 > # mvn clean install > # cd .. > # git clone https://gitbox.apache.org/repos/asf/commons-cli.git > # cd commons-cli > # git checkout 08f8c5034a8492be6db65b2086341c292489ee53 > # mvn clean package > [INFO] --- source:3.3.0:jar-no-fork (create-source-jar) @ commons-cli --- > [ERROR] We have duplicated artifacts attached. > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 15.233 s > [INFO] Finished at: 2023-08-15T15:39:45-04:00 > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork > (create-source-jar) on project commons-cli: Presumably you have configured > maven-source-plugn to execute twice times in your build. You have to > configure a classifier for at least on of them. -> [Help 1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSOURCES-143) Can't create a source and test jar in Commons using commons-parent
[ https://issues.apache.org/jira/browse/MSOURCES-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17755657#comment-17755657 ] Romain Manni-Bucau commented on MSOURCES-143: - [~ggregory] spdx or parent pom or cli pom.xml, whatever will make the error case no more hit avoiding rebuild of the same mvn mojo execution > Can't create a source and test jar in Commons using commons-parent > -- > > Key: MSOURCES-143 > URL: https://issues.apache.org/jira/browse/MSOURCES-143 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Gary D. Gregory >Priority: Major > > Steps to reproduce: > # git clone https://gitbox.apache.org/repos/asf/commons-parent.git > # cd commons-parent > # git checkout 8d886ce8382f7a79f06d51a3afc386b8a37d0473 > # mvn clean install > # cd .. > # git clone https://gitbox.apache.org/repos/asf/commons-cli.git > # cd commons-cli > # git checkout 08f8c5034a8492be6db65b2086341c292489ee53 > # mvn clean package > [INFO] --- source:3.3.0:jar-no-fork (create-source-jar) @ commons-cli --- > [ERROR] We have duplicated artifacts attached. > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 15.233 s > [INFO] Finished at: 2023-08-15T15:39:45-04:00 > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork > (create-source-jar) on project commons-cli: Presumably you have configured > maven-source-plugn to execute twice times in your build. You have to > configure a classifier for at least on of them. -> [Help 1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSOURCES-143) Can't create a source and test jar in Commons using commons-parent
[ https://issues.apache.org/jira/browse/MSOURCES-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754899#comment-17754899 ] Romain Manni-Bucau commented on MSOURCES-143: - Can't reproduce too (even tested with maven 4 and 3.6), > Can't create a source and test jar in Commons using commons-parent > -- > > Key: MSOURCES-143 > URL: https://issues.apache.org/jira/browse/MSOURCES-143 > Project: Maven Source Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: Gary D. Gregory >Priority: Major > > Steps to reproduce: > # git clone https://gitbox.apache.org/repos/asf/commons-parent.git > # cd commons-parent > # git checkout 8d886ce8382f7a79f06d51a3afc386b8a37d0473 > # mvn clean install > # cd .. > # git clone https://gitbox.apache.org/repos/asf/commons-cli.git > # cd commons-cli > # git checkout 08f8c5034a8492be6db65b2086341c292489ee53 > # mvn clean package > [INFO] --- source:3.3.0:jar-no-fork (create-source-jar) @ commons-cli --- > [ERROR] We have duplicated artifacts attached. > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 15.233 s > [INFO] Finished at: 2023-08-15T15:39:45-04:00 > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-source-plugin:3.3.0:jar-no-fork > (create-source-jar) on project commons-cli: Presumably you have configured > maven-source-plugn to execute twice times in your build. You have to > configure a classifier for at least on of them. -> [Help 1] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7838) Local repository breaks exec plugin
[
https://issues.apache.org/jira/browse/MNG-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741139#comment-17741139
]
Romain Manni-Bucau commented on MNG-7838:
-
Right but maven set of sources is known (repos), so guess we should check all
local ones at least - maybe just all since remote ones will be ignored with the
update policy. Don't think it is what we do, we just check the other module
target which misses the case I mention. Likely not critical but a bit weird if
you get an artifact installed in another way. From my window it looks like
maven does not respects maven or that end user must understand the internals,
this is why I'm a bit mixed about this issue.
> Local repository breaks exec plugin
> ---
>
> Key: MNG-7838
> URL: https://issues.apache.org/jira/browse/MNG-7838
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
>Reporter: Romain Manni-Bucau
>Assignee: Guillaume Nodet
>Priority: Major
>
> Didn't fully investigate but in a multimodule project with modules A and B
> and A used in B with exec plugin (exec:java, add project deps =true), doing
> `cd A && mvn install && cd ../B && mvn package exec:java` keeps using an
> outdated version of A whereas it shouldnt.
>
> here some logs when replacing second command by one from the root module:
>
> {code:java}
> [INFO] --- exec:3.0.0:java (generate-model) @ B ---
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [INFOS]ㅤGenerated 73 files in
> /opt/rmannibucau/dev/app/B/target/generated-sources/models (some.xsd)
> [INFO] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7838) Local repository breaks exec plugin
[
https://issues.apache.org/jira/browse/MNG-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741100#comment-17741100
]
Romain Manni-Bucau commented on MNG-7838:
-
Issue is when it finds one probably. Guess it can be ok we shouldnt mix version
when doing that but we can also take some more time to think if we should
enhance the "dirty checking" or not.
> Local repository breaks exec plugin
> ---
>
> Key: MNG-7838
> URL: https://issues.apache.org/jira/browse/MNG-7838
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
>Reporter: Romain Manni-Bucau
>Assignee: Guillaume Nodet
>Priority: Major
>
> Didn't fully investigate but in a multimodule project with modules A and B
> and A used in B with exec plugin (exec:java, add project deps =true), doing
> `cd A && mvn install && cd ../B && mvn package exec:java` keeps using an
> outdated version of A whereas it shouldnt.
>
> here some logs when replacing second command by one from the root module:
>
> {code:java}
> [INFO] --- exec:3.0.0:java (generate-model) @ B ---
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [INFOS]ㅤGenerated 73 files in
> /opt/rmannibucau/dev/app/B/target/generated-sources/models (some.xsd)
> [INFO] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7838) Local repository breaks exec plugin
[
https://issues.apache.org/jira/browse/MNG-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17741068#comment-17741068
]
Romain Manni-Bucau commented on MNG-7838:
-
[~gnodet] think I narrowed something which can be half on my side half on maven
side: seems I was doing the "install*s*" in 2 consoles with different env (one
with maven 3 and one with maven 4), but wonder if the
`isPackagedArtifactUpToDate` should also check the local m2 (skipping remotes)
and not only in project artifacts which are just a partial view of the
"up-to-date" state.
> Local repository breaks exec plugin
> ---
>
> Key: MNG-7838
> URL: https://issues.apache.org/jira/browse/MNG-7838
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-5
>Reporter: Romain Manni-Bucau
>Assignee: Guillaume Nodet
>Priority: Major
>
> Didn't fully investigate but in a multimodule project with modules A and B
> and A used in B with exec plugin (exec:java, add project deps =true), doing
> `cd A && mvn install && cd ../B && mvn package exec:java` keeps using an
> outdated version of A whereas it shouldnt.
>
> here some logs when replacing second command by one from the root module:
>
> {code:java}
> [INFO] --- exec:3.0.0:java (generate-model) @ B ---
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [WARNING] File
> 'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is
> more recent than the packaged artifact for 'A', please run a full `mvn
> package` build
> [INFOS]ㅤGenerated 73 files in
> /opt/rmannibucau/dev/app/B/target/generated-sources/models (some.xsd)
> [INFO] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7839) Plugin v4 API should ensure class realm are fully isolated from maven.core/extensions realms (classes+resources)
Romain Manni-Bucau created MNG-7839: --- Summary: Plugin v4 API should ensure class realm are fully isolated from maven.core/extensions realms (classes+resources) Key: MNG-7839 URL: https://issues.apache.org/jira/browse/MNG-7839 Project: Maven Issue Type: Task Affects Versions: 4.0.0-alpha-7 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7839) Plugin v4 API should ensure class realm are fully isolated from maven.core/extensions realms (classes+resources)
[ https://issues.apache.org/jira/browse/MNG-7839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated MNG-7839: Description: idea is to let mojo do their things and just import the minimal API surface (rest of maven being isolated). Ideally it could be configured in mojo descriptor but minimum is full isolation to avoid issues we hit today. > Plugin v4 API should ensure class realm are fully isolated from > maven.core/extensions realms (classes+resources) > > > Key: MNG-7839 > URL: https://issues.apache.org/jira/browse/MNG-7839 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-7 >Reporter: Romain Manni-Bucau >Priority: Major > > idea is to let mojo do their things and just import the minimal API surface > (rest of maven being isolated). Ideally it could be configured in mojo > descriptor but minimum is full isolation to avoid issues we hit today. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7838) Local repository breaks exec plugin
Romain Manni-Bucau created MNG-7838:
---
Summary: Local repository breaks exec plugin
Key: MNG-7838
URL: https://issues.apache.org/jira/browse/MNG-7838
Project: Maven
Issue Type: Bug
Affects Versions: 4.0.0-alpha-5
Reporter: Romain Manni-Bucau
Didn't fully investigate but in a multimodule project with modules A and B and
A used in B with exec plugin (exec:java, add project deps =true), doing `cd A
&& mvn install && cd ../B && mvn package exec:java` keeps using an outdated
version of A whereas it shouldnt.
here some logs when replacing second command by one from the root module:
{code:java}
[INFO] --- exec:3.0.0:java (generate-model) @ B ---
[WARNING] File
'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is more
recent than the packaged artifact for 'A', please run a full `mvn package` build
[WARNING] File
'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is more
recent than the packaged artifact for 'A', please run a full `mvn package` build
[WARNING] File
'app/A/target/classes/com/app/tools/soap/GenerateLightModels$Elt.class' is more
recent than the packaged artifact for 'A', please run a full `mvn package` build
[INFOS]ㅤGenerated 73 files in
/opt/rmannibucau/dev/app/B/target/generated-sources/models (some.xsd)
[INFO] {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7831) Install plugin fails with a NPE when rewriting the pom containing escaped chars
[
https://issues.apache.org/jira/browse/MNG-7831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17739404#comment-17739404
]
Romain Manni-Bucau commented on MNG-7831:
-
[~michael-o] seems so since master got a fix, mainly opened it for stack
tracing but I don't have the perms to close it as fixed on alpha8
> Install plugin fails with a NPE when rewriting the pom containing escaped
> chars
> ---
>
> Key: MNG-7831
> URL: https://issues.apache.org/jira/browse/MNG-7831
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-7
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> {code:java}
> Caused by: java.lang.NullPointerException: Cannot invoke "String.length()"
> because "str" is null
> at java.io.Writer.write (Writer.java:249)
> at org.codehaus.plexus.util.xml.pull.MXSerializer.entityRef
> (MXSerializer.java:806)
> at org.apache.maven.model.transform.pull.XmlUtils.writeDocument
> (XmlUtils.java:81)
> at org.apache.maven.model.transform.pull.XmlUtils.writeDocument
> (XmlUtils.java:40)
> at
> org.apache.maven.internal.transformation.ConsumerPomArtifactTransformer.transform
> (ConsumerPomArtifactTransformer.java:195)
> at
> org.apache.maven.internal.transformation.ConsumerPomArtifactTransformer$ConsumerPomArtifact.lambda$transformer$1
> (ConsumerPomArtifactTransformer.java:175)
> at org.apache.maven.internal.transformation.OnChangeTransformer.mayUpdate
> (OnChangeTransformer.java:93)
> at org.apache.maven.internal.transformation.OnChangeTransformer.get
> (OnChangeTransformer.java:72)
> at org.apache.maven.internal.transformation.TransformedArtifact.getFile
> (TransformedArtifact.java:76)
> at org.apache.maven.RepositoryUtils.toArtifact (RepositoryUtils.java:159)
> at org.apache.maven.plugins.install.InstallMojo.processProject
> (InstallMojo.java:227)
> at org.apache.maven.plugins.install.InstallMojo.execute
> (InstallMojo.java:127)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:143)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
> (MojoExecutor.java:333)
> at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
> (MojoExecutor.java:321)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:217)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:178)
> at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
> (MojoExecutor.java:77)
> at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
> (MojoExecutor.java:166)
> at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
> (DefaultMojosExecutionStrategy.java:39)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:163)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:114)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:60)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:132)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:313)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:228)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:153)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:943)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:282)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:225)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:347)
> {code}
> maven install pluin: 3.1.1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7831) Install plugin fails with a NPE when rewriting the pom containing escaped chars
Romain Manni-Bucau created MNG-7831:
---
Summary: Install plugin fails with a NPE when rewriting the pom
containing escaped chars
Key: MNG-7831
URL: https://issues.apache.org/jira/browse/MNG-7831
Project: Maven
Issue Type: Bug
Components: Core
Affects Versions: 4.0.0-alpha-7
Reporter: Romain Manni-Bucau
{code:java}
Caused by: java.lang.NullPointerException: Cannot invoke "String.length()"
because "str" is null
at java.io.Writer.write (Writer.java:249)
at org.codehaus.plexus.util.xml.pull.MXSerializer.entityRef
(MXSerializer.java:806)
at org.apache.maven.model.transform.pull.XmlUtils.writeDocument
(XmlUtils.java:81)
at org.apache.maven.model.transform.pull.XmlUtils.writeDocument
(XmlUtils.java:40)
at
org.apache.maven.internal.transformation.ConsumerPomArtifactTransformer.transform
(ConsumerPomArtifactTransformer.java:195)
at
org.apache.maven.internal.transformation.ConsumerPomArtifactTransformer$ConsumerPomArtifact.lambda$transformer$1
(ConsumerPomArtifactTransformer.java:175)
at org.apache.maven.internal.transformation.OnChangeTransformer.mayUpdate
(OnChangeTransformer.java:93)
at org.apache.maven.internal.transformation.OnChangeTransformer.get
(OnChangeTransformer.java:72)
at org.apache.maven.internal.transformation.TransformedArtifact.getFile
(TransformedArtifact.java:76)
at org.apache.maven.RepositoryUtils.toArtifact (RepositoryUtils.java:159)
at org.apache.maven.plugins.install.InstallMojo.processProject
(InstallMojo.java:227)
at org.apache.maven.plugins.install.InstallMojo.execute
(InstallMojo.java:127)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:143)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2
(MojoExecutor.java:333)
at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute
(MojoExecutor.java:321)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:217)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:178)
at org.apache.maven.lifecycle.internal.MojoExecutor.access$000
(MojoExecutor.java:77)
at org.apache.maven.lifecycle.internal.MojoExecutor$1.run
(MojoExecutor.java:166)
at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute
(DefaultMojosExecutionStrategy.java:39)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:163)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:114)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:60)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:132)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:313)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:228)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:943)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:77)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:568)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:347)
{code}
maven install pluin: 3.1.1
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7827) Fix org.apache.maven.plugin.logging.Log deprecation message and AbstractMojo#getLog fallback
Romain Manni-Bucau created MNG-7827: --- Summary: Fix org.apache.maven.plugin.logging.Log deprecation message and AbstractMojo#getLog fallback Key: MNG-7827 URL: https://issues.apache.org/jira/browse/MNG-7827 Project: Maven Issue Type: Improvement Components: Plugin API Affects Versions: 4.0.0-alpha-7 Reporter: Romain Manni-Bucau In maven 4 an official Log API was created and using SLF4J as primary logging solution is not recommended nor the official way so javadoc and impl should be aligned to reflcet that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7808) Remove warnings of undefined plugin versions
[ https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17734012#comment-17734012 ] Romain Manni-Bucau commented on MNG-7808: - [~sjaranowski] 3.9.3 is ok for me except that it was not done on master first and backported so we still have the issue project wide. > Remove warnings of undefined plugin versions > > > Key: MNG-7808 > URL: https://issues.apache.org/jira/browse/MNG-7808 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Reporter: Benjamin Marwell >Priority: Major > > h2. Actual behaviour > Maven issues warnings about undefined plugin versions when not needed > h2. Expected behaviour > Maven should not issue warnings about undefined plugin versions early in a > project build. > > h2. Rationale > The release plugin will be modified to reject releases of projects which are > not defining all plugin versions: [MRELEASE-1130] Reject release of project > containing undefined plugin versions - ASF JIRA (apache.org) > > Once that is done, we can remove the warnings from core: > 1.) There should be as few as possible warnings OOTB on new maven projects > 2.) It is not really important for local builds to define plugin versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7808) Remove warnings of undefined plugin versions
[
https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733933#comment-17733933
]
Romain Manni-Bucau commented on MNG-7808:
-
[~hboutemy] yes, sadly we have not only 2 behaviors on that aspect (raw output:
https://gist.github.com/rmannibucau/fc07a89d554764d2826af2ff55b3a42d):
* old versions (tested on 3.8.6 in ^^) -> nothing (as expected I'd say)
* last v4 (at the beginning of the build):
{code:java}
[WARNING] Version not locked for default bindings plugins
[maven-surefire-plugin, maven-jar-plugin], you should define versions in
pluginManagement section of your pom.xml or parent {code}
* 3.9.2 (after the build, multiple lines)
{code:java}
[WARNING] [WARNING] Plugin validation issues were detected in 2
plugin(s)[WARNING] [WARNING] *
org.apache.maven.plugins:maven-resources-plugin:3.2.0[WARNING] *
org.apache.maven.plugins:maven-compiler-plugin:3.10.1[WARNING] [WARNING] For
more or less details, use 'maven.plugin.validation' property with one of the
values (case insensitive): [BRIEF, DEFAULT, VERBOSE][WARNING] {code}
> Remove warnings of undefined plugin versions
>
>
> Key: MNG-7808
> URL: https://issues.apache.org/jira/browse/MNG-7808
> Project: Maven
> Issue Type: Improvement
> Components: Core, Logging
>Reporter: Benjamin Marwell
>Priority: Major
>
> h2. Actual behaviour
> Maven issues warnings about undefined plugin versions when not needed
> h2. Expected behaviour
> Maven should not issue warnings about undefined plugin versions early in a
> project build.
>
> h2. Rationale
> The release plugin will be modified to reject releases of projects which are
> not defining all plugin versions: [MRELEASE-1130] Reject release of project
> containing undefined plugin versions - ASF JIRA (apache.org)
>
> Once that is done, we can remove the warnings from core:
> 1.) There should be as few as possible warnings OOTB on new maven projects
> 2.) It is not really important for local builds to define plugin versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7808) Remove warnings of undefined plugin versions
[
https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733913#comment-17733913
]
Romain Manni-Bucau commented on MNG-7808:
-
[~hboutemy] gave multiple examples in the related threads but if you want a
few:
{code:java}
mvn archetype:generate \
-DarchetypeGroupId=org.apache.camel.archetypes \
-DarchetypeArtifactId=camel-archetype-java \
-DarchetypeVersion=3.20.0 {code}
You will say me that camel must pin versions and as maven core committer, you
will also recommend to not pin default plugins to ensure it works with the most
maven versions since some archetypes are not about a specific plugin but just
building a jar or war (= 100% use maven plugins so best advice is to not bound
the pom to a version).
As explained, it is more than fine to fail if we dont support a config and we
broke a plugin for whatever reason, it is not acceptable to warn for something
we are ourself responsible (we own plugin and bind them to releases so it is
intended to not be pinned).
Last: if you want reproducibility you are bound to a mvn and java version at
build time (--release does not make it better, just more tolerance) so in such
a case, versions are locked by design so forcing the locking is overall
negative for maven and does not enhance the reproducibility - only goal AFAIK -
so we don't have to keep it.
Side note: indeed you can get the same issue with pure maven archtectype until
you bind maven version to archtetype versions which is, here again, not what we
do today nor what we want probably since it breaks consumer/producer contract.
Hope it is clearer.
> Remove warnings of undefined plugin versions
>
>
> Key: MNG-7808
> URL: https://issues.apache.org/jira/browse/MNG-7808
> Project: Maven
> Issue Type: Improvement
> Components: Core, Logging
>Reporter: Benjamin Marwell
>Priority: Major
>
> h2. Actual behaviour
> Maven issues warnings about undefined plugin versions when not needed
> h2. Expected behaviour
> Maven should not issue warnings about undefined plugin versions early in a
> project build.
>
> h2. Rationale
> The release plugin will be modified to reject releases of projects which are
> not defining all plugin versions: [MRELEASE-1130] Reject release of project
> containing undefined plugin versions - ASF JIRA (apache.org)
>
> Once that is done, we can remove the warnings from core:
> 1.) There should be as few as possible warnings OOTB on new maven projects
> 2.) It is not really important for local builds to define plugin versions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7808) Remove warnings of undefined plugin versions
[ https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733870#comment-17733870 ] Romain Manni-Bucau commented on MNG-7808: - Let's make it simple: warning about defaults means maven does not support defaults anymore so is no more about convention which I think is wrong, still. > Remove warnings of undefined plugin versions > > > Key: MNG-7808 > URL: https://issues.apache.org/jira/browse/MNG-7808 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Reporter: Benjamin Marwell >Priority: Major > > h2. Actual behaviour > Maven issues warnings about undefined plugin versions when not needed > h2. Expected behaviour > Maven should not issue warnings about undefined plugin versions early in a > project build. > > h2. Rationale > The release plugin will be modified to reject releases of projects which are > not defining all plugin versions: [MRELEASE-1130] Reject release of project > containing undefined plugin versions - ASF JIRA (apache.org) > > Once that is done, we can remove the warnings from core: > 1.) There should be as few as possible warnings OOTB on new maven projects > 2.) It is not really important for local builds to define plugin versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7808) Remove warnings of undefined plugin versions
[ https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733763#comment-17733763 ] Romain Manni-Bucau commented on MNG-7808: - [~hboutemy] do you know a lot of archetypes not triggering these warnings? Most will do and as an archetype writer you do *not* want to put versions there but just override what maven provides OOTB to limit the maintainance (it is how maven was designed after all). So yes, we shouted in our foot. You are right about 3.8.8 and 3.9.3, this is an intended instability by design and assume you pin the version with 3.8.8, you don't know if it will work with 3.9.3 so you didn't get anything pinning, you just ensure it will not work faster cause plugins tends to be more stable accross versions when doing upgrades than pinning versions which can have internal breakages. So overall we should probably just keep our philosophy and work OOTB without any side effects which don't enhance the user stability but keep it at status quo with the same downside than not having them. > Remove warnings of undefined plugin versions > > > Key: MNG-7808 > URL: https://issues.apache.org/jira/browse/MNG-7808 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Reporter: Benjamin Marwell >Priority: Major > > h2. Actual behaviour > Maven issues warnings about undefined plugin versions when not needed > h2. Expected behaviour > Maven should not issue warnings about undefined plugin versions early in a > project build. > > h2. Rationale > The release plugin will be modified to reject releases of projects which are > not defining all plugin versions: [MRELEASE-1130] Reject release of project > containing undefined plugin versions - ASF JIRA (apache.org) > > Once that is done, we can remove the warnings from core: > 1.) There should be as few as possible warnings OOTB on new maven projects > 2.) It is not really important for local builds to define plugin versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7808) Remove warnings of undefined plugin versions
[ https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17732894#comment-17732894 ] Romain Manni-Bucau commented on MNG-7808: - [~hboutemy] well, understand the playing side but if you think "maven" you realize this just breaks maven conception so people speaking of "years ago" on the list will probably care ;). Joke aside this means that archetypes are broken by design and literally that maven is no more convention over configuration so that default lifecycles and packagings don't make sense anymore, we are just one step ahead of being back to ant which is not something I find consistent with maven nor nice for end user. Key point for me being it does *not* help anything regarding the reproducibility cause reproducibility has as prerequisite maven and java locked versions (and distribution for java) so if you are under a particular maven and java version the default versions are locked by nature. So this is really just some annoyance for end user IMHO we can't justify. > Remove warnings of undefined plugin versions > > > Key: MNG-7808 > URL: https://issues.apache.org/jira/browse/MNG-7808 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Reporter: Benjamin Marwell >Priority: Major > > h2. Actual behaviour > Maven issues warnings about undefined plugin versions when not needed > h2. Expected behaviour > Maven should not issue warnings about undefined plugin versions early in a > project build. > > h2. Rationale > The release plugin will be modified to reject releases of projects which are > not defining all plugin versions: [MRELEASE-1130] Reject release of project > containing undefined plugin versions - ASF JIRA (apache.org) > > Once that is done, we can remove the warnings from core: > 1.) There should be as few as possible warnings OOTB on new maven projects > 2.) It is not really important for local builds to define plugin versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7808) Remove warnings of undefined plugin versions
[ https://issues.apache.org/jira/browse/MNG-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17731537#comment-17731537 ] Romain Manni-Bucau commented on MNG-7808: - [~hboutemy] maven is about convention over configuration so `git clone && mvn install` must work without warnings, this got broken in last releases. This ticket is about fixing and respecting our core values. > Remove warnings of undefined plugin versions > > > Key: MNG-7808 > URL: https://issues.apache.org/jira/browse/MNG-7808 > Project: Maven > Issue Type: Improvement > Components: Core, Logging >Reporter: Benjamin Marwell >Priority: Major > > h2. Actual behaviour > Maven issues warnings about undefined plugin versions when not needed > h2. Expected behaviour > Maven should not issue warnings about undefined plugin versions early in a > project build. > > h2. Rationale > The release plugin will be modified to reject releases of projects which are > not defining all plugin versions: [MRELEASE-1130] Reject release of project > containing undefined plugin versions - ASF JIRA (apache.org) > > Once that is done, we can remove the warnings from core: > 1.) There should be as few as possible warnings OOTB on new maven projects > 2.) It is not really important for local builds to define plugin versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MDEP-845) list mojo does not decoralate output file content from log configuration so colors are controlled by the build and not the mojo
Romain Manni-Bucau created MDEP-845: --- Summary: list mojo does not decoralate output file content from log configuration so colors are controlled by the build and not the mojo Key: MDEP-845 URL: https://issues.apache.org/jira/browse/MDEP-845 Project: Maven Dependency Plugin Issue Type: Improvement Affects Versions: 3.5.0 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7724) Don't log warnings when runtime is not broken (slf4j integrations)
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697985#comment-17697985 ] Romain Manni-Bucau commented on MNG-7724: - > Warnings are warnings and not errors for a reason. Does not change the fact the log is at a bothering level (warning = call for action but does not block, whereas error = you failed). It is still wrong and in such cases it is fair to ask the project emitting it to fix its logic instead of just configuring an ignore pattern which can lead to ignoring an actual action message. > Also we shouldn't call ex.printStackTrace in > Slf4jConfigurationFactory.getConfigurationFactory. The catch block maybe > should log a warning (though that's a potentially different warning than > we're logging now, and more actionable). Or perhaps this should be at debug > level? But UnsupportedSlf4jBindingConfiguration should not log anything. Was what was doing my previous PR and logging in info the fact the maven integration was not there for the case there was no exception but this option was rejected. Technically speaking the exception logging must *not* use a logger since when it happens it can mean the logging setup is broken. > Don't log warnings when runtime is not broken (slf4j integrations) > -- > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7724) Don't log warnings when runtime is not broken (slf4j integrations)
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697929#comment-17697929 ] Romain Manni-Bucau commented on MNG-7724: - > One more time: if a project chooses to fail on *warnings* that's there issue, > not ours. We should not adjust our code to suit their idiosyncratic code > bureaucracy. > It sounds like maybe this shouldn't log at all. That is, this issue is simply > not a problem. The code runs fine. If so, turn it off completely. But if it > is a problem, then make it a warning, not info. You just ignore the context, as explained in the issue there are multiple contexts and therefore outcome/expectations: # I wouldn't call users idots because they don't do like you do (it is often the opposite actually, we learn from users), technically speaking out fail-on-severity is likely the most idiot part of the solution ;) # it is a warning if maven intends to use a predefined integration but fails to do so # it is an info if maven has no integration - but fail-on-severity will be disabled which is intended when doing this kind of setup # a warning is only relevant if you can do something about it and here it implies coding which is not satisfying for any CI solution - the PR solves that # Also strongly disagree that failling on warning is an user issue and not a maven one, you can check out some project even encouraging it like...maven (fail-on-severity is exactly that case) so no, your statement is likely wrong or maven toggle is wrong, I'm fine with both options but we need a solution anyway. So overall I think the PR enables all the mentionned use cases smoothly even if I agree with your the slf4j binding integration is likely wrong from a design standpoint (think of the case where slf4j falls back on noop, the warning will not be seen at all for ex). > Don't log warnings when runtime is not broken (slf4j integrations) > -- > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7724) Don't log warnings when runtime is not broken (slf4j integrations)
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated MNG-7724: Summary: Don't log warnings when runtime is not broken (slf4j integrations) (was: Slf4jConfigurationFactory should use info level when there is no exception and the logger type is unknown) > Don't log warnings when runtime is not broken (slf4j integrations) > -- > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7724) Slf4jConfigurationFactory should use info level when there is no exception and the logger type is unknown
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697798#comment-17697798 ] Romain Manni-Bucau edited comment on MNG-7724 at 3/8/23 9:33 AM: - No guys, this means maven does not allow to use slf4j bindings without maven integration. What is the rational then and the key feature we have in maven to justify it? Only `fail-on-severity` flag which is almost never used (keep in mind this is often a transversal feature instead of a maven specific one in the usage) so we log warnings (which must be considered as error/something needing attention by any user). You can also note that in MavenCli this handling is specific and warning are only issues if it is used. So if you reject this use case you enforce any slf4j binding to integrate with maven for a rare feature, I think this is wrong and going against the ecosystem and the slf4j choice, minimum we can do is to reduce the logging level to say "hey there a small toggle which will be ignored but your build is not at risk". It has a lot of downside depending the log setup - we don't control by contract, i put a few examples in the description but there are more. So really think we should do something about that. I will rework the PR to try to propose a few more precise options but closing it is against users and usability of maven so please reopen the issue - i dont have enough karma. edit: updated the PR with another approach was (Author: romain.manni-bucau): No guys, this means maven does not allow to use slf4j bindings without maven integration. What is the rational then and the key feature we have in maven to justify it? Only `fail-on-severity` flag which is almost never used (keep in mind this is often a transversal feature instead of a maven specific one in the usage) so we log warnings (which must be considered as error/something needing attention by any user). You can also note that in MavenCli this handling is specific and warning are only issues if it is used. So if you reject this use case you enforce any slf4j binding to integrate with maven for a rare feature, I think this is wrong and going against the ecosystem and the slf4j choice, minimum we can do is to reduce the logging level to say "hey there a small toggle which will be ignored but your build is not at risk". It has a lot of downside depending the log setup - we don't control by contract, i put a few examples in the description but there are more. So really think we should do something about that. I will rework the PR to try to propose a few more precise options but closing it is against users and usability of maven so please reopen the issue - i dont have enough karma. > Slf4jConfigurationFactory should use info level when there is no exception > and the logger type is unknown > - > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7724) Slf4jConfigurationFactory should use info level when there is no exception and the logger type is unknown
[ https://issues.apache.org/jira/browse/MNG-7724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17697798#comment-17697798 ] Romain Manni-Bucau commented on MNG-7724: - No guys, this means maven does not allow to use slf4j bindings without maven integration. What is the rational then and the key feature we have in maven to justify it? Only `fail-on-severity` flag which is almost never used (keep in mind this is often a transversal feature instead of a maven specific one in the usage) so we log warnings (which must be considered as error/something needing attention by any user). You can also note that in MavenCli this handling is specific and warning are only issues if it is used. So if you reject this use case you enforce any slf4j binding to integrate with maven for a rare feature, I think this is wrong and going against the ecosystem and the slf4j choice, minimum we can do is to reduce the logging level to say "hey there a small toggle which will be ignored but your build is not at risk". It has a lot of downside depending the log setup - we don't control by contract, i put a few examples in the description but there are more. So really think we should do something about that. I will rework the PR to try to propose a few more precise options but closing it is against users and usability of maven so please reopen the issue - i dont have enough karma. > Slf4jConfigurationFactory should use info level when there is no exception > and the logger type is unknown > - > > Key: MNG-7724 > URL: https://issues.apache.org/jira/browse/MNG-7724 > Project: Maven > Issue Type: Improvement >Affects Versions: 4.0.0-alpha-4 >Reporter: Romain Manni-Bucau >Priority: Minor > > As of now if we change the SLF4J bindings maven will issue warnings because a > few features are disabled but due to the nature of switching these bindings > it is highly likely it is intended and therefore the warning are misleading > more than helping. > The solution can be to log a warning if a configured factory fails to load > but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7724) Slf4jConfigurationFactory should use info level when there is no exception and the logger type is unknown
Romain Manni-Bucau created MNG-7724: --- Summary: Slf4jConfigurationFactory should use info level when there is no exception and the logger type is unknown Key: MNG-7724 URL: https://issues.apache.org/jira/browse/MNG-7724 Project: Maven Issue Type: Improvement Affects Versions: 4.0.0-alpha-4 Reporter: Romain Manni-Bucau As of now if we change the SLF4J bindings maven will issue warnings because a few features are disabled but due to the nature of switching these bindings it is highly likely it is intended and therefore the warning are misleading more than helping. The solution can be to log a warning if a configured factory fails to load but just log info when it succeeds. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7563) User properties now override model properties in dependencies
[
https://issues.apache.org/jira/browse/MNG-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17646989#comment-17646989
]
Romain Manni-Bucau commented on MNG-7563:
-
Hi,
Think we should normalise the behavior to always enable to override a value by
the most specific setting, ie system properties in our case. So model would be
overriden by user props which is overriden by system props.
The rational is double:
* an user should ultimately control what he builds so more specific is the
setting more it overrides others (as in most system actually)
* if you to try to lock the value with the definition, then you fall in the
trap to force the end user to not set the value and force it to be required at
the highest level you want (user or system props) which is a big anti-pattern
because you can't build without specific settings anymore.
> User properties now override model properties in dependencies
> -
>
> Key: MNG-7563
> URL: https://issues.apache.org/jira/browse/MNG-7563
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, POM
>Affects Versions: 3.8.5, 3.8.6
>Reporter: Hervé Guillemet
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: poms.zip
>
>
> An important change has been introduced in 3.8.5 that breaks some existing
> builds: Java system properties now take precedence over default values of
> user properties in dependency POMs. This look like a bug since it's now easy
> to affect dependency behaviors with system properties, a practice that has
> been discouraged. But maybe do you consider this as a new feature ?
> As an example, 3 poms are attached to this ticket.
> After installing projects b and c, building project a with:
> {{mvn package -Ddep=x}}
> used to succeed until 3.8.4 (-D is ignored) but throws error with 3.8.5 and
> 3.8.6 (-D override the default).
> Note that without the setting of the default value for property {{dep}} in
> project b, the build fails with any version of Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7620) Rework how "exportedArtifacts" works
[
https://issues.apache.org/jira/browse/MNG-7620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644367#comment-17644367
]
Romain Manni-Bucau commented on MNG-7620:
-
Today exports are quite wrong from a design perspective and we leak way too
much so v4 will clean up things and using extensions you are able to contribute
artifacts in the same realm which will make the runtime more consistent and
less error prone.
Using another classrealm intermediate can be not bad but then you will not be
in core which is likely desired sometimes so let's keep it simple and enrich
ext classrealm only and expose or not the libs to mojos.
> Rework how "exportedArtifacts" works
>
>
> Key: MNG-7620
> URL: https://issues.apache.org/jira/browse/MNG-7620
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
>
> Recently there was a discussion about "exportedArtifacts" and how the work
> here are the relevant code path:
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java#L302-L328
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java#L83-L87
> First the documentation is a bit misleading, as it says
> {code:java}
> Patterns of artifacts provided by maven core and exported via maven api realm
> {code}
> from some experiments, it seems that any core or project extension can also
> define "exported" artifacts.
> Second is, that this simply adds the URL of an exported artifact and thus
> always the same *jar* is used to load the class, but still different
> classrealms can load the class.
> What came into my mind is that it actually should have an own realm where
> such exported artifacts are loaded and this realm is then imported instead of
> the URL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7620) Rework how "exportedArtifacts" works
[
https://issues.apache.org/jira/browse/MNG-7620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644281#comment-17644281
]
Romain Manni-Bucau commented on MNG-7620:
-
extensions.xml enables that or you enhance maven core class realm "factory" if
you prefer (depends if you want it to be static or dynamic I'd say).
only pre-requisite: load the extension early enough, ie not part of the
project/build itself but we can't really help that until we enable some reload
mecanism which would break more than it would help for a build system IMHO.
> Rework how "exportedArtifacts" works
>
>
> Key: MNG-7620
> URL: https://issues.apache.org/jira/browse/MNG-7620
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
>
> Recently there was a discussion about "exportedArtifacts" and how the work
> here are the relevant code path:
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java#L302-L328
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java#L83-L87
> First the documentation is a bit misleading, as it says
> {code:java}
> Patterns of artifacts provided by maven core and exported via maven api realm
> {code}
> from some experiments, it seems that any core or project extension can also
> define "exported" artifacts.
> Second is, that this simply adds the URL of an exported artifact and thus
> always the same *jar* is used to load the class, but still different
> classrealms can load the class.
> What came into my mind is that it actually should have an own realm where
> such exported artifacts are loaded and this realm is then imported instead of
> the URL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7620) Rework how "exportedArtifacts" works
[
https://issues.apache.org/jira/browse/MNG-7620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17644264#comment-17644264
]
Romain Manni-Bucau commented on MNG-7620:
-
Guess with the new v4 api it will mainly be a matter of taking what is exported
from maven-core (v4 api impl) + optionally added by extensions and be it.
Side note: for v3 plugin we must keep the legacy behavior of exporting or not
based on a predefined list (+ext).
> Rework how "exportedArtifacts" works
>
>
> Key: MNG-7620
> URL: https://issues.apache.org/jira/browse/MNG-7620
> Project: Maven
> Issue Type: Improvement
>Reporter: Christoph Läubrich
>Priority: Major
>
> Recently there was a discussion about "exportedArtifacts" and how the work
> here are the relevant code path:
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java#L302-L328
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/classrealm/DefaultClassRealmManager.java#L83-L87
> First the documentation is a bit misleading, as it says
> {code:java}
> Patterns of artifacts provided by maven core and exported via maven api realm
> {code}
> from some experiments, it seems that any core or project extension can also
> define "exported" artifacts.
> Second is, that this simply adds the URL of an exported artifact and thus
> always the same *jar* is used to load the class, but still different
> classrealms can load the class.
> What came into my mind is that it actually should have an own realm where
> such exported artifacts are loaded and this realm is then imported instead of
> the URL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MPLUGIN-436) Deprecate implementation configuration in plugin descriptor
[ https://issues.apache.org/jira/browse/MPLUGIN-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated MPLUGIN-436: --- Description: Goal is to align with https://issues.apache.org/jira/browse/MPLUGIN-435. Likely should be done for 4.x rather than 3.x. > Deprecate implementation configuration in plugin descriptor > --- > > Key: MPLUGIN-436 > URL: https://issues.apache.org/jira/browse/MPLUGIN-436 > Project: Maven Plugin Tools > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Minor > > Goal is to align with https://issues.apache.org/jira/browse/MPLUGIN-435. > Likely should be done for 4.x rather than 3.x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-436) Deprecate implementation configuration in plugin descriptor
Romain Manni-Bucau created MPLUGIN-436: -- Summary: Deprecate implementation configuration in plugin descriptor Key: MPLUGIN-436 URL: https://issues.apache.org/jira/browse/MPLUGIN-436 Project: Maven Plugin Tools Issue Type: Task Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-435) Revert MPLUGIN-410 (@Parameter(implementation))
Romain Manni-Bucau created MPLUGIN-435: -- Summary: Revert MPLUGIN-410 (@Parameter(implementation)) Key: MPLUGIN-435 URL: https://issues.apache.org/jira/browse/MPLUGIN-435 Project: Maven Plugin Tools Issue Type: Task Components: maven-plugin-tools-annotations Reporter: Romain Manni-Bucau This usage seems an edge case and bring more ambiguity to the API than it helps so saner to keep it handled in the mojo (either binding the implementation, using explicit impl as an attribute or using a wrapper binding). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7532) Revert MNG-6931 deprecation since list shows no consensus on that
[ https://issues.apache.org/jira/browse/MNG-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated MNG-7532: Description: There are several threads on the dev list asking for the drop of slf4j and at least keeping a logging abstraction for not internal dev (= core can use slf4j but not mojo/extensions). Work is being done to abstract plugin api so let's keep the deprecation/replacement of our Log API in this track and keep it the official way for now. one of the multiple refs: https://www.mail-archive.com/dev@maven.apache.org/msg123452.html was: There are several threads on the dev list asking for the drop of slf4j and at least keeping a logging abstraction for not internal dev (= core can use slf4j but not mojo/extensions). Work is being done to abstract plugin api so let's keep the deprecation/replacement of our Log API in this track and keep it the official way for now. > Revert MNG-6931 deprecation since list shows no consensus on that > - > > Key: MNG-7532 > URL: https://issues.apache.org/jira/browse/MNG-7532 > Project: Maven > Issue Type: Task >Reporter: Romain Manni-Bucau >Priority: Major > > There are several threads on the dev list asking for the drop of slf4j and at > least keeping a logging abstraction for not internal dev (= core can use > slf4j but not mojo/extensions). > Work is being done to abstract plugin api so let's keep the > deprecation/replacement of our Log API in this track and keep it the official > way for now. > one of the multiple refs: > https://www.mail-archive.com/dev@maven.apache.org/msg123452.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7532) Revert MNG-6931 deprecation since list shows no consensus on that
Romain Manni-Bucau created MNG-7532: --- Summary: Revert MNG-6931 deprecation since list shows no consensus on that Key: MNG-7532 URL: https://issues.apache.org/jira/browse/MNG-7532 Project: Maven Issue Type: Task Reporter: Romain Manni-Bucau There are several threads on the dev list asking for the drop of slf4j and at least keeping a logging abstraction for not internal dev (= core can use slf4j but not mojo/extensions). Work is being done to abstract plugin api so let's keep the deprecation/replacement of our Log API in this track and keep it the official way for now. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-410) Create implementation attribute for @Parameter as it exists for javadoc @parameter
[ https://issues.apache.org/jira/browse/MPLUGIN-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17572342#comment-17572342 ] Romain Manni-Bucau commented on MPLUGIN-410: [~hboutemy] assume you have an interface `FileConfiguration` and an implementation you want to use (`implementation=xxx`) which is `FileConfigurationImpl`, then instead of doing `@Parameter List configs;` you can do `@Parameter List configs;` and be it so `implementation=xxx` is almost always useless. For pluggable and heterogeneous cases (multiple implementations of `FileConfiguration` for example `LocalFileConfiguration` and `HDFSFileConfiguration`) then you can use plexus attributes to set the class (a bit like shade plugin does for transformers) and use `FileConfiguration` so both cases homogeneous (plugin driven) and heterogeneous (user driven) are already handled without this attribute from my window. > Create implementation attribute for @Parameter as it exists for javadoc > @parameter > -- > > Key: MPLUGIN-410 > URL: https://issues.apache.org/jira/browse/MPLUGIN-410 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: maven-plugin-tools-annotations >Reporter: Herve Boutemy >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > > it exists in javadoc annotations: > https://maven.apache.org/plugin-tools/maven-plugin-tools-java/ (line 33) > that goes into plugin.xml descriptor > https://maven.apache.org/ref/3.8.6/maven-plugin-api/plugin.html (line 44) > but was forgotten in Java 5 annotations: > https://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/ (line > 44) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MPLUGIN-410) Create implementation attribute for @Parameter as it exists for javadoc @parameter
[ https://issues.apache.org/jira/browse/MPLUGIN-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17570854#comment-17570854 ] Romain Manni-Bucau commented on MPLUGIN-410: Out of curiosity: any reason to implement that and not encourage to use the impl as parameter type instead as done today - = is the complexity it adds in the API for us (validation of the class hierarchy) and users (duplicated information in most of the case if you don't use the default or ignore the parameter) worth it? > Create implementation attribute for @Parameter as it exists for javadoc > @parameter > -- > > Key: MPLUGIN-410 > URL: https://issues.apache.org/jira/browse/MPLUGIN-410 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: maven-plugin-tools-annotations >Reporter: Herve Boutemy >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.7.0 > > > it exists in javadoc annotations: > https://maven.apache.org/plugin-tools/maven-plugin-tools-java/ (line 33) > that goes into plugin.xml descriptor > https://maven.apache.org/ref/3.8.6/maven-plugin-api/plugin.html (line 44) > but was forgotten in Java 5 annotations: > https://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/ (line > 44) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-385) Support for Multi-Release-JARs
[ https://issues.apache.org/jira/browse/MSHADE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17567826#comment-17567826 ] Romain Manni-Bucau commented on MSHADE-385: --- Yeah, long story short: manifestEntries enables to control what ends in the MANIFEST.MF and multijars are just about enabling a particular attribute in this file so the plugin does not handle it specifically but supports it. > Support for Multi-Release-JARs > -- > > Key: MSHADE-385 > URL: https://issues.apache.org/jira/browse/MSHADE-385 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.3.0 >Reporter: Markus Karg >Priority: Major > > Maven Shade Plugin currently is unable to deal with multi-release JARs, hence > it always (and only) picks the lowest commen nominator (fallback) class. > > Actually the plugin should instead produce a multi-release JAR, hence pick > all class versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-385) Support for Multi-Release-JARs
[ https://issues.apache.org/jira/browse/MSHADE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17567680#comment-17567680 ] Romain Manni-Bucau commented on MSHADE-385: --- Hi [~lucastheisen] , did you set it in manifest entries? > Support for Multi-Release-JARs > -- > > Key: MSHADE-385 > URL: https://issues.apache.org/jira/browse/MSHADE-385 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.3.0 >Reporter: Markus Karg >Priority: Major > > Maven Shade Plugin currently is unable to deal with multi-release JARs, hence > it always (and only) picks the lowest commen nominator (fallback) class. > > Actually the plugin should instead produce a multi-release JAR, hence pick > all class versions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1892) systemPropertyVariables does not support interpolated values which are not string like settings.offline
[ https://issues.apache.org/jira/browse/SUREFIRE-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551978#comment-17551978 ] Romain Manni-Bucau commented on SUREFIRE-1892: -- [~olamy] hmm, was months ago now but was clearly taking way too much time for a trivial fix so guess I just gave up since there are workarounds > systemPropertyVariables does not support interpolated values which are not > string like settings.offline > --- > > Key: SUREFIRE-1892 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1892 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M5 >Reporter: Romain Manni-Bucau >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (MSCRIPTING-9) Support java scripting
Romain Manni-Bucau created MSCRIPTING-9: --- Summary: Support java scripting Key: MSCRIPTING-9 URL: https://issues.apache.org/jira/browse/MSCRIPTING-9 Project: Maven Scripting Issue Type: Task Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516370#comment-17516370
]
Romain Manni-Bucau commented on MSHADE-417:
---
Yep please close as fixed. I used romain.manni-bucau since a bit more for most
asf project, only openejb used rmannibucau before switching, not sure where the
assumption the same name is used on both systems comes from but happy to fix it
if it is a missed update sby can point out.
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MSHADE-417) Nul bytes appended to small files by maven-shade-plugin
[
https://issues.apache.org/jira/browse/MSHADE-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516344#comment-17516344
]
Romain Manni-Bucau commented on MSHADE-417:
---
[~hboutemy] , yes I don't have perms to do that (mentionned it a few times on
slack, guess it is a bad username - romain.manni-bucau is the right one?).
Not sure about your use case for null bytes, do you have some sample? Max
analyzis is right but also means we create a shade of nothing which sounds like
a project setup error.
> Nul bytes appended to small files by maven-shade-plugin
> ---
>
> Key: MSHADE-417
> URL: https://issues.apache.org/jira/browse/MSHADE-417
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Max Zerzouri
>Priority: Major
> Attachments: original-shadetest-0.0.0.jar, pom.xml,
> shadetest-0.0.0.jar, test.txt
>
>
> Version 3.3.0 of maven shade plugin seems to append "\x00" bytes to a file if
> it's less than 4 bytes:
> {code:sh}
> $ echo -n a > src/main/resources/test.txt
> $ mvn clean install
> ...
> $ bsdtar -xOf target/original-shadetest-0.0.0.jar test.txt | xxd
> : 61 a
> $ bsdtar -xOf target/shadetest-0.0.0.jar test.txt | xxd
> : 6100 a...
> {code}
> I've attached a basic {{pom.xml}} that triggers this. This doesn't occur in
> the previous version, 3.2.4.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MSHADE-412) SimpleRelocator can fail in NPE, in particular with manifest transformer
Romain Manni-Bucau created MSHADE-412: - Summary: SimpleRelocator can fail in NPE, in particular with manifest transformer Key: MSHADE-412 URL: https://issues.apache.org/jira/browse/MSHADE-412 Project: Maven Shade Plugin Issue Type: Task Affects Versions: 3.2.4 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MPLUGIN-385) Clarify usage of scope "provided" for Maven artifacts with group id "org.apache.maven"
[
https://issues.apache.org/jira/browse/MPLUGIN-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461552#comment-17461552
]
Romain Manni-Bucau commented on MPLUGIN-385:
[~cstamas] just diff maven 3.3 and 3.8 exported packages and jars. Even in
plain 3.8 you get it since not all is exported so this issue cant be done until
we have a real API sadly :(.
> Clarify usage of scope "provided" for Maven artifacts with group id
> "org.apache.maven"
> --
>
> Key: MPLUGIN-385
> URL: https://issues.apache.org/jira/browse/MPLUGIN-385
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Since m-plugin-p 3.6.2 (MPLUGIN-370) all dependencies with group id
> {{org.apache.maven}} are supposed to be referenced with scope {{provided}}.
> But once turning dependency {{org.apache.maven:maven-archiver:3.5.1}} to
> scope provided my ITs based on
> {{org.apache.maven.shared:maven-verifier:1.7.2}} are starting to fail with
> NCDF errors
> {code}
> java.lang.NoClassDefFoundError:
> Lorg/apache/maven/archiver/MavenArchiveConfiguration;
> {code}
> Is that a bug in the classloader with maven-verifier? What if I want to use a
> newer version than shipped with Maven like "maven-archiver 3.5.1"?
> What about group ids starting with "org.apache.maven" like
> "org.apache.maven.shared"?
> You can reproduce with
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MPLUGIN-385) Clarify usage of scope "provided" for Maven artifacts with group id "org.apache.maven"
[
https://issues.apache.org/jira/browse/MPLUGIN-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461532#comment-17461532
]
Romain Manni-Bucau commented on MPLUGIN-385:
Once again the point is that we must enable provided only for explicitly
allowed API, rest must be compile. So provided by default is the promise to
have ClassNotFound very quickly. In terms of perf the actually provided deps
can be skipped even if in compile mode so we have multiple axes to optimize but
moving to provided maven-* does not work.
> Clarify usage of scope "provided" for Maven artifacts with group id
> "org.apache.maven"
> --
>
> Key: MPLUGIN-385
> URL: https://issues.apache.org/jira/browse/MPLUGIN-385
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Since m-plugin-p 3.6.2 (MPLUGIN-370) all dependencies with group id
> {{org.apache.maven}} are supposed to be referenced with scope {{provided}}.
> But once turning dependency {{org.apache.maven:maven-archiver:3.5.1}} to
> scope provided my ITs based on
> {{org.apache.maven.shared:maven-verifier:1.7.2}} are starting to fail with
> NCDF errors
> {code}
> java.lang.NoClassDefFoundError:
> Lorg/apache/maven/archiver/MavenArchiveConfiguration;
> {code}
> Is that a bug in the classloader with maven-verifier? What if I want to use a
> newer version than shipped with Maven like "maven-archiver 3.5.1"?
> What about group ids starting with "org.apache.maven" like
> "org.apache.maven.shared"?
> You can reproduce with
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MPLUGIN-385) Clarify usage of scope "provided" for Maven artifacts with group id "org.apache.maven"
[
https://issues.apache.org/jira/browse/MPLUGIN-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461506#comment-17461506
]
Romain Manni-Bucau commented on MPLUGIN-385:
[~michael-o] this is not the case since most of org.apache.maven packages/jars
are internals of maven-core and must not be used from plugins.
> Clarify usage of scope "provided" for Maven artifacts with group id
> "org.apache.maven"
> --
>
> Key: MPLUGIN-385
> URL: https://issues.apache.org/jira/browse/MPLUGIN-385
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.6.2
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 3.7.0
>
>
> Since m-plugin-p 3.6.2 (MPLUGIN-370) all dependencies with group id
> {{org.apache.maven}} are supposed to be referenced with scope {{provided}}.
> But once turning dependency {{org.apache.maven:maven-archiver:3.5.1}} to
> scope provided my ITs based on
> {{org.apache.maven.shared:maven-verifier:1.7.2}} are starting to fail with
> NCDF errors
> {code}
> java.lang.NoClassDefFoundError:
> Lorg/apache/maven/archiver/MavenArchiveConfiguration;
> {code}
> Is that a bug in the classloader with maven-verifier? What if I want to use a
> newer version than shipped with Maven like "maven-archiver 3.5.1"?
> What about group ids starting with "org.apache.maven" like
> "org.apache.maven.shared"?
> You can reproduce with
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MPLUGIN-385) Clarify usage of scope "provided" for Maven artifacts with group id "org.apache.maven"
[
https://issues.apache.org/jira/browse/MPLUGIN-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461223#comment-17461223
]
Romain Manni-Bucau commented on MPLUGIN-385:
[~kwin] this is technically only possible if you have a compatibility with past
*and* future version to respect "Very true, but both version and scope should
IMHO be determined from the minimum Maven version the plugin claims to be
compatible with", it is quite unlikely and in terms of testing requires a new
setup we don't have so just moving to scope=provided is very risky without
implementing the full story which requires to add to our release metadata we
don't have yet.
Also "True that in case of wrong assumptions of versions it will fail for both
scopes "provided" and "compile", but my point is actually that "provided" is
better due to the reasons outlined by you (not unnecessarily downloaded)" is
not true since the only case which is to discuss is an incompatibility between
an exported lib where provided is better but for all other cases compile is the
right one (lib present but not exported, lib missing) so compile is the right
scope as explained.
For extension we enabled to control the classloading strategy (thanks [~gnodet]
) so we can end up enabling it for mojo - and likely in the plugin definition
in the pom and not in the plugin _only_ - to solve that properly for all users.
Last, the woraround to add in plugin dependencies provided deps is a bad one
since it breaks existing plugins when they will upgrade and it will not be
natural for users in most cases whereas compile is.
Now, there is no issue dropping a dependency resolution for mojo when we know
we will provide the dependency and let it be loaded from maven.core which
solves your download issue.
> Clarify usage of scope "provided" for Maven artifacts with group id
> "org.apache.maven"
> --
>
> Key: MPLUGIN-385
> URL: https://issues.apache.org/jira/browse/MPLUGIN-385
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.6.2
>Reporter: Konrad Windszus
>Priority: Major
>
> Since m-plugin-p 3.6.2 (MPLUGIN-370) all dependencies with group id
> {{org.apache.maven}} are supposed to be referenced with scope {{provided}}.
> But once turning dependency {{org.apache.maven:maven-archiver:3.5.1}} to
> scope provided my ITs based on
> {{org.apache.maven.shared:maven-verifier:1.7.2}} are starting to fail with
> NCDF errors
> {code}
> java.lang.NoClassDefFoundError:
> Lorg/apache/maven/archiver/MavenArchiveConfiguration;
> {code}
> Is that a bug in the classloader with maven-verifier? What if I want to use a
> newer version than shipped with Maven like "maven-archiver 3.5.1"?
> What about group ids starting with "org.apache.maven" like
> "org.apache.maven.shared"?
> You can reproduce with
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MPLUGIN-385) Clarify usage of scope "provided" for Maven artifacts with group id "org.apache.maven"
[
https://issues.apache.org/jira/browse/MPLUGIN-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460980#comment-17460980
]
Romain Manni-Bucau commented on MPLUGIN-385:
This is one issue of current design: all the API can be used as provided but
the API is not what is in maven/lib but only a very very small subset (the one
leaked in mojo classrealm) so anything else must stay in scope compile to
survive a maven version change (keep in mind plugins are not used with a single
version of maven). At some point we'll need to do our homework and define an
explicit API where provided scope would be encourage but AFAIK we don't have it
yet. Hope it makes sense.
> Clarify usage of scope "provided" for Maven artifacts with group id
> "org.apache.maven"
> --
>
> Key: MPLUGIN-385
> URL: https://issues.apache.org/jira/browse/MPLUGIN-385
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 3.6.2
>Reporter: Konrad Windszus
>Priority: Major
>
> Since m-plugin-p 3.6.2 (MPLUGIN-370) all dependencies with group id
> {{org.apache.maven}} are supposed to be referenced with scope {{provided}}.
> But once turning dependency {{org.apache.maven:maven-archiver:3.5.1}} to
> scope provided my ITs based on
> {{org.apache.maven.shared:maven-verifier:1.7.2}} are starting to fail with
> NCDF errors
> {code}
> java.lang.NoClassDefFoundError:
> Lorg/apache/maven/archiver/MavenArchiveConfiguration;
> {code}
> Is that a bug in the classloader with maven-verifier? What if I want to use a
> newer version than shipped with Maven like "maven-archiver 3.5.1"?
> What about group ids starting with "org.apache.maven" like
> "org.apache.maven.shared"?
> You can reproduce with
> https://github.com/apache/jackrabbit-filevault-package-maven-plugin.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MNG-6354) don't leak javax.* API
[ https://issues.apache.org/jira/browse/MNG-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427462#comment-17427462 ] Romain Manni-Bucau commented on MNG-6354: - [~michael-o] thanks for the ping, sent now. > don't leak javax.* API > -- > > Key: MNG-6354 > URL: https://issues.apache.org/jira/browse/MNG-6354 > Project: Maven > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: waiting-for-feedback > > > At the moment maven leaks cdi/inject spec jars. This has side effects for > several frameworks/servers. Would be good to keep it internal. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6354) don't leak javax.* API
[ https://issues.apache.org/jira/browse/MNG-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417458#comment-17417458 ] Romain Manni-Bucau commented on MNG-6354: - Will open a thread on the list to see what we do about it. > don't leak javax.* API > -- > > Key: MNG-6354 > URL: https://issues.apache.org/jira/browse/MNG-6354 > Project: Maven > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: waiting-for-feedback > > > At the moment maven leaks cdi/inject spec jars. This has side effects for > several frameworks/servers. Would be good to keep it internal. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6354) don't leak javax.* API
[ https://issues.apache.org/jira/browse/MNG-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417399#comment-17417399 ] Romain Manni-Bucau commented on MNG-6354: - Javax.inject is unique so okish, annotation too cause of jakarta switch but it stays a design issue we should fix if possible but would be a breaking change - not sure we can break mojos/exts like that. > don't leak javax.* API > -- > > Key: MNG-6354 > URL: https://issues.apache.org/jira/browse/MNG-6354 > Project: Maven > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: waiting-for-feedback > > > At the moment maven leaks cdi/inject spec jars. This has side effects for > several frameworks/servers. Would be good to keep it internal. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6354) don't leak javax.* API
[ https://issues.apache.org/jira/browse/MNG-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417383#comment-17417383 ] Romain Manni-Bucau commented on MNG-6354: - Inject and annotations are still exported afaik: https://github.com/apache/maven/blob/406c525ec45da466387dbf19f7fd8ed1d9885e66/maven-core/src/main/resources/META-INF/maven/extension.xml#L98 > don't leak javax.* API > -- > > Key: MNG-6354 > URL: https://issues.apache.org/jira/browse/MNG-6354 > Project: Maven > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: waiting-for-feedback > > > At the moment maven leaks cdi/inject spec jars. This has side effects for > several frameworks/servers. Would be good to keep it internal. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6354) don't leak javax.* API
[ https://issues.apache.org/jira/browse/MNG-6354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17417324#comment-17417324 ] Romain Manni-Bucau commented on MNG-6354: - We did for cdi not all subpackages AFAIK - jsr250 still leaks i think even if less impacting since jakarta renaming. > don't leak javax.* API > -- > > Key: MNG-6354 > URL: https://issues.apache.org/jira/browse/MNG-6354 > Project: Maven > Issue Type: Improvement >Reporter: Romain Manni-Bucau >Priority: Major > Fix For: waiting-for-feedback > > > At the moment maven leaks cdi/inject spec jars. This has side effects for > several frameworks/servers. Would be good to keep it internal. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1943) give surefirebooter jar an useful name
Romain Manni-Bucau created SUREFIRE-1943: Summary: give surefirebooter jar an useful name Key: SUREFIRE-1943 URL: https://issues.apache.org/jira/browse/SUREFIRE-1943 Project: Maven Surefire Issue Type: Task Reporter: Romain Manni-Bucau Surefire booter jar name generally looks like "surefirebooter.jar". Would be way better to name it "surefirebooter--.jar" since it would enable to identify it using jps (or equivalent) very quickly and is not that crazy since all the info are in the mojo anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSCRIPTING-7) Session is not bound in scripting bindings
[ https://issues.apache.org/jira/browse/MSCRIPTING-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402758#comment-17402758 ] Romain Manni-Bucau commented on MSCRIPTING-7: - Functionally i want to be able to replace any custom mojo so i need kind of inject capability. Gmavenplus plugin does it exposing the session and therefore plexus container as most plugins. > Session is not bound in scripting bindings > -- > > Key: MSCRIPTING-7 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-7 > Project: Maven Scripting > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Romain Manni-Bucau >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSCRIPTING-7) Session is not bound in scripting bindings
[ https://issues.apache.org/jira/browse/MSCRIPTING-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402740#comment-17402740 ] Romain Manni-Bucau commented on MSCRIPTING-7: - There are operations you cant do without the session so it must be done otherwise the scripting goal to enable to extend the build with custom tasks without writing a plugin for specific cases is not reached. All other scripting plugins do generally for that reason. Minimum is to let the ioc/guice injector/plexus container be accessed. > Session is not bound in scripting bindings > -- > > Key: MSCRIPTING-7 > URL: https://issues.apache.org/jira/browse/MSCRIPTING-7 > Project: Maven Scripting > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Romain Manni-Bucau >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MSCRIPTING-7) Session is not bound in scripting bindings
Romain Manni-Bucau created MSCRIPTING-7: --- Summary: Session is not bound in scripting bindings Key: MSCRIPTING-7 URL: https://issues.apache.org/jira/browse/MSCRIPTING-7 Project: Maven Scripting Issue Type: Task Affects Versions: 3.0.0 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHARED-989) Undeprecate DirectoryScanner and MatchPattern(s)
[
https://issues.apache.org/jira/browse/MSHARED-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17355768#comment-17355768
]
Romain Manni-Bucau commented on MSHARED-989:
[~kwin] IIRC it was the idea yes
> Undeprecate DirectoryScanner and MatchPattern(s)
>
>
> Key: MSHARED-989
> URL: https://issues.apache.org/jira/browse/MSHARED-989
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-shared-utils
>Reporter: Konrad Windszus
>Priority: Major
>
> In MSHARED-898 {{DirectoryScanner}} has been deprecated. Instead using the
> {{java.nio.file.DirectoryStream}} is now recommended.
> The latter is often no replacement as the parametrization of DirectoryScanner
> with Ant-style globs for includes/excludes is not supported. Also the
> {{DEFAULTEXCLUDES}} are not part of Java NIO {{DirectoryStream}} either.
> The same applies to {{MatchPatterns}}, which is deprecated and now recommends
> using {{java.nio.filejava.nio.file.DirectoryStream.Filter}}. Please
> instead provide a Filter for Java NIO for those patterns (regex and ant) and
> make {{DirectoryScanner}} use File NIO internally while keeping API
> compatibility.
> Otherwise every consumer of DirectoryScanner needs to come up with a custom
> implementation of pattern matching and a lot of glue code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MJAVADOC-623) [ERROR] Error fetching link: %{project.basedir}/target/javadoc-bundle-options. Ignored it.
[
https://issues.apache.org/jira/browse/MJAVADOC-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352722#comment-17352722
]
Romain Manni-Bucau commented on MJAVADOC-623:
-
Hi, seems it happens with JDK 16 again. Not sure there is a workaround.
> [ERROR] Error fetching link:
> %{project.basedir}/target/javadoc-bundle-options. Ignored it.
> --
>
> Key: MJAVADOC-623
> URL: https://issues.apache.org/jira/browse/MJAVADOC-623
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.1
>Reporter: Yaytay
>Assignee: Robert Scholte
>Priority: Minor
> Fix For: 3.3.0
>
>
> Not sure whether this is a bug or a something missing my side.
> Using the javadoc plugin with maven 3.6.2 and JDK 13 and a minimal
> configuration:
> {code:xml}
>
> org.apache.maven.plugins
> maven-javadoc-plugin
> 3.1.1
>
>
>attach-javadocs
>
> jar
>
>
>
>
> {code}
> I get this error:
> [ERROR] Error fetching link:
> ${project.basedir}/target/javadoc-bundle-options. Ignored it.
> (with the ${project.basedir} being the absolute path for the project).
> If this error can be ignored it shouldn't be logged at Error level (debug or
> info would be preferable).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346919#comment-17346919
]
Romain Manni-Bucau commented on MNG-6677:
-
During the migration time it can if mixed licenses are used but im sure we can
update it to merge to spdx naming for known string - at least asf exception -
so does not look like a blocker to me.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346856#comment-17346856
]
Romain Manni-Bucau commented on MNG-6677:
-
> Yes, ti will, all reporting for license will be broken because they don't use
>the current canonical display name.
Likely not since current value is a free text, they will just use it as a free
text and work the same.
Such tools already don't match the exact text but pattern (Apache.*2 for ex) so
it is a win and no real drawbacks AFAIK. Any example of broken tool with this
move?
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6677) Ability to declare machine-readable license identifier for project
[
https://issues.apache.org/jira/browse/MNG-6677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346633#comment-17346633
]
Romain Manni-Bucau commented on MNG-6677:
-
What about these 2 actions:
1. make asf parent using the normalized name
2. add to our xsd completion capability for known licenses (normalized fashion)
this way no breaking change and we still support custom licenses but we enable
and encourage normalized values.
> Ability to declare machine-readable license identifier for project
> --
>
> Key: MNG-6677
> URL: https://issues.apache.org/jira/browse/MNG-6677
> Project: Maven
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.6.1
>Reporter: Vladimir Sitnikov
>Priority: Major
> Fix For: Issues to be reviewed for 4.x
>
>
> Current model for license is something, yet it is not machine-friendly.
> Developers tend to put random data into
> {{..}}, and it is hard to analyze in
> automatic way.
> What if we could use SPDX license identifiers/expressions for license
> information?
> Note: currently POM allows to list multiple tags, and it is not
> clear how they should be treated (and? or?). So a machine-readable field
> should probably allow for AND/OR license expressions.
> So it would be nice if there was a way to declare a machine-readable license
> tag.
> I'm not affiliated with SPDX, however OSGi use those ids:
> https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1798) trimStackTrace should be false by default
[ https://issues.apache.org/jira/browse/SUREFIRE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346329#comment-17346329 ] Romain Manni-Bucau commented on SUREFIRE-1798: -- Fixed the "local" build which is now all green so hope CI will be as well. > trimStackTrace should be false by default > - > > Key: SUREFIRE-1798 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1798 > Project: Maven Surefire > Issue Type: Task > Components: Maven Surefire Plugin >Reporter: Romain Manni-Bucau >Priority: Major > > True was intended to clean up the output but it always misses any useful data > so let's set an useful default -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1798) trimStackTrace should be false by default
[ https://issues.apache.org/jira/browse/SUREFIRE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346083#comment-17346083 ] Romain Manni-Bucau commented on SUREFIRE-1798: -- up, any hope trimStackTrace becomes disabled by default? This is just unusable in most projects (I don't have a single project it works since some years already). > trimStackTrace should be false by default > - > > Key: SUREFIRE-1798 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1798 > Project: Maven Surefire > Issue Type: Task > Components: Maven Surefire Plugin >Reporter: Romain Manni-Bucau >Priority: Major > > True was intended to clean up the output but it always misses any useful data > so let's set an useful default -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-7134) Backport 3.8.1 security fixes in 3.6.x branch
Romain Manni-Bucau created MNG-7134: --- Summary: Backport 3.8.1 security fixes in 3.6.x branch Key: MNG-7134 URL: https://issues.apache.org/jira/browse/MNG-7134 Project: Maven Issue Type: Task Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7132) org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not handle local host/ip if not locahost/127.0.0.1
[ https://issues.apache.org/jira/browse/MNG-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311213#comment-17311213 ] Romain Manni-Bucau commented on MNG-7132: - [~hboutemy] isn't it only in resolver? About the title, I tried an update, does it work better for you? > org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not > handle local host/ip if not locahost/127.0.0.1 > > > Key: MNG-7132 > URL: https://issues.apache.org/jira/browse/MNG-7132 > Project: Maven > Issue Type: Bug >Reporter: Romain Manni-Bucau >Priority: Minor > > DefaultMirrorSelector used in > org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory#newRepositorySession > does not implement isLocal properly - more exactly it only handles 2 > particular cases whereas local can be way more numerous: > # ipv4 case: 127.x.y.z (test can be has 4 segments separated by a dot and > starts with 127.) > # ipv6 case: starts with 1 and ends with 0 (see > java.net.Inet6Address.Inet6AddressHolder#isLoopbackAddress) > # host case: not sure we want to handle it but except localhost hardcoded > string we could parse /etc/hosts (or windows specific location) too to > resolve the ip without going through InetAddress - see next point) and use > the ip with 1+2 rules. > this can be implemented as string parsing (faster) or reusing > [java.net|http://java.net/].InetAddress#isLoopbackAddress (which can fallback > in some resolution which can be slow at startup but works better overall and > is easier). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7132) org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not handle local host/ip if not locahost/127.0.0.1
[ https://issues.apache.org/jira/browse/MNG-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau updated MNG-7132: Summary: org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not handle local host/ip if not locahost/127.0.0.1 (was: org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not handle local host/ip) > org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not > handle local host/ip if not locahost/127.0.0.1 > > > Key: MNG-7132 > URL: https://issues.apache.org/jira/browse/MNG-7132 > Project: Maven > Issue Type: Bug >Reporter: Romain Manni-Bucau >Priority: Minor > > DefaultMirrorSelector used in > org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory#newRepositorySession > does not implement isLocal properly - more exactly it only handles 2 > particular cases whereas local can be way more numerous: > # ipv4 case: 127.x.y.z (test can be has 4 segments separated by a dot and > starts with 127.) > # ipv6 case: starts with 1 and ends with 0 (see > java.net.Inet6Address.Inet6AddressHolder#isLoopbackAddress) > # host case: not sure we want to handle it but except localhost hardcoded > string we could parse /etc/hosts (or windows specific location) too to > resolve the ip without going through InetAddress - see next point) and use > the ip with 1+2 rules. > this can be implemented as string parsing (faster) or reusing > [java.net|http://java.net/].InetAddress#isLoopbackAddress (which can fallback > in some resolution which can be slow at startup but works better overall and > is easier). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7132) org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not handle local host/ip
[ https://issues.apache.org/jira/browse/MNG-7132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310621#comment-17310621 ] Romain Manni-Bucau commented on MNG-7132: - Fully agree, I would prefer to rely on InetAdress in terms of impl but on some (old now - j7 last time I tested) JDK it is a bit slow but since it will end up loaded at some point maybe we don't care much except if mirror is loaded and no download are done (which happens luckily quite often). > org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not > handle local host/ip > -- > > Key: MNG-7132 > URL: https://issues.apache.org/jira/browse/MNG-7132 > Project: Maven > Issue Type: Bug >Reporter: Romain Manni-Bucau >Priority: Minor > > DefaultMirrorSelector used in > org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory#newRepositorySession > does not implement isLocal properly - more exactly it only handles 2 > particular cases whereas local can be way more numerous: > # ipv4 case: 127.x.y.z (test can be has 4 segments separated by a dot and > starts with 127.) > # ipv6 case: starts with 1 and ends with 0 (see > java.net.Inet6Address.Inet6AddressHolder#isLoopbackAddress) > # host case: not sure we want to handle it but except localhost hardcoded > string we could parse /etc/hosts (or windows specific location) too to > resolve the ip without going through InetAddress - see next point) and use > the ip with 1+2 rules. > this can be implemented as string parsing (faster) or reusing > [java.net|http://java.net/].InetAddress#isLoopbackAddress (which can fallback > in some resolution which can be slow at startup but works better overall and > is easier). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-7132) org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not handle local host/ip
Romain Manni-Bucau created MNG-7132: --- Summary: org.eclipse.aether.util.repository.DefaultMirrorSelector#isLocal does not handle local host/ip Key: MNG-7132 URL: https://issues.apache.org/jira/browse/MNG-7132 Project: Maven Issue Type: Bug Reporter: Romain Manni-Bucau DefaultMirrorSelector used in org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory#newRepositorySession does not implement isLocal properly - more exactly it only handles 2 particular cases whereas local can be way more numerous: # ipv4 case: 127.x.y.z (test can be has 4 segments separated by a dot and starts with 127.) # ipv6 case: starts with 1 and ends with 0 (see java.net.Inet6Address.Inet6AddressHolder#isLoopbackAddress) # host case: not sure we want to handle it but except localhost hardcoded string we could parse /etc/hosts (or windows specific location) too to resolve the ip without going through InetAddress - see next point) and use the ip with 1+2 rules. this can be implemented as string parsing (faster) or reusing [java.net|http://java.net/].InetAddress#isLoopbackAddress (which can fallback in some resolution which can be slow at startup but works better overall and is easier). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MSHADE-385) Support for Multi-Release-JARs
[ https://issues.apache.org/jira/browse/MSHADE-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17310264#comment-17310264 ] Romain Manni-Bucau commented on MSHADE-385: --- Hi [~mkarg], seems your statement is not accurate and we actually support mjar release as expected. Here is a quick sample project which shows it: [https://gist.github.com/rmannibucau/bee0fff499fdd17f6bffb17b3e0c13ab.] Can you confirm and close the ticket if so please? > Support for Multi-Release-JARs > -- > > Key: MSHADE-385 > URL: https://issues.apache.org/jira/browse/MSHADE-385 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 3.3.0 >Reporter: Markus Karg >Priority: Major > > Maven Shade Plugin currently is unable to deal with multi-release JARs, hence > it always (and only) picks the lowest commen nominator (fallback) class. > > Actually the plugin should instead produce a multi-release JAR, hence pick > all class versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MPLUGIN-350) Extend @Parameter with input/output option
[
https://issues.apache.org/jira/browse/MPLUGIN-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305736#comment-17305736
]
Romain Manni-Bucau commented on MPLUGIN-350:
[~rfscholte] ok to scope this ticket to plugin and have another umbrella ticket
for input/output support (this one becoming a subtask?). eval mojo is a great
example that you can mark input params but not output so overall plugin
contribution is not accurate. Add to that the fact your input is incomplete and
not sufficient for a graph approach (keep in mind most of the scripting engines
will supports imports/includes which are not made mojo aware). This is why I
mentionned that this API is not required to start supported input/output in
maven but that explicitly binding them per module is the main prerequisite (and
that deducing them when not set by checking mojo values can be an
implementation optimization but not the first impl). The fact to fallback on
"not maven context aware" is for not not an option since almost all builds will
fall in this bucket in practise so feature would never be usable as mentionned.
> Extend @Parameter with input/output option
> --
>
> Key: MPLUGIN-350
> URL: https://issues.apache.org/jira/browse/MPLUGIN-350
> Project: Maven Plugin Tools
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
>
> By knowing if parameters are input or output parameters, it is possible to
> improve our builds. It will be possible to create DAGs and chain the
> execution blocks much smarter.
> The Maven Extension created by Gradle heavily relies on this kind of
> information.
> It is probably easier to use new annotations instead of adding a (required)
> status-field to @Parameter
> Looking at the {{plugin.xml}} it looks quite easy to solve this and stay
> backwards compatible: the file looks now like:
> {code:xml}
>
>
> ...
>
>
> {code}
> With plexus-magic the following should still work:
> {code:xml}
>
>
> ...
>
>
> ...
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-350) Extend @Parameter with input/output option
[
https://issues.apache.org/jira/browse/MPLUGIN-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305553#comment-17305553
]
Romain Manni-Bucau commented on MPLUGIN-350:
Which hack? Concretely my point is to target what users can rely on and not try
to be idealistic and do something almost no project but commons can use.
Inputs/outputs from tasks (mojo) always lead to wrong build setups in practise,
always. Workaround is to drop the cache but it is not a feature as such for me.
Ensuring build owns that feature and usage makes it usable and useful for end
users. In that regard using mojo level first is a hack ;).
> Extend @Parameter with input/output option
> --
>
> Key: MPLUGIN-350
> URL: https://issues.apache.org/jira/browse/MPLUGIN-350
> Project: Maven Plugin Tools
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
>
> By knowing if parameters are input or output parameters, it is possible to
> improve our builds. It will be possible to create DAGs and chain the
> execution blocks much smarter.
> The Maven Extension created by Gradle heavily relies on this kind of
> information.
> It is probably easier to use new annotations instead of adding a (required)
> status-field to @Parameter
> Looking at the {{plugin.xml}} it looks quite easy to solve this and stay
> backwards compatible: the file looks now like:
> {code:xml}
>
>
> ...
>
>
> {code}
> With plexus-magic the following should still work:
> {code:xml}
>
>
> ...
>
>
> ...
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-350) Split @Parameter into @Input and @Output
[
https://issues.apache.org/jira/browse/MPLUGIN-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305520#comment-17305520
]
Romain Manni-Bucau commented on MPLUGIN-350:
> I see it as another opportunity to migrate these the official maven-plugins
>so they can benefit from its features.
Let's be honest, it will never be and if it is it means you prevent any user
custom build task which is the exact opposite of current trend (living dock,
custom images, custom distro, native builds, etc) so let's support what people
do today and be "perfect" if possible and if not just work.
> Split @Parameter into @Input and @Output
>
>
> Key: MPLUGIN-350
> URL: https://issues.apache.org/jira/browse/MPLUGIN-350
> Project: Maven Plugin Tools
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
>
> By knowing if parameters are input or output parameters, it is possible to
> improve our builds. It will be possible to create DAGs and chain the
> execution blocks much smarter.
> The Maven Extension created by Gradle heavily relies on this kind of
> information.
> It is probably easier to use new annotations instead of adding a (required)
> status-field to @Parameter
> Looking at the {{plugin.xml}} it looks quite easy to solve this and stay
> backwards compatible: the file looks now like:
> {code:xml}
>
>
> ...
>
>
> {code}
> With plexus-magic the following should still work:
> {code:xml}
>
>
> ...
>
>
> ...
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-350) Split @Parameter into @Input and @Output
[
https://issues.apache.org/jira/browse/MPLUGIN-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305430#comment-17305430
]
Romain Manni-Bucau commented on MPLUGIN-350:
+1, also need an adhoc attribute on the plugin since no parameter is needed for
several plugin so no location to add an attribute.
> Split @Parameter into @Input and @Output
>
>
> Key: MPLUGIN-350
> URL: https://issues.apache.org/jira/browse/MPLUGIN-350
> Project: Maven Plugin Tools
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
>
> By knowing if parameters are input or output parameters, it is possible to
> improve our builds. It will be possible to create DAGs and chain the
> execution blocks much smarter.
> The Maven Extension created by Gradle heavily relies on this kind of
> information.
> It is probably easier to use new annotations instead of adding a (required)
> status-field to @Parameter
> Looking at the {{plugin.xml}} it looks quite easy to solve this and stay
> backwards compatible: the file looks now like:
> {code:xml}
>
>
> ...
>
>
> {code}
> With plexus-magic the following should still work:
> {code:xml}
>
>
> ...
>
>
> ...
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MPLUGIN-350) Split @Parameter into @Input and @Output
[
https://issues.apache.org/jira/browse/MPLUGIN-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17305407#comment-17305407
]
Romain Manni-Bucau commented on MPLUGIN-350:
I think it must be added to pom model instead of plugin first (can be cumulated
but general solution is pom) since some plugins have no way to know like exec,
scripting etc...
Also some output can be ignored - thinking to jib debug .properties/json.
So overall it looks like it is a module concern and not a mojo concern since
maven is module driven (whereas grafle is task/mojo driven so we must not copy
thzir model IMHO).
> Split @Parameter into @Input and @Output
>
>
> Key: MPLUGIN-350
> URL: https://issues.apache.org/jira/browse/MPLUGIN-350
> Project: Maven Plugin Tools
> Issue Type: New Feature
>Reporter: Robert Scholte
>Priority: Major
>
> By knowing if parameters are input or output parameters, it is possible to
> improve our builds. It will be possible to create DAGs and chain the
> execution blocks much smarter.
> The Maven Extension created by Gradle heavily relies on this kind of
> information.
> It is probably easier to use new annotations instead of adding a (required)
> status-field to @Parameter
> Looking at the {{plugin.xml}} it looks quite easy to solve this and stay
> backwards compatible: the file looks now like:
> {code:xml}
>
>
> ...
>
>
> {code}
> With plexus-magic the following should still work:
> {code:xml}
>
>
> ...
>
>
> ...
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (SUREFIRE-1892) systemPropertyVariables does not support interpolated values which are not string like settings.offline
Romain Manni-Bucau created SUREFIRE-1892: Summary: systemPropertyVariables does not support interpolated values which are not string like settings.offline Key: SUREFIRE-1892 URL: https://issues.apache.org/jira/browse/SUREFIRE-1892 Project: Maven Surefire Issue Type: Bug Affects Versions: 3.0.0-M5 Reporter: Romain Manni-Bucau -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7067) Ensure produced (consumable) pom takes into account extensions
[
https://issues.apache.org/jira/browse/MNG-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259123#comment-17259123
]
Romain Manni-Bucau commented on MNG-7067:
-
[~rfscholte] don't think it can work this way, the model mutation must be done
before the build plan is ready otherwise the build plan can be wrong so I guess
we must ensure any afterRead callback is callde before the build plan gets
fully computed (blind guess is we'll need to phase that).
> Ensure produced (consumable) pom takes into account extensions
> --
>
> Key: MNG-7067
> URL: https://issues.apache.org/jira/browse/MNG-7067
> Project: Maven
> Issue Type: Task
>Affects Versions: 4.0.0-alpha-1
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> Goal is to have this kind of (build time) extension reflected in the produced
> pom:
> {code:java}
> @Component(role = AbstractMavenLifecycleParticipant.class, hint =
> "rmannibucau-test")
> public class MyListener extends AbstractMavenLifecycleParticipant {
> @Override
> public void afterProjectsRead(final MavenSession session) throws
> MavenExecutionException {
> if (session.getCurrentProject() == null) {
> return;
> }
> session.getProjects().forEach(p -> {
> final Dependency dependency = new Dependency();
> dependency.setGroupId("junit");
> dependency.setArtifactId("junit");
> dependency.setVersion("3.8.1");
> p.getDependencies().add(dependency);
> });
> }
> } {code}
> Without having junit 3.8 in the project pom it should be in the installed pom.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MNG-7067) Ensure produced (consumable) pom takes into account extensions
Romain Manni-Bucau created MNG-7067:
---
Summary: Ensure produced (consumable) pom takes into account
extensions
Key: MNG-7067
URL: https://issues.apache.org/jira/browse/MNG-7067
Project: Maven
Issue Type: Task
Affects Versions: 4.0.0-alpha-1
Reporter: Romain Manni-Bucau
Goal is to have this kind of (build time) extension reflected in the produced
pom:
{code:java}
@Component(role = AbstractMavenLifecycleParticipant.class, hint =
"rmannibucau-test")
public class MyListener extends AbstractMavenLifecycleParticipant {
@Override
public void afterProjectsRead(final MavenSession session) throws
MavenExecutionException {
if (session.getCurrentProject() == null) {
return;
}
session.getProjects().forEach(p -> {
final Dependency dependency = new Dependency();
dependency.setGroupId("junit");
dependency.setArtifactId("junit");
dependency.setVersion("3.8.1");
p.getDependencies().add(dependency);
});
}
} {code}
Without having junit 3.8 in the project pom it should be in the installed pom.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[
https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244013#comment-17244013
]
Romain Manni-Bucau commented on MNG-7045:
-
Ok, here is a small reproducer:
{code:java}
4.0.0
org.apache.maven.its.mng7045
test
1.0
Maven Integration Test :: MNG-7045
Do a maven exec-java which executes some cdi 2.0 code which would fail if
maven leaks cdi-api 1.0.
org.apache.geronimo.specs
geronimo-jcdi_2.0_spec
1.3
org.apache.maven.plugins
maven-compiler-plugin
3.8.1
8
8
UTF-8
org.codehaus.gmavenplus
gmavenplus-plugin
1.11.0
run
process-classes
execute
org.codehaus.groovy
groovy
3.0.7
runtime
{code}
if you run "mvn process-classes" it fails on 3.6.3 and works on
4.0.0-alpha-1-SNAPSHOT.
The point is that as soon as you add decorator/interceptor, reflection will
occur similarly to this main - this is why i dont even start a full container
and just do a reflection check to ensure it uses the api specified in
dependency.
It happens for plugin using ClassRealm as parent classloader of the runtime one
(so exec one can be safe in several cases but not 100%) with the default parent
first strategy.
> Drop CDI API from Maven
> ---
>
> Key: MNG-7045
> URL: https://issues.apache.org/jira/browse/MNG-7045
> Project: Maven
> Issue Type: Bug
> Components: core
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> This is an old leak which triggered a lot of regressions and still triggers
> bugs in mojos.
> Since there is on real justification in maven itself (@Typed is not since
> there are alternative and cdi is not used in any piece of maven), let's drop
> it.
> If a plugin needs it, it already has it since cdi-api is outdated anyway.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243923#comment-17243923 ] Romain Manni-Bucau commented on MNG-7045: - [~michael-o] well, if it is a prerequisite to merge I'll do but it is not CDI specific, this is why Mark said maven shouldn't leak any library except org.apache.maven (or its core backbone) so it is kind of already tested with exportedpackage tests, here the configuration was just wrong. This is why I didn't add a test. Let me know if I must add one or if we are fine with our current coverage. side note: same issue applies to jsr250 but since it didnt move we don't hit it as easily ;) > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Priority: Major > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7045) Drop CDI API from Maven
[ https://issues.apache.org/jira/browse/MNG-7045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243811#comment-17243811 ] Romain Manni-Bucau commented on MNG-7045: - [~michael-o] tomee, meecrowave, weld, camel-cdi, quarkus in some context/config, exec-maven-plugin in java mode, all will fail to use CDI 2 API properly (Instance will not have stream() support for example since it was not in 1.1). Indeed upgrading to cdi-api 2.0 is a workaround in maven but since maven does NOT need this dependency and it creates issue with all implementation there is no point to try to keep it. This always had been a bug and was reported years ago, we were just too slow to fix it - blame me because I guess I was one of the first to face it. Indeed some applications not using overlapping features will run properly but this is still a bug. Also leaking API not provided is another bug (why do we export javax.enterprise and not use it at all except @Typed from memory which is not even needed. Indeed if you have another fix i'm fine with it but I think it is the simplest and less breaking fix to that old bug. > Drop CDI API from Maven > --- > > Key: MNG-7045 > URL: https://issues.apache.org/jira/browse/MNG-7045 > Project: Maven > Issue Type: Bug > Components: core >Reporter: Romain Manni-Bucau >Priority: Major > > This is an old leak which triggered a lot of regressions and still triggers > bugs in mojos. > Since there is on real justification in maven itself (@Typed is not since > there are alternative and cdi is not used in any piece of maven), let's drop > it. > If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-7045) Drop cdi-api from maven
Romain Manni-Bucau created MNG-7045: --- Summary: Drop cdi-api from maven Key: MNG-7045 URL: https://issues.apache.org/jira/browse/MNG-7045 Project: Maven Issue Type: Bug Components: core Reporter: Romain Manni-Bucau This is an old leak which triggered a lot of regressions and still triggers bugs in mojos. Since there is on real justification in maven itself (@Typed is not since there are alternative and cdi is not used in any piece of maven), let's drop it. If a plugin needs it, it already has it since cdi-api is outdated anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MJAR-276) Don't log a warning when jar will be empty and creation is forced
[ https://issues.apache.org/jira/browse/MJAR-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17242174#comment-17242174 ] Romain Manni-Bucau commented on MJAR-276: - PR sent https://github.com/apache/maven-jar-plugin/pull/17 > Don't log a warning when jar will be empty and creation is forced > - > > Key: MJAR-276 > URL: https://issues.apache.org/jira/browse/MJAR-276 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.2.0 >Reporter: Romain Manni-Bucau >Priority: Major > > If user forced the jar creation there is no point warning him the jar will be > empty, it is more than likely it forced it for that exact goal. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MJAR-276) Don't log a warning when jar will be empty and creation is forced
Romain Manni-Bucau created MJAR-276: --- Summary: Don't log a warning when jar will be empty and creation is forced Key: MJAR-276 URL: https://issues.apache.org/jira/browse/MJAR-276 Project: Maven JAR Plugin Issue Type: Bug Affects Versions: 3.2.0 Reporter: Romain Manni-Bucau If user forced the jar creation there is no point warning him the jar will be empty, it is more than likely it forced it for that exact goal. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1798) trimStackTrace should be false by default
[ https://issues.apache.org/jira/browse/SUREFIRE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128914#comment-17128914 ] Romain Manni-Bucau edited comment on SUREFIRE-1798 at 6/9/20, 7:16 AM: --- change pushed [https://github.com/apache/maven-surefire/tree/SUREFIRE-1798] waiting for the build to ensure there was no test on that feature ([https://builds.apache.org/job/maven-box/job/maven-surefire/job/SUREFIRE-1798/]) was (Author: romain.manni-bucau): change pushed [https://github.com/apache/maven-surefire/tree/SUREFIRE-1798] waiting for the build to ensure there was no test on that feature > trimStackTrace should be false by default > - > > Key: SUREFIRE-1798 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1798 > Project: Maven Surefire > Issue Type: Task > Components: Maven Surefire Plugin >Reporter: Romain Manni-Bucau >Priority: Major > > True was intended to clean up the output but it always misses any useful data > so let's set an useful default -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1798) trimStackTrace should be false by default
[ https://issues.apache.org/jira/browse/SUREFIRE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17128914#comment-17128914 ] Romain Manni-Bucau commented on SUREFIRE-1798: -- change pushed [https://github.com/apache/maven-surefire/tree/SUREFIRE-1798] waiting for the build to ensure there was no test on that feature > trimStackTrace should be false by default > - > > Key: SUREFIRE-1798 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1798 > Project: Maven Surefire > Issue Type: Task > Components: Maven Surefire Plugin >Reporter: Romain Manni-Bucau >Priority: Major > > True was intended to clean up the output but it always misses any useful data > so let's set an useful default -- This message was sent by Atlassian Jira (v8.3.4#803005)
