Skip to content

In dev mode, non-dflt <outputDirectory> config doesn't result in logs/workarea in this location, and also breaks hot code replace #1684

Open
@scottkurz

Description

@scottkurz

ENVIRONMENT

Running Maven 3.8.8 on Win 11 with liberty-maven-plugin v3.8 with configuration like:

<configuration>
    <outputDirectory>target/myoutput</outputDirectory>
</configuration>

Problems Experienced by End User

  1. logs/workarea still go to default location: target/liberty/wlp/usr/servers/defaultServer/
  2. The loose app uses a mapping like
    <dir sourceOnDisk="C:\myapp\target\classes" targetInArchive="/WEB-INF/classes"/>

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

   /**
     * The directory for compiled classes.
     */
    @Parameter(readonly = true, required = true, defaultValue = "${project.build.outputDirectory}")
    private File outputDirectory;

BasicSupport.java

    @Parameter(property = "outputDirectory")
    protected File outputDirectory = null;

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:

  ServerTask(AbstractTask).setOutputDir(File) line: 157	
  DevMojo(StartDebugMojoSupport).initializeJava() line: 181	
  DevMojo$DevMojoUtil.getServerTask() line: 444	
  DevMojo$DevMojoUtil(DevUtil).startServer(boolean, boolean) line: 747	

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

  1. 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.

  2. 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.

  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions