You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the base class can only see the protected 'outputDirectory' field in BasicSupport.java, which is set to 'null'... and so we end up defaulting the output directory here.
The loose app support here builds the loose app without considering the liberty-maven-plugin <outputDirectory> config, but within DevMojo, this is where the logic is placing the dev mode-compiled classes.
ENVIRONMENT
Running Maven 3.8.8 on Win 11 with liberty-maven-plugin v3.8 with configuration like:
Problems Experienced by End User
and so it doesn't pick up changes made during the dev mode session, (since dev mode is outputting class files to the outputDirectory location).
Problems In Code
To start, a confusing aspect is the fact that DevMode.java (re)defines/overloads the same
@Parameter
already defined by the BasicSupport.java:DevMode.java
BasicSupport.java
Apparently Maven will only "bind" the XML config to the DevMojo (private) field, but NOT the BasicSupport (protected) field.
So on the path involved in server start, which looks something like this:
the base class can only see the protected 'outputDirectory' field in BasicSupport.java, which is set to 'null'... and so we end up defaulting the output directory here.
Other code problems
The issue: Deploy goal fails (hangs) when using non-default output directory (e.g. with MicroProfile starter config), e.g. running dev mode after server is killed. #1536 can happen if dev mode and the server are killed abruptly. In this case, because the dev mojo calls the deploy mojo through the executor, it can pass the correct 'outputDirectory' config on to the deploy mojo impl. So the validation for deploy is expecting to find messages.log in the location matching the (non-dflt) plugin config... but as mentioned above the real log will be over in the default location.
The loose app support here builds the loose app without considering the liberty-maven-plugin
<outputDirectory>
config, but within DevMojo, this is where the logic is placing the dev mode-compiled classes.Finally, if we were to fix this there seem to be some other hard-coded log locations like https://github.com/OpenLiberty/ci.common/blob/4e720b665a8cd212626c8e98b2a59ac69b62400b/src/main/java/io/openliberty/tools/common/plugins/util/DevUtil.java#L777-L778 which should be considered.
Related Issues
The text was updated successfully, but these errors were encountered: