[
https://issues.apache.org/jira/browse/JCRVLT-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16207052#comment-16207052
]
Tobias Bocanegra edited comment on JCRVLT-209 at 10/18/17 7:54 AM:
-------------------------------------------------------------------
what we want:
- backward compatibility: if a filter.xml is copied to vault-work with the
resource plugin, then it should still "work" correctly.
- if there are any comments in the original filtere source, they should not get
lost.
- if there are filters specified in the pom and in a filter source, they should
get merged.
- if the {{prefix}} property is set, it should be used if no filter is set.
so I think the algorithm is like this:
- if filterFile exist and no {{filter.xml.original}} exists, copy the
filterFile to {{filter.xml.original}}
- if filterSource exists, read the filters into {{sourceFilters}}
- if no filterSource exists, but {{filter.xml.original}} read the filters into
{{sourceFilters}}
- if pom filters exist, merge into {{sourceFilters}}
- apply potential prefixes to {{sourceFilters}}
- generate xml and write to filter.xml
- (extra step: if sourceFilters and filters from original are the same, just
copy back the original. this preserves potential comments in the xml)
- if possible, exclude the {{filter.xml.original}} from the package archive
was (Author: tripod):
what we want:
- backward compatibility: if a filter.xml is copied to vault-work with the
resource plugin, then it should still "work" correctly.
- if there are any comments in the original filtere source, they should not get
lost.
- if there are filters specified in the pom and in a filter source, they should
get merged.
-- if the {{prefix}} property is set, it should be added to all filters.-
- if the {{prefix}} property is set, it should be used if no filter is set.
so I think the algorithm is like this:
- if filterFile exist and no {{filter.xml.original}} exists, copy the
filterFile to {{filter.xml.original}}
- if filterSource exists, read the filters into {{sourceFilters}}
- if no filterSource exists, but {{filter.xml.original}} read the filters into
{{sourceFilters}}
- if pom filters exist, merge into {{sourceFilters}}
- apply potential prefixes to {{sourceFilters}}
- generate xml and write to filter.xml
- (extra step: if sourceFilters and filters from original are the same, just
copy back the original. this preserves potential comments in the xml)
- if possible, exclude the {{filter.xml.original}} from the package archive
> 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
> Assignee: Tobias Bocanegra
>
> 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)
