You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Adam Gent (Jira)" <ji...@apache.org> on 2020/11/25 17:53:00 UTC
[jira] [Updated] (MNG-7033) Excluded projects through -pl should
not need to be in the reactor
[ https://issues.apache.org/jira/browse/MNG-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Gent updated MNG-7033:
---------------------------
Description:
TLDR if you exclude a module using {{!module}} or {{-module}} with {{-pl}} that module needs to somehow be in the resolved reactor.
We have custom build scripts (e.g. shells scripts or makes) that will make a certain subset of the project using {{-pl}}. However some modules we want to always exclude. (Yes we could use profiles but the maintenance of that solution is unacceptable to us).
Thus if we do something like this:
{code:sh}
mvn install -pl "snaphop-cache,-snaphop-http" -amd
{code}
We may or not may not get the following depending on whether snaphop-cache has a downstream dependency on snaphop-http:
{code}
[INFO] Scanning for projects...
[ERROR] [ERROR] Could not find the selected project in the reactor: snaphop-http @
[ERROR] Could not find the selected project in the reactor: snaphop-http -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
{code}
Thus it becomes nontrivial to exclude a module. One has to know whether or not {{snaphop-cache}} will trigger {{snaphop-http}} to be in the reactor.
Furthermore the command may fail if some one changes dependencies (not project structure or modules).
I find that to be alarming. {{-pl}} shouldn't fail if dependencies change.
Its notable that the following is completely fine:
{code:sh}
mvn install -pl "snaphop-cache,snaphop-http" -amd
{code}
Which is confusing and inconsistent that one can't then add {{-}}.
My recommendation is if -pl can't find the exclusion module in the currently selected reactor is just ignores it or perhaps issues a warning.
was:
TLDR if you exclude a module using {{!module}} or {{-module}} with {{-pl}} that module needs to somehow be in the resolved reactor.
We have custom build scripts (e.g. shells scripts or makes) that will make a certain subset of the project using {{-pl}}. However some modules we want to always exclude. (Yes we could use profiles but the maintenance of that solution is unacceptable to us).
Thus if we do something like this:
{code:sh}
mvn install -pl "snaphop-cache,-snaphop-http" -amd
{code}
We may or not may not get the following depending on whether snaphop-cache has a downstream dependency on snaphop-http:
{code}
[INFO] Scanning for projects...
[ERROR] [ERROR] Could not find the selected project in the reactor: snaphop-http @
[ERROR] Could not find the selected project in the reactor: snaphop-http -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
{code}
Thus it becomes nontrivial to exclude a module. One has to know whether or not {{snaphop-cache}} will trigger {{snaphop-http}} to be in the reactor.
Furthermore the command may fail if some one changes dependencies (not project structure or modules).
I find that to be alarming. {{-pl}} shouldn't fail if dependencies change.
My recommendation is if -pl can't find the exclusion module in the currently selected reactor is just ignores it or perhaps issues a warning.
> Excluded projects through -pl should not need to be in the reactor
> ------------------------------------------------------------------
>
> Key: MNG-7033
> URL: https://issues.apache.org/jira/browse/MNG-7033
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
> Affects Versions: 3.6.0, 3.6.1, 3.6.3
> Reporter: Adam Gent
> Priority: Major
>
> TLDR if you exclude a module using {{!module}} or {{-module}} with {{-pl}} that module needs to somehow be in the resolved reactor.
> We have custom build scripts (e.g. shells scripts or makes) that will make a certain subset of the project using {{-pl}}. However some modules we want to always exclude. (Yes we could use profiles but the maintenance of that solution is unacceptable to us).
> Thus if we do something like this:
> {code:sh}
> mvn install -pl "snaphop-cache,-snaphop-http" -amd
> {code}
> We may or not may not get the following depending on whether snaphop-cache has a downstream dependency on snaphop-http:
> {code}
> [INFO] Scanning for projects...
> [ERROR] [ERROR] Could not find the selected project in the reactor: snaphop-http @
> [ERROR] Could not find the selected project in the reactor: snaphop-http -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MavenExecutionException
> {code}
> Thus it becomes nontrivial to exclude a module. One has to know whether or not {{snaphop-cache}} will trigger {{snaphop-http}} to be in the reactor.
> Furthermore the command may fail if some one changes dependencies (not project structure or modules).
> I find that to be alarming. {{-pl}} shouldn't fail if dependencies change.
> Its notable that the following is completely fine:
> {code:sh}
> mvn install -pl "snaphop-cache,snaphop-http" -amd
> {code}
> Which is confusing and inconsistent that one can't then add {{-}}.
> My recommendation is if -pl can't find the exclusion module in the currently selected reactor is just ignores it or perhaps issues a warning.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)