Open scottkurz opened 1 year ago
This would be a great feature to have, it would save us from running 'mvn liberty:dev -pl
As an alternative: couldn't the liberty-maven-plugin
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.
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.
@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.
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)
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).
@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.
@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.
As a first step, let's explore a fix to both:
But let's not (yet) pursue the idea of explicitly configuring the server module.
Recreate
mvn liberty:dev
# Good, worksmvn liberty:dev
Get error like:
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.