[ 
https://issues.apache.org/jira/browse/MNG-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tamas Cservenak updated MNG-8283:
---------------------------------
    Description: 
Rework CLI, how Maven "boots". Currently MavenCLI is under-maintained, full of 
tech debt, and blurs boundaries between arg parsing, DI booting and invoking 
Maven. Hence, is not reusable, like for mvnd where a mutilated copy of this 
class was needed.
MavenCLIng should alleviate all these problems.

Rationale:

New CLI for Maven. Goals are reusability, extensibility and easier 
embeddability (a la mvnd). If you build this branch, you will end up with Maven 
distro that uses "new" `maven-cli:org.apache.maven.cling.MavenCling` class as 
entry point instead of "old" `maven-embedder:org.apache.maven.cli.MavenCli`.

First step is to make "pretty much equivalent" capable CLI as compared to 
"old", with some exceptions:
* "encryption" ops are gone, those should be in separate tool anyway
* "deprecated and unsupported" CLI options like `-llr` present ONLY to make 
Maven fail are gone (now Arg parser will fail).

Current state of affairs is messy, MavenCli mixes everything it can, contains 
interleaved logic for bootstrapping, arg parsing, default logic and executing 
Maven. First goal is to clean this up.

Commons CLI are also hidden in this PR, so is ClassWorlds. This basically opens 
up way to have "alternative" CLI arguments parsers as well.

Currently the "local" (CLI) flow is this:

{noformat}
arg[] -> localParser -> Request -> localInvoker -> maven runs (in situ)
{noformat}

But the point is if you "come up" somehow with a Request instance, one can also 
do just:

{noformat}
Request -> invoker -> maven runs (somewhere)
{noformat}

Local parser:
* parses CLI args
* infers the defaults
* creates Request object that contains all information needed to run Maven
* can be reused outside of CLI as well
* does NOT fiddle with Plexus, logging, etc.

Local invoker:
* accepts Request object
* deals with configuring env (logging, etc), creating DI container, and running 
Maven ONLY

There are some experiments ongoing as well, like {{ForkedInvoker}} is, we can 
now make also {{Tool}}s.

  was:
Rework CLI, how Maven "boots". Currently MavenCLI is under-maintained, full of 
tech debt, and blurs boundaries between arg parsing, DI booting and invoking 
Maven. Hence, is not reusable, like for mvnd where a mutilated copy of this 
class was needed.
MavenCLIng should alleviate all these problems.

Rationale:

New CLI for Maven. Goals are reusability, extensibility and easier 
embeddability (a la mvnd). If you build this branch, you will end up with Maven 
distro that uses "new" `maven-cli:org.apache.maven.cling.MavenCling` class as 
entry point instead of "old" `maven-embedder:org.apache.maven.cli.MavenCli`.

First step is to make "pretty much equivalent" capable CLI as compared to 
"old", with some exceptions:
* "encryption" ops are gone, those should be in separate tool anyway
* "deprecated and unsupported" CLI options like `-llr` present ONLY to make 
Maven fail are gone (now Arg parser will fail).

Current state of affairs is messy, MavenCli mixes everything it can, contains 
interleaved logic for bootstrapping, arg parsing, default logic and executing 
Maven. First goal is to clean this up.

Commons CLI are also hidden in this PR, so is ClassWorlds. This basically opens 
up way to have "alternative" CLI arguments parsers as well.

**Note: naming, as always is off. We just could not come up with better names, 
so "invoker" is used, but they are too generic, and they clash with existing 
Maven Invoker. But have to say, that this work could replace Maven Invoker on 
longer run with some much simpler and cleaner solution**.

Currently the "local" (CLI) flow is this:

{noformat}
arg[] -> localParser -> Request -> localInvoker -> maven runs (in situ)
{noformat}

But the point is if you "come up" somehow with a Request instance, one can also 
do just:

{noformat}
Request -> invoker -> maven runs (somewhere)
{noformat}

Local parser:
* parses CLI args
* infers the defaults
* creates Request object that contains all information needed to run Maven
* can be reused outside of CLI as well
* does NOT fiddle with Plexus, logging, etc.

Local invoker:
* accepts Request object
* deals with configuring env (logging, etc), creating DI container, and running 
Maven ONLY

There are some experiments ongoing as well, like {{ForkedInvoker}} is, we can 
now make also {{Tool}}s.


> Maven CLIng, the "new gen" CLI
> ------------------------------
>
>                 Key: MNG-8283
>                 URL: https://issues.apache.org/jira/browse/MNG-8283
>             Project: Maven
>          Issue Type: Task
>          Components: Command Line
>            Reporter: Tamas Cservenak
>            Priority: Major
>             Fix For: 4.0.0, 4.0.0-beta-5
>
>
> Rework CLI, how Maven "boots". Currently MavenCLI is under-maintained, full 
> of tech debt, and blurs boundaries between arg parsing, DI booting and 
> invoking Maven. Hence, is not reusable, like for mvnd where a mutilated copy 
> of this class was needed.
> MavenCLIng should alleviate all these problems.
> Rationale:
> New CLI for Maven. Goals are reusability, extensibility and easier 
> embeddability (a la mvnd). If you build this branch, you will end up with 
> Maven distro that uses "new" `maven-cli:org.apache.maven.cling.MavenCling` 
> class as entry point instead of "old" 
> `maven-embedder:org.apache.maven.cli.MavenCli`.
> First step is to make "pretty much equivalent" capable CLI as compared to 
> "old", with some exceptions:
> * "encryption" ops are gone, those should be in separate tool anyway
> * "deprecated and unsupported" CLI options like `-llr` present ONLY to make 
> Maven fail are gone (now Arg parser will fail).
> Current state of affairs is messy, MavenCli mixes everything it can, contains 
> interleaved logic for bootstrapping, arg parsing, default logic and executing 
> Maven. First goal is to clean this up.
> Commons CLI are also hidden in this PR, so is ClassWorlds. This basically 
> opens up way to have "alternative" CLI arguments parsers as well.
> Currently the "local" (CLI) flow is this:
> {noformat}
> arg[] -> localParser -> Request -> localInvoker -> maven runs (in situ)
> {noformat}
> But the point is if you "come up" somehow with a Request instance, one can 
> also do just:
> {noformat}
> Request -> invoker -> maven runs (somewhere)
> {noformat}
> Local parser:
> * parses CLI args
> * infers the defaults
> * creates Request object that contains all information needed to run Maven
> * can be reused outside of CLI as well
> * does NOT fiddle with Plexus, logging, etc.
> Local invoker:
> * accepts Request object
> * deals with configuring env (logging, etc), creating DI container, and 
> running Maven ONLY
> There are some experiments ongoing as well, like {{ForkedInvoker}} is, we can 
> now make also {{Tool}}s.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to