Support Maven multi-module dev mode with only 1 "server module" even with >1 module with no downstream modules

[scottkurz]

Recreate

1. git clone git@github.com:OpenLiberty/guide-maven-multimodules; cd guide-maven-multimodules/finish
2. Run mvn liberty:dev # Good, works
3. Add a new module in a subdir of 'finish', e.g. mvn archetype:generate -Dfilter=org.apache.maven.archetypes: (run interactively, picked number 11)
4. Add the subdir to the finish/pom.xml in
5. Run mvn liberty:dev

Get error like:

[ERROR] Failed to execute goal io.openliberty.tools:liberty-maven-plugin:3.5.1:dev (default-cli) on project guide-maven-multimodules: Found multiple independent modules in the Reactor build order: [ear, mysite-artifact]. Specify the module containing the Liberty configuration that you want to use for the server by including the following parameters in the Maven command: -pl -am -> [Help 1]

We should be able to detect that there is only one "server module" to run dev mode from and filter out the 'mysite-artifact' in my example.

The "real world" use case could involve any number of things: test, Docker, doc, site, whatever. Perhaps it doesn't truly need to be part of the same reactor build as the ear/jar/war modules even though it shares a parent with them for properties, and dependency management, but someone went down the path of including it anyway and is tied into that decision.

[m-schutte-ohra-nl]

This would be a great feature to have, it would save us from running 'mvn liberty:dev -pl -am'. Detection could be done by looking for existence of src/main/liberty/config (or whatever 'configDirectory' points at).

[m-schutte-ohra-nl]

As an alternative: couldn't the liberty-maven-plugintrue configuration be used to exclude modules ? This would only require a one time setup in a module that is not intended as a 'server module', which is much more convenient than constantly having to provide the -pl module -am parameters to liberty:dev

[scottkurz]

Haven't forgotten about this issue.

As an alternative: couldn't the liberty-maven-plugintrue configuration be used to exclude modules ?

Sounds like that could be a good idea. There is in fact already a 'skip' for every liberty-maven-plugin goal. Perhaps it should be leveraged so that a module configured with skip isn't included as one of the "multiple independent modules" causing ambiguity.

It's maybe not quite a "bug" that it doesn't already have this effect, because the error would typically be thrown when running the aggregator module, rather than the module configured with the skip. But perhaps the aggregator validation should be relaxed.

It seems like we could make the case this that this should/could be done independently of any further enhancement in this space.

[scottkurz]

Another idea would be to have a new plugin parm, e.g.

            <plugin>
                <groupId>io.openliberty.tools</groupId>
                <artifactId>liberty-maven-plugin</artifactId>
                <configuration>
                    <devModule>war</devModule>

with, say a user property like liberty.dev so run, e.g. -Dliberty.dev=war

The XML parameter would only be useful in cases where the config was applied to the aggregator module itself. E.g. in cases with a shared aggregator and parent. (Though we could reuse the technique used in dev mode of reading the config from either plugins OR pluginManagement config).

The user property isn't actually less typing than -pl war -am though it might be more "familiar"-looking to a new user and less esoteric looking.

LOOKING FOR FEEDBACK

@m-schutte-ohra-nl I'm wondering if you could say a bit more about your use cases(s) here.

What does your project look like such that you're running up against this limitation?

Is it that you have certain "leaf" nodes that are useful to include in the bigger project scope, but have nothing to do directly with deploying the app to Liberty? Or maybe you have multiple Liberty server modules but you are happy to work with only one at a time (so don't mind adding this to the pom.xml)?

Thanks for adding your comments. We appreciate your input on this issue.

[m-schutte-ohra-nl]

Haven't forgotten about this issue.

As an alternative: couldn't the liberty-maven-plugintrue configuration be used to exclude modules ?

Sounds like that could be a good idea. There is in fact already a 'skip' for every liberty-maven-plugin goal. Perhaps it should be leveraged so that a module configured with skip isn't included as one of the "multiple independent modules" causing ambiguity.

It's maybe not quite a "bug" that it doesn't already have this effect, because the error would typically be thrown when running the aggregator module, rather than the module configured with the skip. But perhaps the aggregator validation should be relaxed.

It seems like we could make the case this that this should/could be done independently of any further enhancement in this space.

Using the 'skip' config item was exactly what I was thinking of here, I see now that it got mangled in my previous comment.

Another idea would be to have a new plugin parm, e.g.

            <plugin>
                <groupId>io.openliberty.tools</groupId>
                <artifactId>liberty-maven-plugin</artifactId>
                <configuration>
                    <devModule>war</devModule>

with, say a user property like liberty.dev so run, e.g. -Dliberty.dev=war

The XML parameter would only be useful in cases where the config was applied to the aggregator module itself. E.g. in cases with a shared aggregator and parent. (Though we could reuse the technique used in dev mode of reading the config from either plugins OR pluginManagement config).

The user property isn't actually less typing than -pl war -am though it might be more "familiar"-looking to a new user and less esoteric looking.

I don't see a lot of added value in this approach, please see below for my ideal situation.

LOOKING FOR FEEDBACK

@m-schutte-ohra-nl I'm wondering if you could say a bit more about your use cases(s) here.

What does your project look like such that you're running up against this limitation?

Is it that you have certain "leaf" nodes that are useful to include in the bigger project scope, but have nothing to do directly with deploying the app to Liberty? Or maybe you have multiple Liberty server modules but you are happy to work with only one at a time (so don't mind adding this to the pom.xml)?

Thanks for adding your comments. We appreciate your input on this issue.

Our projects all share a common structure which looks like this:

ProjectParent (this pom inherits from a CompanyParent)

• ProjectWAR (web module)
• ProjectEAR (ear module)
• ProjectDIST (this project contains the liberty-maven-plugin files in src/main/liberty/config)
• ProjectTEST (project with test code to run against the main application)

These 4 subprojects are modules of ProjectParent and also have it as their parent.

We need to use 'mvn liberty:dev -pl ProjectDIST -am' because liberty-maven-plugin can't decide between ProjectDIST and ProjectTEST.

What would be ideal for us is to have liberty-maven-plugin ignore any project with skip set to true, because we could add that to ProjectTEST or even to a specific profile in CompanyParent that we set to activate on projects of type TEST (we can do that based on presence of specific files in these projects).

[scottkurz]

@m-schutte-ohra-nl thank you for the additional detail.

Is your "ProjectTEST" module using 'jar' packaging type? It seems like we might be able to exclude jar packaging from consideration, which would then seem to solve your use case without even any skip config.

That still leaves us 'pom', 'liberty-assembly' packaging types as well as 'ear', 'war' to deal with, so the rest of the skip discussion might still apply.

I can see that the -Dliberty.dev=war option wouldn't be useful for your use case, but could still be for a project like the JPA guide https://github.com/OpenLiberty/guide-jpa-intro/tree/prod/finish with >1 microservice each with a separate Liberty server.

[m-schutte-ohra-nl]

@scottkurz Yes it does. It would be great if you could skip jar packaging always, but as I explained using skip config is quite OK for us too.

[scottkurz]

As a first step, let's explore a fix to both:

1. Honor the existing 'skip' config for the run/dev goals or the plugin config as a whole. This is mentioned in this comment: Support Maven multi-module dev mode with only 1 "server module" even with >1 module with no downstream modules #1606 (comment). There may still be some ambiguities in the rules needed to specify behavior across all use cases, so we should include a doc update specifying these (and tests).
2. Exclude 'jar' packaging types from consideration in deciding if there is >1 module with no downstream modules: Support Maven multi-module dev mode with only 1 "server module" even with >1 module with no downstream modules #1606 (comment)

But let's not (yet) pursue the idea of explicitly configuring the server module.