Hi Adam, On Fri, 2013-05-31 at 10:58 -0400, Adam Yocum wrote: > It would be nice to have vault working with Sling, it has a lot of > functionality including > copying content between two separate servers (vault rcp) and an already > complete eclipse plugin 'vaultclipse'
Once open-sourced, you will be able to work with vlt on pure Sling applications, not only with CQ applications. Robert > > On Fri, May 31, 2013 at 10:36 AM, Ruben Reusser <[email protected]> wrote: > > > 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 <[email protected]> > >> 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 <[email protected]> > >>>> > >>>> 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 > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >>> > >
