jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Adamcin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCRVLT-331) Incorrected embedded base name used in generate-metadata goal during CLI execution of `mvn test`
Date Tue, 12 Feb 2019 19:58:00 GMT

    [ 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] ------------------------------------------------------------------------
> [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
> 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

View raw message