[ 
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)

Reply via email to