[
https://issues.apache.org/jira/browse/MNG-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8462:
---------------------------------
Description:
Current stance is way better what MavenCli was, but still is quite dirty (and
problematic):
* context is "naked", is not encapsulated and is really just a mixed bag of
exposed data fields and some methods
* invoker reentrancy is problematic, as it is coupled to value (null/non-null)
of context "naked" fields, causes issues like MNG-8461 was
It should be refactored:
* if you consider, we have "stages" executing
* "stage methods" should be aware are they "first time" or "re entering" (or
they could be just "do always")
* context should be encapsulated
* context should be aware of stage when fields are set (so they could "unset" a
stage?)
* context should be "forked" (in scenario similar to MNG-8461) when context is
to be reused but should not affect "main stages", this could also simplify
reentrancy/residency
Current stages could be (are defined already somewhat):
{noformat}
protected int doInvoke(C context) throws Exception {
pushCoreProperties(context);
pushUserProperties(context);
configureLogging(context);
createTerminal(context);
activateLogging(context);
helpOrVersionAndMayExit(context);
preCommands(context);
container(context);
postContainer(context);
pushUserProperties(context); // after PropertyContributor SPI
lookup(context);
init(context);
postCommands(context);
settings(context);
return execute(context);
}
{noformat}
Basically "stage methods" could just be tracking "past stages" and depending on
state (first time? re entering stage?) could invoke/perform proper code
(instead to tie it to context field value).
was:
Current stance is way better what MavenCli was, but still is quite dirty (and
problematic):
* context is "naked", is not encapsulated and is really just a mixed bag of
exposed data fields and some methods
* invoker reentrancy is problematic, as it is coupled to value (null/non-null)
of context "naked" fields, causes issues like MNG-8461 was
It should be refactored:
* if you consider, we have "stages" executing
* "stage methods" should be aware are they "first time" or "re entering" (or
they could be just "do always")
* context should be encapsulated
* context should be aware of stage when fields are set (so they could "unset" a
stage?
* context should be "forked" (in scenario similar to MNG-8461) when context is
to be reused but should not affect "main stages", this could also simplify
reentrancy/residency
Current stages could be (are defined already somewhat):
{noformat}
protected int doInvoke(C context) throws Exception {
pushCoreProperties(context);
pushUserProperties(context);
configureLogging(context);
createTerminal(context);
activateLogging(context);
helpOrVersionAndMayExit(context);
preCommands(context);
container(context);
postContainer(context);
pushUserProperties(context); // after PropertyContributor SPI
lookup(context);
init(context);
postCommands(context);
settings(context);
return execute(context);
}
{noformat}
Basically "stage methods" could just be tracking "past stages" and depending on
state (first time? re entering stage?) could invoke/perform proper code
(instead to tie it to context field value).
> Refactor maven-cli:Invoker and/or Context
> -----------------------------------------
>
> Key: MNG-8462
> URL: https://issues.apache.org/jira/browse/MNG-8462
> Project: Maven
> Issue Type: Task
> Components: Command Line
> Reporter: Tamas Cservenak
> Priority: Major
>
> Current stance is way better what MavenCli was, but still is quite dirty (and
> problematic):
> * context is "naked", is not encapsulated and is really just a mixed bag of
> exposed data fields and some methods
> * invoker reentrancy is problematic, as it is coupled to value
> (null/non-null) of context "naked" fields, causes issues like MNG-8461 was
> It should be refactored:
> * if you consider, we have "stages" executing
> * "stage methods" should be aware are they "first time" or "re entering" (or
> they could be just "do always")
> * context should be encapsulated
> * context should be aware of stage when fields are set (so they could "unset"
> a stage?)
> * context should be "forked" (in scenario similar to MNG-8461) when context
> is to be reused but should not affect "main stages", this could also simplify
> reentrancy/residency
> Current stages could be (are defined already somewhat):
> {noformat}
> protected int doInvoke(C context) throws Exception {
> pushCoreProperties(context);
> pushUserProperties(context);
> configureLogging(context);
> createTerminal(context);
> activateLogging(context);
> helpOrVersionAndMayExit(context);
> preCommands(context);
> container(context);
> postContainer(context);
> pushUserProperties(context); // after PropertyContributor SPI
> lookup(context);
> init(context);
> postCommands(context);
> settings(context);
> return execute(context);
> }
> {noformat}
> Basically "stage methods" could just be tracking "past stages" and depending
> on state (first time? re entering stage?) could invoke/perform proper code
> (instead to tie it to context field value).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
