slachiewicz opened a new issue, #579: URL: https://github.com/apache/maven-ear-plugin/issues/579
Tools that lay out an EAR without running `ear:ear`, for example liberty-maven-plugin for its loose applications, need the path of every module inside the EAR. Today they rebuild it from this plugin's configuration: `outputFileNameMapping`, `defaultLibBundleDir` and the `uri`, `bundleDir` and `bundleFileName` overrides under `<modules>`. liberty-maven-plugin does this in [`LooseEarApplication.getModuleUri`](https://github.com/OpenLiberty/ci.maven/blob/main/liberty-maven-plugin/src/main/java/io/openliberty/tools/maven/applications/LooseEarApplication.java), about 80 lines that follow this plugin's rules only approximately; for example, it matches modules by groupId and artifactId but not by type or classifier. `generate-application-xml`, which liberty-maven-plugin already runs, computes these paths to write `application.xml`, but library jars appear there only with `includeLibInApplicationXml`. Proposal: an optional `moduleMapFile` parameter on `generate-application-xml`. When it is set, the goal writes a properties file with one entry per module in the EAR, keyed by `groupId:artifactId:type` or `groupId:artifactId:type:classifier`, with the module's path in the EAR as the value. The lines are sorted and there is no timestamp, so the file is reproducible. Nothing changes when the parameter is not set. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
