[
https://issues.apache.org/jira/browse/JCRVLT-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16766394#comment-16766394
]
Mark Adamcin commented on JCRVLT-331:
-------------------------------------
[~kwin] I also added similar support for `subPackages` along with an
integration test to verify that it works. The situation with subPackages during
`mvn test` executions is that when the dependency artifact is still pointing to
a target/classes directory, the target/classes directory likely does not
contain the vault properties.xml file, and may have a different vault-work
directory location configured, relative to its target/classes directory.
To solve this, I added logic to the GenerateMetadataMojo to put its configured
workDirectory file into the pluginContext for the mojo at the start of the
plugin execution, using the layout path for the project artifact as the key.
The when generating the subpackage entries for the filter.xml file, logic
attempts to lookup the vault work directory file for each subpackage dependency
artifact, then tries to read the properties.xml file relative to that directory.
Since this issue only occurs during a multimodule build where we expect
subpackages to be identified as dependencies on the main content package
artifact, the maven execution plan will ensure that the dependency modules
reach their generate-metadata goals before the main content package module
does. This should guarantee that the dependency vault work directories and
properties.xml files exist to support inference of the container package filter
paths.
> Incorrected embedded base name used in generate-metadata goal during CLI
> execution of `mvn test`
> ------------------------------------------------------------------------------------------------
>
> Key: JCRVLT-331
> URL: https://issues.apache.org/jira/browse/JCRVLT-331
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
> Affects Versions: package-maven-plugin-1.0.3
> Reporter: Mark Adamcin
> Priority: Major
>
> 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`:
> {code:java}
> [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]{code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
