Expand my Community achievements bar.

SOLVED

Interesting Error with filevault-package-maven-plugin:1.0.3:generate-metadata

Avatar

Level 2

Has anyone experienced an error when doing a maven build?

Giancarlo_at_KD_0-1578799175984.png

My project structure is common stuff:

/
   /apps
   /conf

The filter.xml in /META-INF/vault/filter.xml

<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
    <filter root="/conf/testproj" mode="merge"/>
    <filter root="/apps/testproj" mode="merge"/>
</workspaceFilter>

After doing a maven build (clean, then install) the error is

[INFO] Loading filter from /projects/my-view/src/main/content/META-INF/vault/filter.xml
[ERROR] 1 error(s) detected during dependency analysis.
1 error(s) detected during dependency analysis.
Filter root's ancestor '/conf' is not covered by any of the specified dependencies.

Not sure if the error message makes sense, since I have no dependencies on the view (or ui.apps). This behavior was reported already for the vault plugin 0.5.4.

Interesting is, that if I create a different Maven module, like e.g. ui.content, add a pom-dependency to the view (or ui.apps), manage /conf with that module, then the vault plugin seems to work.

 

Therefore my question: Is there indeed a dependency error (what dependency are we talking about) or is this a bug similar to what was reported for the vault plugin 0.5.4?

1 Accepted Solution

Avatar

Correct answer by
Level 2

Seems I can answer my own question...
In the AEM Maven archetype 22 there is a module called repository-structure. The module's description says it all:

Empty package that defines the structure of the Adobe Experience Manager repository the Code packages in this project deploy into.
Any roots in the Code packages of this project should have their parent enumerated in the Filters list below.

You have to define the /conf as "root":

<build>
<plugins>
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>>
</properties>
<filters>

<!-- /apps root -->
<filter><root>/apps</root></filter>

<!-- Common overlay roots -->
<filter><root>/apps/sling</root></filter>
<filter><root>/apps/cq</root></filter>
<filter><root>/apps/dam</root></filter>
<filter><root>/apps/wcm</root></filter>
<filter><root>/apps/msm</root></filter>

<!-- Immutable context-aware configurations -->
<filter><root>/apps/settings</root></filter>

<filter><root>/conf</root></filter>
</filters>
</configuration>
</plugin>
</plugins>
</build>

Now building the view (or ui.apps) module in which /conf is treated like a code folder, e.g. for editable templates, the Maven build will work with no errors.

 

So no bug, just the typical "Saturday night disturbances"...

View solution in original post

6 Replies

Avatar

Correct answer by
Level 2

Seems I can answer my own question...
In the AEM Maven archetype 22 there is a module called repository-structure. The module's description says it all:

Empty package that defines the structure of the Adobe Experience Manager repository the Code packages in this project deploy into.
Any roots in the Code packages of this project should have their parent enumerated in the Filters list below.

You have to define the /conf as "root":

<build>
<plugins>
<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>>
</properties>
<filters>

<!-- /apps root -->
<filter><root>/apps</root></filter>

<!-- Common overlay roots -->
<filter><root>/apps/sling</root></filter>
<filter><root>/apps/cq</root></filter>
<filter><root>/apps/dam</root></filter>
<filter><root>/apps/wcm</root></filter>
<filter><root>/apps/msm</root></filter>

<!-- Immutable context-aware configurations -->
<filter><root>/apps/settings</root></filter>

<filter><root>/conf</root></filter>
</filters>
</configuration>
</plugin>
</plugins>
</build>

Now building the view (or ui.apps) module in which /conf is treated like a code folder, e.g. for editable templates, the Maven build will work with no errors.

 

So no bug, just the typical "Saturday night disturbances"...

But this will overwrite the whole /conf folder. So if you have other projects with editable templates, they will not exists anymore, after installation. I've tested it on AEM 6.4.8.1. I'm still searching for a solution.

Avatar

Level 2
Same issue is happening with me. If I add filter as mentioned above, whole directory is getting replaced. Any help would be highly appreciated.

Avatar

Level 3
our solution was to create a content (ui.content) package for things like /conf or /content. Same as in the wknd Project. https://helpx.adobe.com/ch_de/experience-manager/kt/sites/using/getting-started-wknd-tutorial-develo... You can't mix up /conf folder under /apps. they have to be separated completely (new folder structure). Still don't know where to put the /etc/map folder now

Avatar

Level 2

Have you tried to set the "mode" in the filter?

For example:

<filter root="/conf/myproject" mode="merge"/>

IIRC mode="replace" is the default mode. This will indeed replace the content of /conf/myproject.

 

Some notes from the Jackrabbit Filter page:

  • mode=mergeExisting content is not modified, i.e. only new content is added and none is deleted or modified. Note though that "merge" is deprecated and is replaced by merge_properties.
  • mode=replace: Default mode. Existing content is replaced completely by the imported content.
  • mode=update: Existing content is updated, new content is added and none is deleted. Note though that "merge" is deprecated and is replaced by update_properties.

Avatar

Level 1

trying to help out anyone stuck with this: 

per the pom in the wknd guide see validatorSettings:



<plugin>
<groupId>org.apache.jackrabbit</groupId>
<artifactId>filevault-package-maven-plugin</artifactId>
<configuration>
<properties>
<cloudManagerTarget>none</cloudManagerTarget>
</properties>
<group>com.adobe.aem.guides</group>
<name>aem-guides-wknd.ui.content</name>
<packageType>content</packageType>
<accessControlHandling>merge</accessControlHandling>
<validatorsSettings>
<!-- disable nodetype validation as workaround until JCRVLT-463 got fixed -->
<jackrabbit-nodetypes>
<isDisabled>true</isDisabled>
</jackrabbit-nodetypes>
<jackrabbit-filter>
<options>
<validRoots>/conf,/content,/content/experience-fragments,/content/dam,/content/cq:tags</validRoots>
</options>
</jackrabbit-filter>
</validatorsSettings>

re: https://github.com/adobe/aem-guides-wknd/blob/main/ui.content/pom.xml 

 

This ultimately worked for me to define a single scope filter once the root was defined. 

        <plugin>
                <groupId>org.apache.jackrabbit</groupId>
                <artifactId>filevault-package-maven-plugin</artifactId>
                <configuration>
                    <properties>
                        <cloudManagerTarget>none</cloudManagerTarget>
                    </properties>
                    <filters>
                        <!-- filter root -->
                        <filter><root>/apps/some/path/my-scoped-filter-package-path</root></filter>
                    </filters>
                    <validatorsSettings>
                        <!-- disable nodetype validation as workaround until JCRVLT-463 got fixed -->
                        <jackrabbit-nodetypes>
                            <isDisabled>true</isDisabled>
                        </jackrabbit-nodetypes>
                        <jackrabbit-filter>
                            <options>
                                <validRoots>/apps/some/path</validRoots>
                            </options>
                        </jackrabbit-filter>
                    </validatorsSettings>
                    <group>com.my.org</group>
                    <name>my.ui.apps</name>
                    <packageType>application</packageType>
                </configuration>
            </plugin>

 

Note: this project had no pre-existing filter.xml as a reference it's all defined in the pom.xml spec and gets generated when maven builds the package.