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
+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
