One comment about content.xml - in our CQ solutions we do use the Sling-Initialcontent (with the much nicer json files placed parallel to the folders with the same name instead of .content.xml underneath) instead of packing it directly in the vault based packages. This leads to a clean and much better searchable filestructure. The code at least for the jcr installation is yet there so this json based syntax would be an option that allready works. The syntax is exactly what you get from the default GET Servlet dumping the structure as json.
The only drawback to vault is that synchronisation is just in direction of the repository, no export (but dumping via the default get servlet). Cheers Dominik On Fri, May 31, 2013 at 2:14 PM, Carsten Ziegeler <cziege...@apache.org>wrote: > 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 >
