[
https://issues.apache.org/jira/browse/JCRVLT-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207140#comment-16207140
]
Tobias Bocanegra commented on JCRVLT-209:
-----------------------------------------
well, I disagree. most of the usages so far, are quite simple; just define the
vault-work in the resources, and have a more or less empty plugin config:
{noformat}
<build>
<resources>
<resource>
<directory>${basedir}/META-INF</directory>
<targetPath>../vault-work/META-INF</targetPath>
</resource>
<resource>
<directory>${basedir}/jcr_root</directory>
<targetPath>.</targetPath>
</resource>
</resources>
<plugins>
<plugin>
<groupId>com.day.jcr.vault</groupId>
<artifactId>content-package-maven-plugin</artifactId>
<extensions>true</extensions>
<version>0.5.14</version>
</plugin>
</plugins>
</build>
{noformat}
additionally, there are many more files that potentially go into the
META-INF/vault directory, like the nodetypes, privileges, entire package
definition trees, etc. so using a deliberate filter.xml is rather the norm,
than having everything in the pom.
so maybe the problem is not the filterSource alone, but the lacking capability
to specify the meta-inf source. so we can do away from specifying the meta-info
in the resource plugin. this is IMO also the goal of JCRVLT-210.
anyways, I don't think that the checksum would help here. because if someone
modifies the filters in the pom, the content would also be different.
another alternative would be, to more or less keep the current way, but to set
the last-modified date of the filter.xml to 0, so that the next resource-plugin
run would update it. so no need to 'clean':
- if last modified of {{vault-work/META-INF/vault/filter.xml == 0}} -> delete it
- by default, set the {{filterSource = vault-work/META-INF/vault/filter.xml}}
- if there are no filters defined in the pom, no nothing
- if there are filters defined, merge them with the {{filterSource}} and write
to {{vault-work/META-INF/vault/filter.xml}}
- update the last modified time of the filters file to 0
> Always write to the filter.xml inside the vaultDir but never to
> filter-plugin-generated.xml
> -------------------------------------------------------------------------------------------
>
> Key: JCRVLT-209
> URL: https://issues.apache.org/jira/browse/JCRVLT-209
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: package maven plugin
> Reporter: Konrad Windszus
>
> Currently in case the filter configuration of the plugin has been changed and
> there is already a {{filter.xml}} in the {{vaultDir}} this is not being
> overwritten. Instead a new file named {{filter-plugin-generated.xml}} is
> being generated which is irrelevant for the package
> (https://github.com/apache/jackrabbit-filevault-package-maven-plugin/blob/15baff9be241a851d4ad36e53336cec1d5613c9d/plugin/src/main/java/org/apache/jackrabbit/filevault/maven/packaging/VaultMojo.java#L372).
> IMHO this is not a clever default behaviour because it forces to always use
> {{mvn clean}} in case of filter definition changes.
> In case someone want's to really manually modify the filter.xml the parameter
> {{filterSource}} should be used instead, but in any case the generated
> {{filter.xml}} inside the {{vaultDir}} should contain the latest generated
> filter file.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
