[ 
https://issues.apache.org/jira/browse/SLING-6344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15815644#comment-15815644
 ] 

Konrad Windszus commented on SLING-6344:
----------------------------------------

Yes, I agree. IMHO we should disable a) syncing b) explicit import and c) 
explicit export. At least a) causes right now problems by destroying content 
(see the original description of the issue). And since we want to handle all 
three use cases with the same underlying filter concept we just prevent all. 

So the first fix should would in case of a generated filter.xml prevent content 
from being destroyed (by disabling sync/import and export alltogether).

As a second step we could look into supporting generated filter.xmls better.

> 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, 
> SLING-6344-v03.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)

Reply via email to