That's why I think a resource packaging format is the way to go: a) it makes syncing easy during development b) it can directly be packaged together to create a package, so maven/ci builds simply work c) installation of those packages is easy as well
I think it's important to note that this is not about a better/new vlt; it's a imho a different approach which directly addresses existing requirements. Carsten 2013/5/31 Ruben Reusser <r...@headwire.com> > I think the use case of doing maven/jenkins builds and continuous > integrations should also be considered here. Most CQ projects at this time > seem to be using maven builds that create packages that can be deployed to > CQ. Since VLT is open sourced and since the packaging part is also in VLT > I'd expect that to be open sourced as well. vlt sync would actually work if > it did manage the .content.xml files as well (didn't it do that in the > beginning - seems that feature was removed?) allowing developers to change > their code either in the ide or crxde|lite and having the code sync'd to > the file system for checkin and separate builds for CI. Breaking this > experience may be a big problem. > > Ruben > > > On 5/31/2013 7:27 AM, Dominik Süß wrote: > >> One problematic part about serialisation is structuredepth. In development >> you might not want to handle complex structures by shifting folders >> around, >> so it would be nice to have a format that allows to define a substructure, >> so in the Sling Initialcontent you might even define one big JSON that >> defines the complete structure. The consequence of that if you also need >> to >> be able to export changes to the filesystem it isn't clear when things >> should be handled within a file, and when to break up in folderstructures. >> >> In vault this is implicitly solved for specific nodetypes. E.g. in cq a >> dialog always gets exportet to a specific xml file covering this explicit >> substrutcture in one aggregated file. But still even in vault you can have >> situations where you define substructures in the .content.xml which leads >> to an instant "asynchronity" with the repository since vault tries to >> synch >> that as folder/file structure. >> >> I currently have no idea for good solution, but in any case these problems >> should be solved. >> >> Dominik >> >> >> On Fri, May 31, 2013 at 3:19 PM, Robert Munteanu <romb...@apache.org> >> wrote: >> >> On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler 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) >>>> >>> Good point, added >>> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE> >>> +tooling#SlingIDEtooling-**Resourceserializationformat to capture the >>> proposal / points to discuss. >>> >>> Robert >>> >>> 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
