[
https://issues.apache.org/jira/browse/SLING-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-3583.
------------------------------------
Resolution: Fixed
This should now be fixed, your example project works fine for me.
* http://svn.apache.org/viewvc?view=revision&revision=1596257 - simplify usage
of ProjectAdapter.createOrUpdateFile
* http://svn.apache.org/viewvc?view=revision&revision=1596258 - added tracing
to the node deletion code
* http://svn.apache.org/viewvc?view=revision&revision=1596259 - fixed bug +
added regression test
> children of folder, containing files besides .content.xml, will get deleted
> on content-sync
> -------------------------------------------------------------------------------------------
>
> Key: SLING-3583
> URL: https://issues.apache.org/jira/browse/SLING-3583
> Project: Sling
> Issue Type: Bug
> Components: IDE
> Reporter: Stefan Egli
> Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.0.0
>
> Attachments: bugproject.zip
>
>
> In slingclipse, when content is synched to a launchpad-server, children of
> certain folders are immediately deleted after creation.
> Details:
> * consider a sling-content project which contains e.g the following
> structure (node names of children describe their primary type)
> {code}
> someparent
> ├── osgiconfig
> ├── ntfolder
> ├── ntunstructured
> │ └── childofntunstructured
> └── slingfolder
> └── childofslingfolder
> {code}
> * The SlingLaunchpadBehavior.publishContentModule, which is in charge of
> updating the launchpad with changes in the eclipse-filesystem, goes through
> the list of files (Let's assume an initial publish for simplicity reason).
> * It so happens, that the order of iteration is in such a way, that the
> someparent/.content.xml is handled last - after the other children have
> properly been synched with the server.
> * Upon handling of someparent/.content.xml,
> SlingLaunchpadBehavior.addFileCommand is executed, and in there,
> serializationManager.readSerializationData() (or more precisely in
> VltSerializationManager.readSerializationData()) returns the *parent of the
> .content.xml file*, namely the 'someparent' node.
> * With that, in turn, the AddOrUpdateNodeCommand.processDeletedNodes() claims
> that the someparent(ex ./.content.xml) has no children, hence deletes all
> existing ones from the server.
> [~rombert], assigning this to you as you're more familiar with the code in
> that area. I'm uncertain if the real bug is in the readSerializationData or
> in the AddOrUpdateNodeCommand..
--
This message was sent by Atlassian JIRA
(v6.2#6252)
