[ 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)