[
https://issues.apache.org/jira/browse/SLING-6344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15708972#comment-15708972
]
Konrad Windszus commented on SLING-6344:
----------------------------------------
Since the {{content-package-maven-plugin}} generates the final filter.xml as
well as the ZIP artifact in the same goal (even in the same method) there is no
easy way to leverage the functionality in the Sling IDE. The possible solutions
which come to my mind are
# Adobe would properly split up filter.xml generation and generation of the
final package into two different goals (the former bound to
{{process-resources}} phase the latter to {{package}} phase) in the
content-package-maven-plugin and make the first goal m2e compliant (i.e.
support incremental builds)
# Sling IDE would just copy the according code from
content-package-maven-plugin to generate the filter.xml
Though 1 is the much cleaner solution it is IMHO less likely to happen soon, so
we probably have to stick to solution 2.
> Support filter.xmls being generated by the content-package-maven-plugin
> -----------------------------------------------------------------------
>
> Key: SLING-6344
> URL: https://issues.apache.org/jira/browse/SLING-6344
> Project: Sling
> Issue Type: Bug
> Components: IDE
> Affects Versions: Sling Eclipse IDE 1.1.0
> Reporter: Konrad Windszus
> Priority: Critical
> Attachments: SLING-6344-v01.patch, SLING-6344-v02.patch
>
>
> The content-package-maven plugin can not only consume a filter.xml from the
> source directory, but also generate or merge filter.xmls. Therefore Sling IDE
> should consider only the filter.xml in the generated artifacts (package). The
> problem with that is, that content-package-maven-plugin does only generate
> that filter.xml when it generates the real package.
> There is one other related issue: In case a filter file is not found, the
> method {{ResourceChangeCommandFactory#getFilterResult}} returns {{ALLOW}}
> while it should return {{DENY}} to not overwrite any nodes in case the filter
> rules could not be determined.
> In my case those two problems lead to a modification of the jcr:primaryType
> of the root node in the JCR from {{rep:root}} to {{nt:unstructured}} and the
> resourceType from {{sling:redirect}} to just being removed which breaks the
> redirect handling.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
