[ 
https://issues.apache.org/jira/browse/JCRVLT-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Adamcin updated JCRVLT-331:
--------------------------------
    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`:
{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.

  was:
The GenerateMetadataMojo class `@Mojo` annotation defines a defaultPhase of 
"prepare-package", which seems appropriate for the behavior of the mojo, which 
includes processing embeds. However, 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`, like `test`. When the filevault plugin is 
configured to embed a dependency built by another module in this situation, 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 
`target/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 multimodule project.

A patch will be attached to correct the lifecycle mapping mismatch.


> 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)

Reply via email to