Some time ago I thought about this and had the following idea: - we define a packaging for resources - this can be used to represent the resources in the file system or in a zip file - if a resource is a file, it is represented as a file with the same name - if a resource is not a file, it is represented as a directory - properties if a non-file resource, and all additional metadata of a file is stored in a [content].xml (or json)
This would allow browsing through the file system to the resource you want to edit and just edit the properties of this resource in a file. It makes syncing very easy and fast. Maybe we can distinguish between a resource which might have child nodes and one that doesn't and make the mapping differently. In any case the whole mechanism needs some research, a disadvantage might be if you map a huge resource tree which has no files at all to the file system, this will result in a huge directory tree instead of one large content.xml - however as we're talking about developer tooling, we can neglect this. Just a rough idea Carsten 2013/5/31 Robert Munteanu <romb...@apache.org> > On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: > > is the vlt sync now actually updating .content.xml files? I thought it > > can only sync regular files. > > I'm frankly more of an IDE guy than a VLT guy from a development > experience point of view. > > However, I think that the IDE is the right place for the change > detection/sync capabilities, while VLT will be a mechanism from > transporting changes from/to the repository. > > Robert > > -- Carsten Ziegeler cziege...@apache.org
