Before you read this, please a) excuse my ignorance of Sling build tools, I'm just getting started with pure Sling and b) feel free to inform my of said ignorance :D
I use Maven and Jenkins to do automated builds of our CQ project at work. For development we use a combination of maven and vault with the vaultclipse plugin. With vaultclipse it is as simple as a couple clicks and a second or two to update the running local CQ instance with your code / css / images (anything) you have just changed. If you need to do a full build you just use Maven. When I recently started working with pure Sling I was surprised to see there was no equivalent way of working. (or maybe there is?) So my workflow with Sling is that I use maven to deploy my project on my ec2 server (with Jenkins) and when working locally, but I also have a quick and dirty file editor based on the Editarea JS library that I use to edit jsps etc in the browser and save changes using the Sling Post Servlet. I built this because I was tired of waiting 20+ seconds to deploy my whole project for a simple css change... 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', maybe it could be extended to handle things on a more Sling Resource level than a JCR level, but right now that's where we're at so why not use this tool to it's best abilities. Another downside I've noticed using maven with Sling "bundle resources" the impore doesn't set the JCR node types, so no sling:Folder etc settings, this is making a tree browser harder for me to write... With 'packages' and the vault maven plugin I believe all content loaded this way would get proper sling node types correct? Ok, this noob just couldn't resist to chime in please continue on the discussion :) Thanks, Adam On Fri, May 31, 2013 at 10:36 AM, Ruben Reusser <r...@headwire.com> 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 <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 >>>>> >>>>> >>>>> >>>> >>> >>> >>> >
