-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Maven multi-module dev mode with only 1 "server module" even with >1 module with no downstream modules #1606
Comments
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). |
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 |
Haven't forgotten about this issue.
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. 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 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. |
Using the 'skip' config item was exactly what I was thinking of here, I see now that it got mangled in my previous comment.
I don't see a lot of added value in this approach, please see below for my ideal situation.
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 |
@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.
The text was updated successfully, but these errors were encountered: