Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
package-maven-plugin-1.0.3
-
None
-
Patch
Description
The lifecycle-mapping for the `content-package` packaging type included in the plugin attaches the generate-metadata goal to the `process-classes` phase. This results in odd behavior in a multi-module project when the execution phase specified for a build is prior to `package` (i.e. `mvn test`). When the filevault plugin is configured to embed a dependency built by another module in this situation, and when the `<embedded>` element does not declare a `<destFileName>`, it will try to embed the classes directory of that module, since `process-classes` phase is active, but the `package` phase will not be reached.
This error I reached during a `mvn test -B` execution offers a clue to the symptom. In this case, having TWO such embeds introduces a filter path collision because the final artifact name of both modules is reduced to `classes`:
[INFO] --- filevault-package-maven-plugin:1.0.3:generate-metadata (default-generate-metadata) @ oakpal-aem-interactive-apps --- [INFO] Embedding --- Embedded: groupId=net.adamcin.oakpal,artifactId=oakpal-core,type=,classifier=,filter=true,excludeTransitive=false,target=/apps/oakpal-interactive/install/ --- [INFO] Embedding net.adamcin.oakpal:oakpal-core:jar:1.1.14-SNAPSHOT (from /home/travis/build/adamcin/oakpal/core/target/classes) -> jcr_root/apps/oakpal-interactive/install/classes [INFO] Embedding --- Embedded: groupId=net.adamcin.oakpal,artifactId=net.adamcin.oakpal.interactive,type=,classifier=,filter=true,excludeTransitive=false,target=/apps/oakpal-interactive/install/ --- [INFO] Embedding net.adamcin.oakpal:net.adamcin.oakpal.interactive:jar:1.1.14-SNAPSHOT (from /home/travis/build/adamcin/oakpal/aem/net.adamcin.oakpal.interactive/target/classes) -> jcr_root/apps/oakpal-interactive/install/classes [INFO] using meta-inf/vault from /home/travis/build/adamcin/oakpal/aem/interactive-apps/src/main/META-INF/vault [INFO] Loading filter from /home/travis/build/adamcin/oakpal/aem/interactive-apps/src/main/META-INF/vault/filter.xml [INFO] Merging inline filters. ... ... [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 35.480 s [INFO] Finished at: 2019-02-11T18:00:04Z [INFO] Final Memory: 50M/621M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.jackrabbit:filevault-package-maven-plugin:1.0.3:generate-metadata (default-generate-metadata) on project oakpal-aem-interactive-apps: Execution default-generate-metadata of goal org.apache.jackrabbit:filevault-package-maven-plugin:1.0.3:generate-metadata failed: Merging of equal filter roots not allowed for: /apps/oakpal-interactive/install/classes -> [Help 1]
This issue theoretically affects the plugin for all execution phases between `process-classes` and `prepare-package` (inclusive), but the problem is greatest for executions up to the `test` phase, since the other phases in this range are usually not executed across a multi-module project.
In order to support incremental builds which, intentionally, do not proceed to the `package` phase, the GenerateMetadataMojo behavior for constructing the filter for each embedded artifact should not rely on the native filename (`File.getName()`), since that may be temporarily mapped to a folder containing test classes. Instead, users would expect the filter to use the default maven layout base name, by default.
Attachments
Issue Links
- is related to
-
JCRVLT-386 Eclipse/m2e: Could not get metadata for dependencies which are resolved via m2e workspace resolution or for multimodule builds with phases < package
-
- Closed
-
- relates to
-
-
- Closed
-
- links to