[tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

Hi,

Following Antonio's kick-start of the Sling developer tooling [1] I've
gathered some thoughts about the initial goals and implementation of our
Sling IDE tooling.

The document is at [2] so please have a look and let me know what your
thoughts are. I intend to take a pass at the code next week and align it
to the proposed structure, as a foundation for feature work.

Robert

[1]: https://cwiki.apache.org/SLING/slingclipse.html
[2]: https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling

Re: [tooling] Moving forward with IDE tooling

[Antonio Sanso <as...@adobe.com>]

Hi *,

just my  cents.

First of all I am really happy to see this moving forward (thanks Robert for bring this up).

About the usage of VLT I am not against it but I do not see any problem on having a further level of abstraction between the tooling and 
the "transport layer" (e.g. VLT)

Regards

Antonio

On May 31, 2013, at 2:16 AM, Justin Edelson wrote:

> Hi,
> I would strongly suggest that this effort be based on VLT. As mentioned on
> the wiki page, we're in the process of moving that to ASF and I think once
> the code is available, it will be clear that it provides a good low-level
> interface for this type of UI.
> 
> While it is true that VLT currently only works with DavEX servers, I
> suspect it would not be hard to isolate the "Ex" bits and have a "WebDAV"
> only driver which could be used on non-JCR applications for basic file
> operations.
> 
> My concern is that we end up building one more abstraction which is going
> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.).
> 
> I know VLT has some baggage, but I'd just ask that people keep an open mind.
> 
> Separately, I'm going to start a child page of this wiki page to gather use
> cases. There are some functional areas listed on the main page, but I think
> we should try to capture individual use cases.
> 
> Regards,
> Justin
> 
> 
> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <ro...@apache.org>wrote:
> 
>> Hi,
>> 
>> Following Antonio's kick-start of the Sling developer tooling [1] I've
>> gathered some thoughts about the initial goals and implementation of our
>> Sling IDE tooling.
>> 
>> The document is at [2] so please have a look and let me know what your
>> thoughts are. I intend to take a pass at the code next week and align it
>> to the proposed structure, as a foundation for feature work.
>> 
>> Robert
>> 
>> [1]: https://cwiki.apache.org/SLING/slingclipse.html
>> [2]: https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
>> 
>> 

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

To sum up this long discussion thread

1. I've updated the two wiki pages(  [1],[2] ) to contain the topics
we've discussed here. I see Dan has been doing the same, so thanks for
that. Any omissions are accidental, please update the pages if I missed
something.

2. We don't have a definite answer for two topics - resource
serialization format and Sling -> workspace serialization ( automatic vs
manual ) so I'll be careful not to commit to a specific option when I'm
going to touch those areas of the code.

3. As the next step, I'm going to restructure the repo to follow the
structure outlined in [1] and propose moving it to contrib once it's
stable.

Thanks to all who contributed in this discussion thread, I'm now aware
of a couple more issues to tackle with the IDE tooling.

Cheers,

Robert

[1]: https://cwiki.apache.org/SLING/sling-ide-tooling.html
[2]: https://cwiki.apache.org/SLING/use-cases.html

Re: [tooling] Moving forward with IDE tooling

[Dominik Süß <do...@gmail.com>]

Here my 2 cents about Sling Tooling & vault,

IMHO vault is pure JCR Tooling. And even if some people do not like the
fact, but the resourcetree is different from the jcr tree. So in
consequence this additional abstraction of the Resource API is there (even
without additional resource resolvers, since Sling Servlets are not present
in the JCR Tree as well). Due to that I think vault AS IS is not the right
choice since this would hide everything happening on the resourcetree
layer. Having a complete view on the Resourcetree at least in the /apps and
/libs section would be something I really would appreciate.

Best regards
Dominik


On Fri, May 31, 2013 at 2:04 PM, Robert Munteanu <ro...@apache.org> wrote:

> Hi Justin,
>
> (and this will address Ian's comments as well )
>
> On Thu, 2013-05-30 at 20:16 -0400, Justin Edelson wrote:
> > Hi,
> > I would strongly suggest that this effort be based on VLT. As mentioned
> on
> > the wiki page, we're in the process of moving that to ASF and I think
> once
> > the code is available, it will be clear that it provides a good low-level
> > interface for this type of UI.
>
> I have not yet reviewed how embeddable VLT is, but it's hard to believe
> that it will be a perfect match for both the IntelliJ and Eclipse plugin
> APIs. As I noted, you should not directly read from/write to the
> filesystem in Eclipse ( and I expect IntelliJ to have similar
> requirements ) for both user experience ( stale workspace resources )
> and performance ( forced refresh of resources from disk ) reasons.
>
> As such, we will need a wrapper over VLT anyway to make this API
> IDE-friendly. So there's no large effort to have transport API layer.
>
> Also, echoing Antonio's and Carsten's comments, I think that while VLT
> is a powerful and mature tool, it does not work on top of the resource
> API that we have in sling.
>
> We already have a MongoDB resource provider in contrib [1]  and a GSoC
> project accepted which will create an Apache Cassandra resource provider
> [2]. A resource-based transport implementation will help us make those
> implementations first-class citizens.
>
> (snip...)
>
>
> > Separately, I'm going to start a child page of this wiki page to gather
> use
> > cases. There are some functional areas listed on the main page, but I
> think
> > we should try to capture individual use cases.
>
>
> +1
>
> Robert
>
>
> [1]:
> http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/mongodb/
>
> [2]: http://sling.markmail.org/thread/ugghepk5hod55fy5
>
>

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

Hi Justin,

(and this will address Ian's comments as well )

On Thu, 2013-05-30 at 20:16 -0400, Justin Edelson wrote:
> Hi,
> I would strongly suggest that this effort be based on VLT. As mentioned on
> the wiki page, we're in the process of moving that to ASF and I think once
> the code is available, it will be clear that it provides a good low-level
> interface for this type of UI.

I have not yet reviewed how embeddable VLT is, but it's hard to believe
that it will be a perfect match for both the IntelliJ and Eclipse plugin
APIs. As I noted, you should not directly read from/write to the
filesystem in Eclipse ( and I expect IntelliJ to have similar
requirements ) for both user experience ( stale workspace resources )
and performance ( forced refresh of resources from disk ) reasons.

As such, we will need a wrapper over VLT anyway to make this API
IDE-friendly. So there's no large effort to have transport API layer.

Also, echoing Antonio's and Carsten's comments, I think that while VLT
is a powerful and mature tool, it does not work on top of the resource
API that we have in sling.

We already have a MongoDB resource provider in contrib [1]  and a GSoC
project accepted which will create an Apache Cassandra resource provider
[2]. A resource-based transport implementation will help us make those
implementations first-class citizens.

(snip...)


> Separately, I'm going to start a child page of this wiki page to gather use
> cases. There are some functional areas listed on the main page, but I think
> we should try to capture individual use cases.


+1

Robert


[1]:
http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/mongodb/

[2]: http://sling.markmail.org/thread/ugghepk5hod55fy5

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

On Fri, 2013-05-31 at 10:40 -0400, Justin Edelson wrote:
> Hi,
> These are all excellent points.
> 
> I am a bit confused about mentions of the Sling Resource API. This is a
> server-side API while we are discussing client code. AFAIK we don't have a
> client implementation of the Resource API nor do we have a standard
> transport mechanism. We do have the default GET and POST servlets, but as
> Robert pointed out in the wiki, those can't be depended upon consistently.

The current integration uses HTTP calls, and I don't expect to develop
an actual API. But I think we can enhance the server-side API to be able
to get all the data using GET requests.

> 
> The points Carsten and Dominik point to something broader - not using vlt
> (and the content packing process in general) necessitates defining
> packaging and deployment mechanisms. After all, it wouldn't be acceptable
> to have a way to develop and application without being able to deploy it.
> With vlt, these mechanisms are defined already (whether these mechanisms
> are ideal or not is a separate problem). One option is to use
> Sling-InitialContent and POST to the webconsole (as Dominik suggested);
> another is to build something new (as Carsten suggested).

Agreed.

> 
> At the end of the day, what I'm asking is that we wait until vlt has been
> moved to ASF before judging it. My belief, based on some experience
> embedding vlt, is that the issues raised in this thread are relatively easy
> to resolve. Certainly easier than creating a new thing.

Agreed again. We'll definitely use vlt, and the implementation will
definitely be vlt-heavy, at least to get a 1.0 version running. Or 0.9,
to set expectations about backwards compatibility.

Robert

> 
> Justin
> 
> On Fri, May 31, 2013 at 8:21 AM, Dominik Süß <do...@gmail.com>wrote:
> 
> > 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 <cziegeler@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 <ro...@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
> > > cziegeler@apache.org
> > >
> >

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler <cz...@apache.org>]

I personally think creating a new thing from scratch is easier, sure there
might a little bit of work - but on the other hand it comes with a lot of
benefits.

However, whoever does the work can decide - and why not having more than
one prototype and then see whats the better way?


Or in other words, I think it makes sense at least to think about this
issue green field without already having existing solutions prediction the
final solution.

Carsten


2013/5/31 Justin Edelson <ju...@justinedelson.com>

> Hi,
> These are all excellent points.
>
> I am a bit confused about mentions of the Sling Resource API. This is a
> server-side API while we are discussing client code. AFAIK we don't have a
> client implementation of the Resource API nor do we have a standard
> transport mechanism. We do have the default GET and POST servlets, but as
> Robert pointed out in the wiki, those can't be depended upon consistently.
>
> The points Carsten and Dominik point to something broader - not using vlt
> (and the content packing process in general) necessitates defining
> packaging and deployment mechanisms. After all, it wouldn't be acceptable
> to have a way to develop and application without being able to deploy it.
> With vlt, these mechanisms are defined already (whether these mechanisms
> are ideal or not is a separate problem). One option is to use
> Sling-InitialContent and POST to the webconsole (as Dominik suggested);
> another is to build something new (as Carsten suggested).
>
> At the end of the day, what I'm asking is that we wait until vlt has been
> moved to ASF before judging it. My belief, based on some experience
> embedding vlt, is that the issues raised in this thread are relatively easy
> to resolve. Certainly easier than creating a new thing.
>
> Justin
>
> On Fri, May 31, 2013 at 8:21 AM, Dominik Süß <dominik.suess@gmail.com
> >wrote:
>
> > 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 <cziegeler@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 <ro...@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
> > > cziegeler@apache.org
> > >
> >
>



-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Justin Edelson <ju...@justinedelson.com>]

Hi,
These are all excellent points.

I am a bit confused about mentions of the Sling Resource API. This is a
server-side API while we are discussing client code. AFAIK we don't have a
client implementation of the Resource API nor do we have a standard
transport mechanism. We do have the default GET and POST servlets, but as
Robert pointed out in the wiki, those can't be depended upon consistently.

The points Carsten and Dominik point to something broader - not using vlt
(and the content packing process in general) necessitates defining
packaging and deployment mechanisms. After all, it wouldn't be acceptable
to have a way to develop and application without being able to deploy it.
With vlt, these mechanisms are defined already (whether these mechanisms
are ideal or not is a separate problem). One option is to use
Sling-InitialContent and POST to the webconsole (as Dominik suggested);
another is to build something new (as Carsten suggested).

At the end of the day, what I'm asking is that we wait until vlt has been
moved to ASF before judging it. My belief, based on some experience
embedding vlt, is that the issues raised in this thread are relatively easy
to resolve. Certainly easier than creating a new thing.

Justin

On Fri, May 31, 2013 at 8:21 AM, Dominik Süß <do...@gmail.com>wrote:

> 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 <cziegeler@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 <ro...@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
> > cziegeler@apache.org
> >
>

Re: [tooling] Moving forward with IDE tooling

[Dominik Süß <do...@gmail.com>]

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 <cz...@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 <ro...@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
> cziegeler@apache.org
>

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler <cz...@apache.org>]

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 <rr...@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 <ro...@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 <ro...@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
cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

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 <rr...@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 <ro...@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 <ro...@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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >

Re: [tooling] Moving forward with IDE tooling

[Adam Yocum <ad...@gmail.com>]

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 <rr...@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 <ro...@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 <ro...@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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>

Re: [tooling] Moving forward with IDE tooling

[Ruben Reusser <rr...@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 <ro...@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 <ro...@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
>>>>
>>>>
>>>
>>
>>
>>

Re: [tooling] Moving forward with IDE tooling

[Dominik Süß <do...@gmail.com>]

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 <ro...@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 <ro...@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
> > >
> > >
> >
> >
>
>
>
>

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

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 <ro...@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
> >
> >
> 
> 

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler <cz...@apache.org>]

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 <ro...@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
cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Bertrand Delacretaz <bd...@apache.org>]

On Fri, May 31, 2013 at 2:08 PM, Robert Munteanu <ro...@apache.org> wrote:
> ...I'm frankly more of an IDE guy than a VLT guy from a development
> experience point of view....

IMO focusing on filesystem operations (which can be driven by IDEs)
would be the right abstraction level, so that people can use any
suitable development environment.

Do we need anything more than the following story?

** Life of a Sling Developer **
I have a Sling project at /P on my disk, consisting of Sling resources
content and Java bundles code.

To start working on it I can point Sling to file:///P, and the content
and (Maven-built) bundles are loaded into Sling.

I can modify the properties of the Sling /content/foo resource by
editing a /P/content/foo/SLING.properties file.

Changes to those files are synced quickly to the Sling repository.

Changes to Java bundles code under /P are detected (maybe by a
separate tool) and cause a rebuild and update of the corresponding
bundle.

When I'm happy with my content and code, Maven plugins allow me to
package it for distribution, as Sling bundles that include initial
content.

A separate tool allows for dumping a set of Sling repository subtrees
as content .properties file.

-Bertrand

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@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

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

On Sun, 2013-06-02 at 10:53 -0700, Ruben Reusser wrote:
> I was trying to dumb down the example with 'content', however, in the CQ 
> world there are a couple of areas where the tool comes with an editor 
> for certain functionalities, for example workflows. While I can manage 
> them in XML, it would be much nicer to manage them in CQ (or in the IDE, 
> maybe through a hook that allows me to manage them in the repository and 
> then at save bring the generated structure back to the IDE).
> 
> Also, editing the XML's in an IDE has a couple of shortcomings due to 
> the fact that the XML structure currently used is very finicky and does 
> not allow for a DTD for example. This makes it IMHO pretty hard to 
> manage the structures in an IDE. (for example, list of child nodes has 
> to be at the end of the .content.xml file, can't be in the beginning and 
> the xml tag names are used to drive the node names in the repository, 
> not allowing a clear validation of the options).

Agreed on all the above points. IMO 'Edit in Sling/CQ, then pull into
the IDE workspace' is a required operation. FWIW, it's currently
implemented in Slingclipse, although it doesn't work in all situations.

Robert

Re: [tooling] Moving forward with IDE tooling

[Ruben Reusser <rr...@headwire.com>]

I was trying to dumb down the example with 'content', however, in the CQ 
world there are a couple of areas where the tool comes with an editor 
for certain functionalities, for example workflows. While I can manage 
them in XML, it would be much nicer to manage them in CQ (or in the IDE, 
maybe through a hook that allows me to manage them in the repository and 
then at save bring the generated structure back to the IDE).

Also, editing the XML's in an IDE has a couple of shortcomings due to 
the fact that the XML structure currently used is very finicky and does 
not allow for a DTD for example. This makes it IMHO pretty hard to 
manage the structures in an IDE. (for example, list of child nodes has 
to be at the end of the .content.xml file, can't be in the beginning and 
the xml tag names are used to drive the node names in the repository, 
not allowing a clear validation of the options).

Ruben

On 6/2/2013 9:33 AM, Dominik Süß wrote:
> I'm trying to summarize my thoughts including the several opinions
> scenarios stated:
> a) The main usecase seems to be development from IDE (persisted to FS and
> therefore to be integreated with any FS based versioning tool of choice)
> b) a  (on save) sync the application from FS to Sling via IDE seems what
> everybody needs and agrees on
> c) Not directly mentioned but what I think should be defined as well how
> and when bundlebased (JAVA) code gets synced to the repository
> d) where I didn't hear consensus is about syncing from Sling to FS. The
> reason why I have my problem with that,  is that autosync needs an explicit
> definition how structures get mapped. In direction repository this is easy
> since this unwraps the filebased (xml or json) wrappers and creates a lot
> of finegrained strucures, but the other way around there would be the need
> of an implicit way how those structures get serialized to the FS or some
> (potentially) complex definition that a dev would have to make (possible
> with vault afaik, but IMHO errorprone).
> e) one of the main reasons for d is to see changes from the repository
> within the IDE. I here fully second Carsten that this shouldn't be
> automagically resolved but be controlled from the dev.  The IDE here can
> create some tooling to identify and display changes and support the job to
> reestablish synchronity (this might be the hardest part for the tooling
> since I  havent seen a proper ui doing such a job).
> f) regarding "sample" content mentioned by Ruben I think some
> packagingmechanism and a maven task to upload/download this package should
> besufficient (lock package, upload, change content in repo, download
> package, check in vcs)
>
> Cheers
> Dominik
>
>
> On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser <rr...@headwire.com> wrote:
>
>> we frequently have a content project during development with a sample site
>> that can be deployed over maven to a local dev instance. Maintaining the
>> sample content in the project requires to author in the cms and then sync
>> back to file system. Making bulk changes to the structure (for example,
>> globally rename a sling:resourceSuperType) is easier done in the IDE.
>> Content is then pushed back into the repository. I am not saying a constant
>> sync is needed, but a way for the IDE to 'update from repository' would
>> really help.
>>
>> The vlt sync command has another issue. Since it stores its state in the
>> local file system but relies on the server to manage the files your server
>> instance and file system can get out of sync (say your server crashes and
>> you have to reinstall it). Switching instances (say current version vs new
>> version) for testing purposes (is everything still working fine) is not
>> well supported either.
>>
>> Ruben
>>
>>
>> On 6/2/2013 6:35 AM, Antonio Sanso wrote:
>>
>>> On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler wrote:
>>>
>>>   I think a sync in both directions is problematic and I wouldn't go there
>>>> -
>>>> but I know that there only a few having this opinion.
>>>> In my opinion, when I'm talking about a developer that's someone who
>>>> develops code including scripts and usually Java - this might also
>>>> include
>>>> coding in client side stuff like js and css. There is the central tool
>>>> you
>>>> use for developing and that's the IDE with a strong integration into the
>>>> SCM (svn, git etc). The dev never has to leave this IDE for anything. In
>>>> this scenario, there is only a sync from IDE to Sling required - but not
>>>> the other way round.
>>>>
>>> +1
>>>
>>>   Whenever that's needed (syncing data from Sling into the file system)
>>>> this
>>>> should imho be an explicit decision by the dev - simply by invoking an
>>>> action from the IDE.
>>>>
>>> +1
>>>
>>> Regards
>>>
>>> Antonio
>>>
>>>
>>>   An automatic sync in both directions is dangerous and
>>>> imho in most cases not wanted/desired/required.
>>>>
>>>> As soon as we're talking about automatic sync from Sling to the project
>>>> checkout, this has a different style of development in mind - which I
>>>> think
>>>> we should not support when talking about IDE support. Either we support
>>>> IDE
>>>> development and then we do it right and have a style of working that does
>>>> not require to leave the IDE - or we do something different, but then
>>>> let's
>>>> make it clear that we don't plan to provide a true dev experience.
>>>>
>>>>
>>>> Carsten
>>>>
>>>>
>>>> 2013/6/1 Ian Boston <ie...@tfd.co.uk>
>>>>
>>>>   Hi,
>>>>> I've added the requirements for autosync to [1]. Although VLT does a
>>>>> good
>>>>> job of this once setup I don't use CLI for editing and manipulating. I
>>>>> use
>>>>> the IDE 100% with all its other tooling and just File Save.
>>>>> Setup with VLT is 2 commands and a 1 line config file edit, which could
>>>>> easily be converted into a IDE plugin.
>>>>>
>>>>> Having thought about it, I think the reason vlt sync works well is that
>>>>> Sling is on the same box, monitoring the file system for changes, (I
>>>>> think
>>>>> thats right, there is no local process with vlt sync) and monitoring JCR
>>>>> for changes, which avoids lots of processing and http traffic. When I
>>>>> have
>>>>> used other forms of integration on large repositories, the volume http
>>>>> traffic and speed of response has nearly always made them unusable.
>>>>>
>>>>> What ever is used or reimplemented it must not rely on scanning a
>>>>> repository to know what has changed. It must relay on notification of
>>>>> some
>>>>> form so that Edit->Save->Refresh is never more than a few seconds, and
>>>>> doesn't impact the Sling server resource usage. Ideally notification
>>>>> should
>>>>> not rely on the IDE, since changes can be made without the IDE running,
>>>>> and
>>>>> routing it via the IDE is going to get really confusing with 3 or more
>>>>> potential sources of updates. (assuming code under version control)
>>>>>
>>>>> HTH
>>>>> Ian
>>>>>
>>>>> 1. https://cwiki.apache.org/**confluence/display/SLING/Use+**Cases<https://cwiki.apache.org/confluence/display/SLING/Use+Cases>
>>>>>
>>>>>
>>>>> On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>>
>>>>>   @Justin, will do.
>>>>>> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about
>>>>>> its
>>>>>> internals).
>>>>>>
>>>>>>
>>>>>> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
>>>>>>
>>>>>>   is the vlt sync now actually updating .content.xml files? I thought it
>>>>>>> can only sync regular files.
>>>>>>>
>>>>>>> Ruben
>>>>>>>
>>>>>>>
>>>>>>> On 5/30/2013 7:24 PM, Justin Edelson wrote:
>>>>>>>
>>>>>>>   Ian - please do add the autosync use case to the wiki page I created.
>>>>>>>>
>>>>>>>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>> +1 to that. After working on sling for many years doing a mixture of
>>>>>>>>> bundle
>>>>>>>>> and UI work, mainly using the FileSystemResolver bundle, I realise
>>>>>>>>> now
>>>>>>>>> if
>>>>>>>>> VLT had been available with sync mode (ie auto syncing the repo and
>>>>>>>>>
>>>>>>>> the
>>>>>> file system), we (the team I was working with at the time) would have
>>>>>>>>> made
>>>>>>>>> much more rapid progress. UI dev work needs file-save-refresh. The
>>>>>>>>> in
>>>>>>>>> browser editing UIs deliver this, as does VLT in sync mode, but
>>>>>>>>> unfortunately native eclipse based tooling is just too slow (on my
>>>>>>>>> machine,
>>>>>>>>> might be my machine). Using VLT since I joined Adobe, has been a
>>>>>>>>> joy,
>>>>>>>>> and I
>>>>>>>>> am very glad to know its being donated to the ASF.
>>>>>>>>>
>>>>>>>>> Had we had VLT then, we would have developed in a very different
>>>>>>>>> way,
>>>>>>>>> and
>>>>>>>>> might not have had half the problems we had with tooling and team
>>>>>>>>> structure.
>>>>>>>>> Ian
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
>>>>>>>>>
>>>>>>>> wrote:
>>>>>> Hi,
>>>>>>>>>> I would strongly suggest that this effort be based on VLT. As
>>>>>>>>>>
>>>>>>>>> mentioned
>>>>>> on
>>>>>>>>>   the wiki page, we're in the process of moving that to ASF and I
>>>>>>>>>> think
>>>>>>>>>>
>>>>>>>>>>   once
>>>>>>>>>   the code is available, it will be clear that it provides a good
>>>>>>>>>> low-level
>>>>>>>>>> interface for this type of UI.
>>>>>>>>>>
>>>>>>>>>> While it is true that VLT currently only works with DavEX servers,
>>>>>>>>>> I
>>>>>>>>>> suspect it would not be hard to isolate the "Ex" bits and have a
>>>>>>>>>> "WebDAV"
>>>>>>>>>> only driver which could be used on non-JCR applications for basic
>>>>>>>>>>
>>>>>>>>> file
>>>>>> operations.
>>>>>>>>>> My concern is that we end up building one more abstraction which is
>>>>>>>>>> going
>>>>>>>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
>>>>>>>>>>
>>>>>>>>>>   etc.).
>>>>>>>>>   I know VLT has some baggage, but I'd just ask that people keep an
>>>>>>>>> open
>>>>>> mind.
>>>>>>>>>> Separately, I'm going to start a child page of this wiki page to
>>>>>>>>>>
>>>>>>>>> gather
>>>>>> use
>>>>>>>>>   cases. There are some functional areas listed on the main page,
>>>>>>>>>> but I
>>>>>>>>>>
>>>>>>>>>>   think
>>>>>>>>>   we should try to capture individual use cases.
>>>>>>>>>> Regards,
>>>>>>>>>> Justin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
>>>>>>>>>>
>>>>>>>>> rombert@apache.org
>>>>>> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Following Antonio's kick-start of the Sling developer tooling [1]
>>>>>>>>>>>
>>>>>>>>>> I've
>>>>>> gathered some thoughts about the initial goals and implementation of
>>>>>>>>>>>   our
>>>>>>>>>> Sling IDE tooling.
>>>>>>>>>>
>>>>>>>>>>> The document is at [2] so please have a look and let me know what
>>>>>>>>>>>
>>>>>>>>>> your
>>>>>> thoughts are. I intend to take a pass at the code next week and
>>>>>>>>>> align
>>>>>> it
>>>>>>>>>> to the proposed structure, as a foundation for feature work.
>>>>>>>>>>
>>>>>>>>>>> Robert
>>>>>>>>>>>
>>>>>>>>>>> [1]: https://cwiki.apache.org/****SLING/slingclipse.html<https://cwiki.apache.org/**SLING/slingclipse.html>
>>>>>>>>>>> <
>>>>>>>>>>>
>>>>>>>>>> https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.apache.org/SLING/slingclipse.html>
>>>>>> [2]:
>>>>>>>>>>>   https://cwiki.apache.org/****confluence/display/SLING/**<https://cwiki.apache.org/**confluence/display/SLING/**>
>>>>>>>>> Sling+IDE+tooling<
>>>>>>>>>
>>>>>>>> https://cwiki.apache.org/**confluence/display/SLING/**
>>>>> Sling+IDE+tooling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
>>>>
>>>> --
>>>> Carsten Ziegeler
>>>> cziegeler@apache.org
>>>>

Re: [tooling] Moving forward with IDE tooling

[Dominik Süß <do...@gmail.com>]

One point about taking those into account is to get a full Resourcetree
view. Even if development and synching between FS and Sling is just enabled
on the repository layer (and propably mounted bundles) It think it would be
really important to have at least optionally a complete view of the
resourceTree and not just the repository tree. A node might then link the
files/classes that handle this resource (and some options to see sling
components that might act for specific selectors or extensions).

Dominik


On Mon, Jun 3, 2013 at 2:46 PM, Carsten Ziegeler <cz...@apache.org>wrote:

> Afaik, Felix can already load exploaded bundles - and I guess this
> integration into Eclipse shouldn't be too hard.
> Maybe my previous wording was not good, I think this is an important area
> where we're currently lacking tooling, however I wouldn't see this as
> Sling's primary goal to provide tools for that; I would rather love to
> reuse others work.
>
> Carsten
>
>
> 2013/6/3 Robert Munteanu <ro...@apache.org>
>
> > On Mon, 2013-06-03 at 14:21 +0200, Dominik Süß wrote:
> > > When skipping Javacode and Bundles (which I'm not so happy with) one
> > option
> > > would also be to have something like a ResourceProvider that for "dev"
> > time
> > > redirects and takes data from the FS. As long as we have the mentioned
> > same
> > > machine scenario the synchronisation is IMHO not necessary, better
> have a
> > > FS Resourceprovider that gets more capabilities than the current one.
> IDE
> > > support could even have some trigger to switch between FS-mode and
> > > Repo-Mode with an automatic deployment/push when switching.
> > >
> > > WDYT?
> > >
> >
> > I think that the difference between java sources and other content is
> > that, unless you use an agent such as JRebel, a java class change leads
> > to a full deploy of the bundle, which is likely not instantaneous.
> >
> > One was I can possibly see this working is:
> >
> > - teach Felix to load exploded bundles ( if it doesn't already know )
> > - map the bundle's target directory to a '..../install' directory in the
> > repository using your FS Resourceprovider idea
> > - have the bundles reloaded using the JCR installer whenever the install
> > location receives changes
> >
> > There are a lot of details to take care of though. The work done for the
> > Felix SCR plugin means that you should get a full bundle structure in
> > Eclipse ( SCR / Metatype XML files, complete manifest ) but I'm not sure
> > about IntelliJ, where you probably need to manually 'Make' the module.
> >
> > Robert
> >
> >
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler <cz...@apache.org>]

Afaik, Felix can already load exploaded bundles - and I guess this
integration into Eclipse shouldn't be too hard.
Maybe my previous wording was not good, I think this is an important area
where we're currently lacking tooling, however I wouldn't see this as
Sling's primary goal to provide tools for that; I would rather love to
reuse others work.

Carsten


2013/6/3 Robert Munteanu <ro...@apache.org>

> On Mon, 2013-06-03 at 14:21 +0200, Dominik Süß wrote:
> > When skipping Javacode and Bundles (which I'm not so happy with) one
> option
> > would also be to have something like a ResourceProvider that for "dev"
> time
> > redirects and takes data from the FS. As long as we have the mentioned
> same
> > machine scenario the synchronisation is IMHO not necessary, better have a
> > FS Resourceprovider that gets more capabilities than the current one. IDE
> > support could even have some trigger to switch between FS-mode and
> > Repo-Mode with an automatic deployment/push when switching.
> >
> > WDYT?
> >
>
> I think that the difference between java sources and other content is
> that, unless you use an agent such as JRebel, a java class change leads
> to a full deploy of the bundle, which is likely not instantaneous.
>
> One was I can possibly see this working is:
>
> - teach Felix to load exploded bundles ( if it doesn't already know )
> - map the bundle's target directory to a '..../install' directory in the
> repository using your FS Resourceprovider idea
> - have the bundles reloaded using the JCR installer whenever the install
> location receives changes
>
> There are a lot of details to take care of though. The work done for the
> Felix SCR plugin means that you should get a full bundle structure in
> Eclipse ( SCR / Metatype XML files, complete manifest ) but I'm not sure
> about IntelliJ, where you probably need to manually 'Make' the module.
>
> Robert
>
>


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

On Mon, 2013-06-03 at 14:21 +0200, Dominik Süß wrote:
> When skipping Javacode and Bundles (which I'm not so happy with) one option
> would also be to have something like a ResourceProvider that for "dev" time
> redirects and takes data from the FS. As long as we have the mentioned same
> machine scenario the synchronisation is IMHO not necessary, better have a
> FS Resourceprovider that gets more capabilities than the current one. IDE
> support could even have some trigger to switch between FS-mode and
> Repo-Mode with an automatic deployment/push when switching.
> 
> WDYT?
> 

I think that the difference between java sources and other content is
that, unless you use an agent such as JRebel, a java class change leads
to a full deploy of the bundle, which is likely not instantaneous.

One was I can possibly see this working is:

- teach Felix to load exploded bundles ( if it doesn't already know )
- map the bundle's target directory to a '..../install' directory in the
repository using your FS Resourceprovider idea
- have the bundles reloaded using the JCR installer whenever the install
location receives changes

There are a lot of details to take care of though. The work done for the
Felix SCR plugin means that you should get a full bundle structure in
Eclipse ( SCR / Metatype XML files, complete manifest ) but I'm not sure
about IntelliJ, where you probably need to manually 'Make' the module.

Robert

Re: [tooling] Moving forward with IDE tooling

[Dominik Süß <do...@gmail.com>]

When skipping Javacode and Bundles (which I'm not so happy with) one option
would also be to have something like a ResourceProvider that for "dev" time
redirects and takes data from the FS. As long as we have the mentioned same
machine scenario the synchronisation is IMHO not necessary, better have a
FS Resourceprovider that gets more capabilities than the current one. IDE
support could even have some trigger to switch between FS-mode and
Repo-Mode with an automatic deployment/push when switching.

WDYT?

Dominik


On Mon, Jun 3, 2013 at 7:25 AM, Carsten Ziegeler <cz...@apache.org>wrote:

> For c) java code and bundles, I would suggest to leave this out for now and
> see if we can integrate other tooling for that work. I'm currently
> exploring options and maybe we can leverage other peoples work for that
>
> Carsten
>
>
> 2013/6/2 Dominik Süß <do...@gmail.com>
>
> > I'm trying to summarize my thoughts including the several opinions
> > scenarios stated:
> > a) The main usecase seems to be development from IDE (persisted to FS and
> > therefore to be integreated with any FS based versioning tool of choice)
> > b) a  (on save) sync the application from FS to Sling via IDE seems what
> > everybody needs and agrees on
> > c) Not directly mentioned but what I think should be defined as well how
> > and when bundlebased (JAVA) code gets synced to the repository
> > d) where I didn't hear consensus is about syncing from Sling to FS. The
> > reason why I have my problem with that,  is that autosync needs an
> explicit
> > definition how structures get mapped. In direction repository this is
> easy
> > since this unwraps the filebased (xml or json) wrappers and creates a lot
> > of finegrained strucures, but the other way around there would be the
> need
> > of an implicit way how those structures get serialized to the FS or some
> > (potentially) complex definition that a dev would have to make (possible
> > with vault afaik, but IMHO errorprone).
> > e) one of the main reasons for d is to see changes from the repository
> > within the IDE. I here fully second Carsten that this shouldn't be
> > automagically resolved but be controlled from the dev.  The IDE here can
> > create some tooling to identify and display changes and support the job
> to
> > reestablish synchronity (this might be the hardest part for the tooling
> > since I  havent seen a proper ui doing such a job).
> > f) regarding "sample" content mentioned by Ruben I think some
> > packagingmechanism and a maven task to upload/download this package
> should
> > besufficient (lock package, upload, change content in repo, download
> > package, check in vcs)
> >
> > Cheers
> > Dominik
> >
> >
> > On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser <rr...@headwire.com> wrote:
> >
> > > we frequently have a content project during development with a sample
> > site
> > > that can be deployed over maven to a local dev instance. Maintaining
> the
> > > sample content in the project requires to author in the cms and then
> sync
> > > back to file system. Making bulk changes to the structure (for example,
> > > globally rename a sling:resourceSuperType) is easier done in the IDE.
> > > Content is then pushed back into the repository. I am not saying a
> > constant
> > > sync is needed, but a way for the IDE to 'update from repository' would
> > > really help.
> > >
> > > The vlt sync command has another issue. Since it stores its state in
> the
> > > local file system but relies on the server to manage the files your
> > server
> > > instance and file system can get out of sync (say your server crashes
> and
> > > you have to reinstall it). Switching instances (say current version vs
> > new
> > > version) for testing purposes (is everything still working fine) is not
> > > well supported either.
> > >
> > > Ruben
> > >
> > >
> > > On 6/2/2013 6:35 AM, Antonio Sanso wrote:
> > >
> > >> On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler wrote:
> > >>
> > >>  I think a sync in both directions is problematic and I wouldn't go
> > there
> > >>> -
> > >>> but I know that there only a few having this opinion.
> > >>> In my opinion, when I'm talking about a developer that's someone who
> > >>> develops code including scripts and usually Java - this might also
> > >>> include
> > >>> coding in client side stuff like js and css. There is the central
> tool
> > >>> you
> > >>> use for developing and that's the IDE with a strong integration into
> > the
> > >>> SCM (svn, git etc). The dev never has to leave this IDE for anything.
> > In
> > >>> this scenario, there is only a sync from IDE to Sling required - but
> > not
> > >>> the other way round.
> > >>>
> > >> +1
> > >>
> > >>  Whenever that's needed (syncing data from Sling into the file system)
> > >>> this
> > >>> should imho be an explicit decision by the dev - simply by invoking
> an
> > >>> action from the IDE.
> > >>>
> > >> +1
> > >>
> > >> Regards
> > >>
> > >> Antonio
> > >>
> > >>
> > >>  An automatic sync in both directions is dangerous and
> > >>> imho in most cases not wanted/desired/required.
> > >>>
> > >>> As soon as we're talking about automatic sync from Sling to the
> project
> > >>> checkout, this has a different style of development in mind - which I
> > >>> think
> > >>> we should not support when talking about IDE support. Either we
> support
> > >>> IDE
> > >>> development and then we do it right and have a style of working that
> > does
> > >>> not require to leave the IDE - or we do something different, but then
> > >>> let's
> > >>> make it clear that we don't plan to provide a true dev experience.
> > >>>
> > >>>
> > >>> Carsten
> > >>>
> > >>>
> > >>> 2013/6/1 Ian Boston <ie...@tfd.co.uk>
> > >>>
> > >>>  Hi,
> > >>>> I've added the requirements for autosync to [1]. Although VLT does a
> > >>>> good
> > >>>> job of this once setup I don't use CLI for editing and
> manipulating. I
> > >>>> use
> > >>>> the IDE 100% with all its other tooling and just File Save.
> > >>>> Setup with VLT is 2 commands and a 1 line config file edit, which
> > could
> > >>>> easily be converted into a IDE plugin.
> > >>>>
> > >>>> Having thought about it, I think the reason vlt sync works well is
> > that
> > >>>> Sling is on the same box, monitoring the file system for changes, (I
> > >>>> think
> > >>>> thats right, there is no local process with vlt sync) and monitoring
> > JCR
> > >>>> for changes, which avoids lots of processing and http traffic. When
> I
> > >>>> have
> > >>>> used other forms of integration on large repositories, the volume
> http
> > >>>> traffic and speed of response has nearly always made them unusable.
> > >>>>
> > >>>> What ever is used or reimplemented it must not rely on scanning a
> > >>>> repository to know what has changed. It must relay on notification
> of
> > >>>> some
> > >>>> form so that Edit->Save->Refresh is never more than a few seconds,
> and
> > >>>> doesn't impact the Sling server resource usage. Ideally notification
> > >>>> should
> > >>>> not rely on the IDE, since changes can be made without the IDE
> > running,
> > >>>> and
> > >>>> routing it via the IDE is going to get really confusing with 3 or
> more
> > >>>> potential sources of updates. (assuming code under version control)
> > >>>>
> > >>>> HTH
> > >>>> Ian
> > >>>>
> > >>>> 1. https://cwiki.apache.org/**confluence/display/SLING/Use+**Cases<
> > https://cwiki.apache.org/confluence/display/SLING/Use+Cases>
> > >>>>
> > >>>>
> > >>>> On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:
> > >>>>
> > >>>>  @Justin, will do.
> > >>>>>
> > >>>>> @Ruben, it doesnt :(, but IMHO it should. (knowing very little
> about
> > >>>>> its
> > >>>>> internals).
> > >>>>>
> > >>>>>
> > >>>>> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
> > >>>>>
> > >>>>>  is the vlt sync now actually updating .content.xml files? I
> thought
> > it
> > >>>>>> can only sync regular files.
> > >>>>>>
> > >>>>>> Ruben
> > >>>>>>
> > >>>>>>
> > >>>>>> On 5/30/2013 7:24 PM, Justin Edelson wrote:
> > >>>>>>
> > >>>>>>  Ian - please do add the autosync use case to the wiki page I
> > created.
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk>
> wrote:
> > >>>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>>> +1 to that. After working on sling for many years doing a
> mixture
> > of
> > >>>>>>>> bundle
> > >>>>>>>> and UI work, mainly using the FileSystemResolver bundle, I
> realise
> > >>>>>>>> now
> > >>>>>>>> if
> > >>>>>>>> VLT had been available with sync mode (ie auto syncing the repo
> > and
> > >>>>>>>>
> > >>>>>>> the
> > >>>>
> > >>>>> file system), we (the team I was working with at the time) would
> have
> > >>>>>>>> made
> > >>>>>>>> much more rapid progress. UI dev work needs file-save-refresh.
> The
> > >>>>>>>> in
> > >>>>>>>> browser editing UIs deliver this, as does VLT in sync mode, but
> > >>>>>>>> unfortunately native eclipse based tooling is just too slow (on
> my
> > >>>>>>>> machine,
> > >>>>>>>> might be my machine). Using VLT since I joined Adobe, has been a
> > >>>>>>>> joy,
> > >>>>>>>> and I
> > >>>>>>>> am very glad to know its being donated to the ASF.
> > >>>>>>>>
> > >>>>>>>> Had we had VLT then, we would have developed in a very different
> > >>>>>>>> way,
> > >>>>>>>> and
> > >>>>>>>> might not have had half the problems we had with tooling and
> team
> > >>>>>>>> structure.
> > >>>>>>>> Ian
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
> > >>>>>>>>
> > >>>>>>> wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>>>>
> > >>>>>>>>> I would strongly suggest that this effort be based on VLT. As
> > >>>>>>>>>
> > >>>>>>>> mentioned
> > >>>>
> > >>>>> on
> > >>>>>>>>
> > >>>>>>>>  the wiki page, we're in the process of moving that to ASF and I
> > >>>>>>>>> think
> > >>>>>>>>>
> > >>>>>>>>>  once
> > >>>>>>>>
> > >>>>>>>>  the code is available, it will be clear that it provides a good
> > >>>>>>>>> low-level
> > >>>>>>>>> interface for this type of UI.
> > >>>>>>>>>
> > >>>>>>>>> While it is true that VLT currently only works with DavEX
> > servers,
> > >>>>>>>>> I
> > >>>>>>>>> suspect it would not be hard to isolate the "Ex" bits and have
> a
> > >>>>>>>>> "WebDAV"
> > >>>>>>>>> only driver which could be used on non-JCR applications for
> basic
> > >>>>>>>>>
> > >>>>>>>> file
> > >>>>
> > >>>>> operations.
> > >>>>>>>>>
> > >>>>>>>>> My concern is that we end up building one more abstraction
> which
> > is
> > >>>>>>>>> going
> > >>>>>>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR,
> > MK,
> > >>>>>>>>>
> > >>>>>>>>>  etc.).
> > >>>>>>>>
> > >>>>>>>>  I know VLT has some baggage, but I'd just ask that people keep
> an
> > >>>>>>>>>
> > >>>>>>>> open
> > >>>>
> > >>>>> mind.
> > >>>>>>>>>
> > >>>>>>>>> Separately, I'm going to start a child page of this wiki page
> to
> > >>>>>>>>>
> > >>>>>>>> gather
> > >>>>
> > >>>>> use
> > >>>>>>>>
> > >>>>>>>>  cases. There are some functional areas listed on the main page,
> > >>>>>>>>> but I
> > >>>>>>>>>
> > >>>>>>>>>  think
> > >>>>>>>>
> > >>>>>>>>  we should try to capture individual use cases.
> > >>>>>>>>>
> > >>>>>>>>> Regards,
> > >>>>>>>>> Justin
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
> > >>>>>>>>>
> > >>>>>>>> rombert@apache.org
> > >>>>
> > >>>>> wrote:
> > >>>>>>>>>> Hi,
> > >>>>>>>>>>
> > >>>>>>>>>> Following Antonio's kick-start of the Sling developer tooling
> > [1]
> > >>>>>>>>>>
> > >>>>>>>>> I've
> > >>>>
> > >>>>> gathered some thoughts about the initial goals and implementation
> of
> > >>>>>>>>>>
> > >>>>>>>>>>  our
> > >>>>>>>>> Sling IDE tooling.
> > >>>>>>>>>
> > >>>>>>>>>> The document is at [2] so please have a look and let me know
> > what
> > >>>>>>>>>>
> > >>>>>>>>> your
> > >>>>
> > >>>>> thoughts are. I intend to take a pass at the code next week and
> > >>>>>>>>>>
> > >>>>>>>>> align
> > >>>>
> > >>>>> it
> > >>>>>>>>> to the proposed structure, as a foundation for feature work.
> > >>>>>>>>>
> > >>>>>>>>>> Robert
> > >>>>>>>>>>
> > >>>>>>>>>> [1]: https://cwiki.apache.org/****SLING/slingclipse.html<
> > https://cwiki.apache.org/**SLING/slingclipse.html>
> > >>>>>>>>>> <
> > >>>>>>>>>>
> > >>>>>>>>> https://cwiki.apache.org/**SLING/slingclipse.html<
> > https://cwiki.apache.org/SLING/slingclipse.html>
> > >>>> >
> > >>>>
> > >>>>> [2]:
> > >>>>>>>>>>
> > >>>>>>>>>>  https://cwiki.apache.org/****confluence/display/SLING/**<
> > https://cwiki.apache.org/**confluence/display/SLING/**>
> > >>>>>>>>>
> > >>>>>>>> Sling+IDE+tooling<
> > >>>>>>>>
> > >>>>>>> https://cwiki.apache.org/**confluence/display/SLING/**
> > >>>> Sling+IDE+tooling<
> > https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
> > >>>> >
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> Carsten Ziegeler
> > >>> cziegeler@apache.org
> > >>>
> > >>
> > >
> >
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler <cz...@apache.org>]

For c) java code and bundles, I would suggest to leave this out for now and
see if we can integrate other tooling for that work. I'm currently
exploring options and maybe we can leverage other peoples work for that

Carsten


2013/6/2 Dominik Süß <do...@gmail.com>

> I'm trying to summarize my thoughts including the several opinions
> scenarios stated:
> a) The main usecase seems to be development from IDE (persisted to FS and
> therefore to be integreated with any FS based versioning tool of choice)
> b) a  (on save) sync the application from FS to Sling via IDE seems what
> everybody needs and agrees on
> c) Not directly mentioned but what I think should be defined as well how
> and when bundlebased (JAVA) code gets synced to the repository
> d) where I didn't hear consensus is about syncing from Sling to FS. The
> reason why I have my problem with that,  is that autosync needs an explicit
> definition how structures get mapped. In direction repository this is easy
> since this unwraps the filebased (xml or json) wrappers and creates a lot
> of finegrained strucures, but the other way around there would be the need
> of an implicit way how those structures get serialized to the FS or some
> (potentially) complex definition that a dev would have to make (possible
> with vault afaik, but IMHO errorprone).
> e) one of the main reasons for d is to see changes from the repository
> within the IDE. I here fully second Carsten that this shouldn't be
> automagically resolved but be controlled from the dev.  The IDE here can
> create some tooling to identify and display changes and support the job to
> reestablish synchronity (this might be the hardest part for the tooling
> since I  havent seen a proper ui doing such a job).
> f) regarding "sample" content mentioned by Ruben I think some
> packagingmechanism and a maven task to upload/download this package should
> besufficient (lock package, upload, change content in repo, download
> package, check in vcs)
>
> Cheers
> Dominik
>
>
> On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser <rr...@headwire.com> wrote:
>
> > we frequently have a content project during development with a sample
> site
> > that can be deployed over maven to a local dev instance. Maintaining the
> > sample content in the project requires to author in the cms and then sync
> > back to file system. Making bulk changes to the structure (for example,
> > globally rename a sling:resourceSuperType) is easier done in the IDE.
> > Content is then pushed back into the repository. I am not saying a
> constant
> > sync is needed, but a way for the IDE to 'update from repository' would
> > really help.
> >
> > The vlt sync command has another issue. Since it stores its state in the
> > local file system but relies on the server to manage the files your
> server
> > instance and file system can get out of sync (say your server crashes and
> > you have to reinstall it). Switching instances (say current version vs
> new
> > version) for testing purposes (is everything still working fine) is not
> > well supported either.
> >
> > Ruben
> >
> >
> > On 6/2/2013 6:35 AM, Antonio Sanso wrote:
> >
> >> On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler wrote:
> >>
> >>  I think a sync in both directions is problematic and I wouldn't go
> there
> >>> -
> >>> but I know that there only a few having this opinion.
> >>> In my opinion, when I'm talking about a developer that's someone who
> >>> develops code including scripts and usually Java - this might also
> >>> include
> >>> coding in client side stuff like js and css. There is the central tool
> >>> you
> >>> use for developing and that's the IDE with a strong integration into
> the
> >>> SCM (svn, git etc). The dev never has to leave this IDE for anything.
> In
> >>> this scenario, there is only a sync from IDE to Sling required - but
> not
> >>> the other way round.
> >>>
> >> +1
> >>
> >>  Whenever that's needed (syncing data from Sling into the file system)
> >>> this
> >>> should imho be an explicit decision by the dev - simply by invoking an
> >>> action from the IDE.
> >>>
> >> +1
> >>
> >> Regards
> >>
> >> Antonio
> >>
> >>
> >>  An automatic sync in both directions is dangerous and
> >>> imho in most cases not wanted/desired/required.
> >>>
> >>> As soon as we're talking about automatic sync from Sling to the project
> >>> checkout, this has a different style of development in mind - which I
> >>> think
> >>> we should not support when talking about IDE support. Either we support
> >>> IDE
> >>> development and then we do it right and have a style of working that
> does
> >>> not require to leave the IDE - or we do something different, but then
> >>> let's
> >>> make it clear that we don't plan to provide a true dev experience.
> >>>
> >>>
> >>> Carsten
> >>>
> >>>
> >>> 2013/6/1 Ian Boston <ie...@tfd.co.uk>
> >>>
> >>>  Hi,
> >>>> I've added the requirements for autosync to [1]. Although VLT does a
> >>>> good
> >>>> job of this once setup I don't use CLI for editing and manipulating. I
> >>>> use
> >>>> the IDE 100% with all its other tooling and just File Save.
> >>>> Setup with VLT is 2 commands and a 1 line config file edit, which
> could
> >>>> easily be converted into a IDE plugin.
> >>>>
> >>>> Having thought about it, I think the reason vlt sync works well is
> that
> >>>> Sling is on the same box, monitoring the file system for changes, (I
> >>>> think
> >>>> thats right, there is no local process with vlt sync) and monitoring
> JCR
> >>>> for changes, which avoids lots of processing and http traffic. When I
> >>>> have
> >>>> used other forms of integration on large repositories, the volume http
> >>>> traffic and speed of response has nearly always made them unusable.
> >>>>
> >>>> What ever is used or reimplemented it must not rely on scanning a
> >>>> repository to know what has changed. It must relay on notification of
> >>>> some
> >>>> form so that Edit->Save->Refresh is never more than a few seconds, and
> >>>> doesn't impact the Sling server resource usage. Ideally notification
> >>>> should
> >>>> not rely on the IDE, since changes can be made without the IDE
> running,
> >>>> and
> >>>> routing it via the IDE is going to get really confusing with 3 or more
> >>>> potential sources of updates. (assuming code under version control)
> >>>>
> >>>> HTH
> >>>> Ian
> >>>>
> >>>> 1. https://cwiki.apache.org/**confluence/display/SLING/Use+**Cases<
> https://cwiki.apache.org/confluence/display/SLING/Use+Cases>
> >>>>
> >>>>
> >>>> On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:
> >>>>
> >>>>  @Justin, will do.
> >>>>>
> >>>>> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about
> >>>>> its
> >>>>> internals).
> >>>>>
> >>>>>
> >>>>> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
> >>>>>
> >>>>>  is the vlt sync now actually updating .content.xml files? I thought
> it
> >>>>>> can only sync regular files.
> >>>>>>
> >>>>>> Ruben
> >>>>>>
> >>>>>>
> >>>>>> On 5/30/2013 7:24 PM, Justin Edelson wrote:
> >>>>>>
> >>>>>>  Ian - please do add the autosync use case to the wiki page I
> created.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>> +1 to that. After working on sling for many years doing a mixture
> of
> >>>>>>>> bundle
> >>>>>>>> and UI work, mainly using the FileSystemResolver bundle, I realise
> >>>>>>>> now
> >>>>>>>> if
> >>>>>>>> VLT had been available with sync mode (ie auto syncing the repo
> and
> >>>>>>>>
> >>>>>>> the
> >>>>
> >>>>> file system), we (the team I was working with at the time) would have
> >>>>>>>> made
> >>>>>>>> much more rapid progress. UI dev work needs file-save-refresh. The
> >>>>>>>> in
> >>>>>>>> browser editing UIs deliver this, as does VLT in sync mode, but
> >>>>>>>> unfortunately native eclipse based tooling is just too slow (on my
> >>>>>>>> machine,
> >>>>>>>> might be my machine). Using VLT since I joined Adobe, has been a
> >>>>>>>> joy,
> >>>>>>>> and I
> >>>>>>>> am very glad to know its being donated to the ASF.
> >>>>>>>>
> >>>>>>>> Had we had VLT then, we would have developed in a very different
> >>>>>>>> way,
> >>>>>>>> and
> >>>>>>>> might not have had half the problems we had with tooling and team
> >>>>>>>> structure.
> >>>>>>>> Ian
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
> >>>>>>>>
> >>>>>>> wrote:
> >>>>
> >>>>> Hi,
> >>>>>>>>
> >>>>>>>>> I would strongly suggest that this effort be based on VLT. As
> >>>>>>>>>
> >>>>>>>> mentioned
> >>>>
> >>>>> on
> >>>>>>>>
> >>>>>>>>  the wiki page, we're in the process of moving that to ASF and I
> >>>>>>>>> think
> >>>>>>>>>
> >>>>>>>>>  once
> >>>>>>>>
> >>>>>>>>  the code is available, it will be clear that it provides a good
> >>>>>>>>> low-level
> >>>>>>>>> interface for this type of UI.
> >>>>>>>>>
> >>>>>>>>> While it is true that VLT currently only works with DavEX
> servers,
> >>>>>>>>> I
> >>>>>>>>> suspect it would not be hard to isolate the "Ex" bits and have a
> >>>>>>>>> "WebDAV"
> >>>>>>>>> only driver which could be used on non-JCR applications for basic
> >>>>>>>>>
> >>>>>>>> file
> >>>>
> >>>>> operations.
> >>>>>>>>>
> >>>>>>>>> My concern is that we end up building one more abstraction which
> is
> >>>>>>>>> going
> >>>>>>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR,
> MK,
> >>>>>>>>>
> >>>>>>>>>  etc.).
> >>>>>>>>
> >>>>>>>>  I know VLT has some baggage, but I'd just ask that people keep an
> >>>>>>>>>
> >>>>>>>> open
> >>>>
> >>>>> mind.
> >>>>>>>>>
> >>>>>>>>> Separately, I'm going to start a child page of this wiki page to
> >>>>>>>>>
> >>>>>>>> gather
> >>>>
> >>>>> use
> >>>>>>>>
> >>>>>>>>  cases. There are some functional areas listed on the main page,
> >>>>>>>>> but I
> >>>>>>>>>
> >>>>>>>>>  think
> >>>>>>>>
> >>>>>>>>  we should try to capture individual use cases.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Justin
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
> >>>>>>>>>
> >>>>>>>> rombert@apache.org
> >>>>
> >>>>> wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> Following Antonio's kick-start of the Sling developer tooling
> [1]
> >>>>>>>>>>
> >>>>>>>>> I've
> >>>>
> >>>>> gathered some thoughts about the initial goals and implementation of
> >>>>>>>>>>
> >>>>>>>>>>  our
> >>>>>>>>> Sling IDE tooling.
> >>>>>>>>>
> >>>>>>>>>> The document is at [2] so please have a look and let me know
> what
> >>>>>>>>>>
> >>>>>>>>> your
> >>>>
> >>>>> thoughts are. I intend to take a pass at the code next week and
> >>>>>>>>>>
> >>>>>>>>> align
> >>>>
> >>>>> it
> >>>>>>>>> to the proposed structure, as a foundation for feature work.
> >>>>>>>>>
> >>>>>>>>>> Robert
> >>>>>>>>>>
> >>>>>>>>>> [1]: https://cwiki.apache.org/****SLING/slingclipse.html<
> https://cwiki.apache.org/**SLING/slingclipse.html>
> >>>>>>>>>> <
> >>>>>>>>>>
> >>>>>>>>> https://cwiki.apache.org/**SLING/slingclipse.html<
> https://cwiki.apache.org/SLING/slingclipse.html>
> >>>> >
> >>>>
> >>>>> [2]:
> >>>>>>>>>>
> >>>>>>>>>>  https://cwiki.apache.org/****confluence/display/SLING/**<
> https://cwiki.apache.org/**confluence/display/SLING/**>
> >>>>>>>>>
> >>>>>>>> Sling+IDE+tooling<
> >>>>>>>>
> >>>>>>> https://cwiki.apache.org/**confluence/display/SLING/**
> >>>> Sling+IDE+tooling<
> https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
> >>>> >
> >>>>
> >>>
> >>>
> >>> --
> >>> Carsten Ziegeler
> >>> cziegeler@apache.org
> >>>
> >>
> >
>



-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Dominik Süß <do...@gmail.com>]

I'm trying to summarize my thoughts including the several opinions
scenarios stated:
a) The main usecase seems to be development from IDE (persisted to FS and
therefore to be integreated with any FS based versioning tool of choice)
b) a  (on save) sync the application from FS to Sling via IDE seems what
everybody needs and agrees on
c) Not directly mentioned but what I think should be defined as well how
and when bundlebased (JAVA) code gets synced to the repository
d) where I didn't hear consensus is about syncing from Sling to FS. The
reason why I have my problem with that,  is that autosync needs an explicit
definition how structures get mapped. In direction repository this is easy
since this unwraps the filebased (xml or json) wrappers and creates a lot
of finegrained strucures, but the other way around there would be the need
of an implicit way how those structures get serialized to the FS or some
(potentially) complex definition that a dev would have to make (possible
with vault afaik, but IMHO errorprone).
e) one of the main reasons for d is to see changes from the repository
within the IDE. I here fully second Carsten that this shouldn't be
automagically resolved but be controlled from the dev.  The IDE here can
create some tooling to identify and display changes and support the job to
reestablish synchronity (this might be the hardest part for the tooling
since I  havent seen a proper ui doing such a job).
f) regarding "sample" content mentioned by Ruben I think some
packagingmechanism and a maven task to upload/download this package should
besufficient (lock package, upload, change content in repo, download
package, check in vcs)

Cheers
Dominik


On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser <rr...@headwire.com> wrote:

> we frequently have a content project during development with a sample site
> that can be deployed over maven to a local dev instance. Maintaining the
> sample content in the project requires to author in the cms and then sync
> back to file system. Making bulk changes to the structure (for example,
> globally rename a sling:resourceSuperType) is easier done in the IDE.
> Content is then pushed back into the repository. I am not saying a constant
> sync is needed, but a way for the IDE to 'update from repository' would
> really help.
>
> The vlt sync command has another issue. Since it stores its state in the
> local file system but relies on the server to manage the files your server
> instance and file system can get out of sync (say your server crashes and
> you have to reinstall it). Switching instances (say current version vs new
> version) for testing purposes (is everything still working fine) is not
> well supported either.
>
> Ruben
>
>
> On 6/2/2013 6:35 AM, Antonio Sanso wrote:
>
>> On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler wrote:
>>
>>  I think a sync in both directions is problematic and I wouldn't go there
>>> -
>>> but I know that there only a few having this opinion.
>>> In my opinion, when I'm talking about a developer that's someone who
>>> develops code including scripts and usually Java - this might also
>>> include
>>> coding in client side stuff like js and css. There is the central tool
>>> you
>>> use for developing and that's the IDE with a strong integration into the
>>> SCM (svn, git etc). The dev never has to leave this IDE for anything. In
>>> this scenario, there is only a sync from IDE to Sling required - but not
>>> the other way round.
>>>
>> +1
>>
>>  Whenever that's needed (syncing data from Sling into the file system)
>>> this
>>> should imho be an explicit decision by the dev - simply by invoking an
>>> action from the IDE.
>>>
>> +1
>>
>> Regards
>>
>> Antonio
>>
>>
>>  An automatic sync in both directions is dangerous and
>>> imho in most cases not wanted/desired/required.
>>>
>>> As soon as we're talking about automatic sync from Sling to the project
>>> checkout, this has a different style of development in mind - which I
>>> think
>>> we should not support when talking about IDE support. Either we support
>>> IDE
>>> development and then we do it right and have a style of working that does
>>> not require to leave the IDE - or we do something different, but then
>>> let's
>>> make it clear that we don't plan to provide a true dev experience.
>>>
>>>
>>> Carsten
>>>
>>>
>>> 2013/6/1 Ian Boston <ie...@tfd.co.uk>
>>>
>>>  Hi,
>>>> I've added the requirements for autosync to [1]. Although VLT does a
>>>> good
>>>> job of this once setup I don't use CLI for editing and manipulating. I
>>>> use
>>>> the IDE 100% with all its other tooling and just File Save.
>>>> Setup with VLT is 2 commands and a 1 line config file edit, which could
>>>> easily be converted into a IDE plugin.
>>>>
>>>> Having thought about it, I think the reason vlt sync works well is that
>>>> Sling is on the same box, monitoring the file system for changes, (I
>>>> think
>>>> thats right, there is no local process with vlt sync) and monitoring JCR
>>>> for changes, which avoids lots of processing and http traffic. When I
>>>> have
>>>> used other forms of integration on large repositories, the volume http
>>>> traffic and speed of response has nearly always made them unusable.
>>>>
>>>> What ever is used or reimplemented it must not rely on scanning a
>>>> repository to know what has changed. It must relay on notification of
>>>> some
>>>> form so that Edit->Save->Refresh is never more than a few seconds, and
>>>> doesn't impact the Sling server resource usage. Ideally notification
>>>> should
>>>> not rely on the IDE, since changes can be made without the IDE running,
>>>> and
>>>> routing it via the IDE is going to get really confusing with 3 or more
>>>> potential sources of updates. (assuming code under version control)
>>>>
>>>> HTH
>>>> Ian
>>>>
>>>> 1. https://cwiki.apache.org/**confluence/display/SLING/Use+**Cases<https://cwiki.apache.org/confluence/display/SLING/Use+Cases>
>>>>
>>>>
>>>> On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>
>>>>  @Justin, will do.
>>>>>
>>>>> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about
>>>>> its
>>>>> internals).
>>>>>
>>>>>
>>>>> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
>>>>>
>>>>>  is the vlt sync now actually updating .content.xml files? I thought it
>>>>>> can only sync regular files.
>>>>>>
>>>>>> Ruben
>>>>>>
>>>>>>
>>>>>> On 5/30/2013 7:24 PM, Justin Edelson wrote:
>>>>>>
>>>>>>  Ian - please do add the autosync use case to the wiki page I created.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>>> +1 to that. After working on sling for many years doing a mixture of
>>>>>>>> bundle
>>>>>>>> and UI work, mainly using the FileSystemResolver bundle, I realise
>>>>>>>> now
>>>>>>>> if
>>>>>>>> VLT had been available with sync mode (ie auto syncing the repo and
>>>>>>>>
>>>>>>> the
>>>>
>>>>> file system), we (the team I was working with at the time) would have
>>>>>>>> made
>>>>>>>> much more rapid progress. UI dev work needs file-save-refresh. The
>>>>>>>> in
>>>>>>>> browser editing UIs deliver this, as does VLT in sync mode, but
>>>>>>>> unfortunately native eclipse based tooling is just too slow (on my
>>>>>>>> machine,
>>>>>>>> might be my machine). Using VLT since I joined Adobe, has been a
>>>>>>>> joy,
>>>>>>>> and I
>>>>>>>> am very glad to know its being donated to the ASF.
>>>>>>>>
>>>>>>>> Had we had VLT then, we would have developed in a very different
>>>>>>>> way,
>>>>>>>> and
>>>>>>>> might not have had half the problems we had with tooling and team
>>>>>>>> structure.
>>>>>>>> Ian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
>>>>>>>>
>>>>>>> wrote:
>>>>
>>>>> Hi,
>>>>>>>>
>>>>>>>>> I would strongly suggest that this effort be based on VLT. As
>>>>>>>>>
>>>>>>>> mentioned
>>>>
>>>>> on
>>>>>>>>
>>>>>>>>  the wiki page, we're in the process of moving that to ASF and I
>>>>>>>>> think
>>>>>>>>>
>>>>>>>>>  once
>>>>>>>>
>>>>>>>>  the code is available, it will be clear that it provides a good
>>>>>>>>> low-level
>>>>>>>>> interface for this type of UI.
>>>>>>>>>
>>>>>>>>> While it is true that VLT currently only works with DavEX servers,
>>>>>>>>> I
>>>>>>>>> suspect it would not be hard to isolate the "Ex" bits and have a
>>>>>>>>> "WebDAV"
>>>>>>>>> only driver which could be used on non-JCR applications for basic
>>>>>>>>>
>>>>>>>> file
>>>>
>>>>> operations.
>>>>>>>>>
>>>>>>>>> My concern is that we end up building one more abstraction which is
>>>>>>>>> going
>>>>>>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
>>>>>>>>>
>>>>>>>>>  etc.).
>>>>>>>>
>>>>>>>>  I know VLT has some baggage, but I'd just ask that people keep an
>>>>>>>>>
>>>>>>>> open
>>>>
>>>>> mind.
>>>>>>>>>
>>>>>>>>> Separately, I'm going to start a child page of this wiki page to
>>>>>>>>>
>>>>>>>> gather
>>>>
>>>>> use
>>>>>>>>
>>>>>>>>  cases. There are some functional areas listed on the main page,
>>>>>>>>> but I
>>>>>>>>>
>>>>>>>>>  think
>>>>>>>>
>>>>>>>>  we should try to capture individual use cases.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Justin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
>>>>>>>>>
>>>>>>>> rombert@apache.org
>>>>
>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Following Antonio's kick-start of the Sling developer tooling [1]
>>>>>>>>>>
>>>>>>>>> I've
>>>>
>>>>> gathered some thoughts about the initial goals and implementation of
>>>>>>>>>>
>>>>>>>>>>  our
>>>>>>>>> Sling IDE tooling.
>>>>>>>>>
>>>>>>>>>> The document is at [2] so please have a look and let me know what
>>>>>>>>>>
>>>>>>>>> your
>>>>
>>>>> thoughts are. I intend to take a pass at the code next week and
>>>>>>>>>>
>>>>>>>>> align
>>>>
>>>>> it
>>>>>>>>> to the proposed structure, as a foundation for feature work.
>>>>>>>>>
>>>>>>>>>> Robert
>>>>>>>>>>
>>>>>>>>>> [1]: https://cwiki.apache.org/****SLING/slingclipse.html<https://cwiki.apache.org/**SLING/slingclipse.html>
>>>>>>>>>> <
>>>>>>>>>>
>>>>>>>>> https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.apache.org/SLING/slingclipse.html>
>>>> >
>>>>
>>>>> [2]:
>>>>>>>>>>
>>>>>>>>>>  https://cwiki.apache.org/****confluence/display/SLING/**<https://cwiki.apache.org/**confluence/display/SLING/**>
>>>>>>>>>
>>>>>>>> Sling+IDE+tooling<
>>>>>>>>
>>>>>>> https://cwiki.apache.org/**confluence/display/SLING/**
>>>> Sling+IDE+tooling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
>>>> >
>>>>
>>>
>>>
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org
>>>
>>
>

Re: [tooling] Moving forward with IDE tooling

[Ruben Reusser <rr...@headwire.com>]

we frequently have a content project during development with a sample 
site that can be deployed over maven to a local dev instance. 
Maintaining the sample content in the project requires to author in the 
cms and then sync back to file system. Making bulk changes to the 
structure (for example, globally rename a sling:resourceSuperType) is 
easier done in the IDE. Content is then pushed back into the repository. 
I am not saying a constant sync is needed, but a way for the IDE to 
'update from repository' would really help.

The vlt sync command has another issue. Since it stores its state in the 
local file system but relies on the server to manage the files your 
server instance and file system can get out of sync (say your server 
crashes and you have to reinstall it). Switching instances (say current 
version vs new version) for testing purposes (is everything still 
working fine) is not well supported either.

Ruben

On 6/2/2013 6:35 AM, Antonio Sanso wrote:
> On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler wrote:
>
>> I think a sync in both directions is problematic and I wouldn't go there -
>> but I know that there only a few having this opinion.
>> In my opinion, when I'm talking about a developer that's someone who
>> develops code including scripts and usually Java - this might also include
>> coding in client side stuff like js and css. There is the central tool you
>> use for developing and that's the IDE with a strong integration into the
>> SCM (svn, git etc). The dev never has to leave this IDE for anything. In
>> this scenario, there is only a sync from IDE to Sling required - but not
>> the other way round.
> +1
>
>> Whenever that's needed (syncing data from Sling into the file system) this
>> should imho be an explicit decision by the dev - simply by invoking an
>> action from the IDE.
> +1
>
> Regards
>
> Antonio
>
>
>> An automatic sync in both directions is dangerous and
>> imho in most cases not wanted/desired/required.
>>
>> As soon as we're talking about automatic sync from Sling to the project
>> checkout, this has a different style of development in mind - which I think
>> we should not support when talking about IDE support. Either we support IDE
>> development and then we do it right and have a style of working that does
>> not require to leave the IDE - or we do something different, but then let's
>> make it clear that we don't plan to provide a true dev experience.
>>
>>
>> Carsten
>>
>>
>> 2013/6/1 Ian Boston <ie...@tfd.co.uk>
>>
>>> Hi,
>>> I've added the requirements for autosync to [1]. Although VLT does a good
>>> job of this once setup I don't use CLI for editing and manipulating. I use
>>> the IDE 100% with all its other tooling and just File Save.
>>> Setup with VLT is 2 commands and a 1 line config file edit, which could
>>> easily be converted into a IDE plugin.
>>>
>>> Having thought about it, I think the reason vlt sync works well is that
>>> Sling is on the same box, monitoring the file system for changes, (I think
>>> thats right, there is no local process with vlt sync) and monitoring JCR
>>> for changes, which avoids lots of processing and http traffic. When I have
>>> used other forms of integration on large repositories, the volume http
>>> traffic and speed of response has nearly always made them unusable.
>>>
>>> What ever is used or reimplemented it must not rely on scanning a
>>> repository to know what has changed. It must relay on notification of some
>>> form so that Edit->Save->Refresh is never more than a few seconds, and
>>> doesn't impact the Sling server resource usage. Ideally notification should
>>> not rely on the IDE, since changes can be made without the IDE running, and
>>> routing it via the IDE is going to get really confusing with 3 or more
>>> potential sources of updates. (assuming code under version control)
>>>
>>> HTH
>>> Ian
>>>
>>> 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases
>>>
>>>
>>> On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:
>>>
>>>> @Justin, will do.
>>>>
>>>> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
>>>> internals).
>>>>
>>>>
>>>> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
>>>>
>>>>> is the vlt sync now actually updating .content.xml files? I thought it
>>>>> can only sync regular files.
>>>>>
>>>>> Ruben
>>>>>
>>>>>
>>>>> On 5/30/2013 7:24 PM, Justin Edelson wrote:
>>>>>
>>>>>> Ian - please do add the autosync use case to the wiki page I created.
>>>>>>
>>>>>>
>>>>>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>> +1 to that. After working on sling for many years doing a mixture of
>>>>>>> bundle
>>>>>>> and UI work, mainly using the FileSystemResolver bundle, I realise now
>>>>>>> if
>>>>>>> VLT had been available with sync mode (ie auto syncing the repo and
>>> the
>>>>>>> file system), we (the team I was working with at the time) would have
>>>>>>> made
>>>>>>> much more rapid progress. UI dev work needs file-save-refresh. The in
>>>>>>> browser editing UIs deliver this, as does VLT in sync mode, but
>>>>>>> unfortunately native eclipse based tooling is just too slow (on my
>>>>>>> machine,
>>>>>>> might be my machine). Using VLT since I joined Adobe, has been a joy,
>>>>>>> and I
>>>>>>> am very glad to know its being donated to the ASF.
>>>>>>>
>>>>>>> Had we had VLT then, we would have developed in a very different way,
>>>>>>> and
>>>>>>> might not have had half the problems we had with tooling and team
>>>>>>> structure.
>>>>>>> Ian
>>>>>>>
>>>>>>>
>>>>>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
>>> wrote:
>>>>>>> Hi,
>>>>>>>> I would strongly suggest that this effort be based on VLT. As
>>> mentioned
>>>>>>> on
>>>>>>>
>>>>>>>> the wiki page, we're in the process of moving that to ASF and I think
>>>>>>>>
>>>>>>> once
>>>>>>>
>>>>>>>> the code is available, it will be clear that it provides a good
>>>>>>>> low-level
>>>>>>>> interface for this type of UI.
>>>>>>>>
>>>>>>>> While it is true that VLT currently only works with DavEX servers, I
>>>>>>>> suspect it would not be hard to isolate the "Ex" bits and have a
>>>>>>>> "WebDAV"
>>>>>>>> only driver which could be used on non-JCR applications for basic
>>> file
>>>>>>>> operations.
>>>>>>>>
>>>>>>>> My concern is that we end up building one more abstraction which is
>>>>>>>> going
>>>>>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
>>>>>>>>
>>>>>>> etc.).
>>>>>>>
>>>>>>>> I know VLT has some baggage, but I'd just ask that people keep an
>>> open
>>>>>>>> mind.
>>>>>>>>
>>>>>>>> Separately, I'm going to start a child page of this wiki page to
>>> gather
>>>>>>> use
>>>>>>>
>>>>>>>> cases. There are some functional areas listed on the main page, but I
>>>>>>>>
>>>>>>> think
>>>>>>>
>>>>>>>> we should try to capture individual use cases.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Justin
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
>>> rombert@apache.org
>>>>>>>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Following Antonio's kick-start of the Sling developer tooling [1]
>>> I've
>>>>>>>>> gathered some thoughts about the initial goals and implementation of
>>>>>>>>>
>>>>>>>> our
>>>>>>>> Sling IDE tooling.
>>>>>>>>> The document is at [2] so please have a look and let me know what
>>> your
>>>>>>>>> thoughts are. I intend to take a pass at the code next week and
>>> align
>>>>>>>> it
>>>>>>>> to the proposed structure, as a foundation for feature work.
>>>>>>>>> Robert
>>>>>>>>>
>>>>>>>>> [1]: https://cwiki.apache.org/**SLING/slingclipse.html<
>>> https://cwiki.apache.org/SLING/slingclipse.html>
>>>>>>>>> [2]:
>>>>>>>>>
>>>>>>>> https://cwiki.apache.org/**confluence/display/SLING/**
>>>>>>> Sling+IDE+tooling<
>>> https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
>>
>>
>> -- 
>> Carsten Ziegeler
>> cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Antonio Sanso <as...@adobe.com>]

On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler wrote:

> I think a sync in both directions is problematic and I wouldn't go there -
> but I know that there only a few having this opinion.
> In my opinion, when I'm talking about a developer that's someone who
> develops code including scripts and usually Java - this might also include
> coding in client side stuff like js and css. There is the central tool you
> use for developing and that's the IDE with a strong integration into the
> SCM (svn, git etc). The dev never has to leave this IDE for anything. In
> this scenario, there is only a sync from IDE to Sling required - but not
> the other way round.

+1

> Whenever that's needed (syncing data from Sling into the file system) this
> should imho be an explicit decision by the dev - simply by invoking an
> action from the IDE.

+1 

Regards

Antonio


> An automatic sync in both directions is dangerous and
> imho in most cases not wanted/desired/required.
> 
> As soon as we're talking about automatic sync from Sling to the project
> checkout, this has a different style of development in mind - which I think
> we should not support when talking about IDE support. Either we support IDE
> development and then we do it right and have a style of working that does
> not require to leave the IDE - or we do something different, but then let's
> make it clear that we don't plan to provide a true dev experience.
> 
> 
> Carsten
> 
> 
> 2013/6/1 Ian Boston <ie...@tfd.co.uk>
> 
>> Hi,
>> I've added the requirements for autosync to [1]. Although VLT does a good
>> job of this once setup I don't use CLI for editing and manipulating. I use
>> the IDE 100% with all its other tooling and just File Save.
>> Setup with VLT is 2 commands and a 1 line config file edit, which could
>> easily be converted into a IDE plugin.
>> 
>> Having thought about it, I think the reason vlt sync works well is that
>> Sling is on the same box, monitoring the file system for changes, (I think
>> thats right, there is no local process with vlt sync) and monitoring JCR
>> for changes, which avoids lots of processing and http traffic. When I have
>> used other forms of integration on large repositories, the volume http
>> traffic and speed of response has nearly always made them unusable.
>> 
>> What ever is used or reimplemented it must not rely on scanning a
>> repository to know what has changed. It must relay on notification of some
>> form so that Edit->Save->Refresh is never more than a few seconds, and
>> doesn't impact the Sling server resource usage. Ideally notification should
>> not rely on the IDE, since changes can be made without the IDE running, and
>> routing it via the IDE is going to get really confusing with 3 or more
>> potential sources of updates. (assuming code under version control)
>> 
>> HTH
>> Ian
>> 
>> 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases
>> 
>> 
>> On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:
>> 
>>> @Justin, will do.
>>> 
>>> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
>>> internals).
>>> 
>>> 
>>> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
>>> 
>>>> is the vlt sync now actually updating .content.xml files? I thought it
>>>> can only sync regular files.
>>>> 
>>>> Ruben
>>>> 
>>>> 
>>>> On 5/30/2013 7:24 PM, Justin Edelson wrote:
>>>> 
>>>>> Ian - please do add the autosync use case to the wiki page I created.
>>>>> 
>>>>> 
>>>>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>> 
>>>>> Hi,
>>>>>> +1 to that. After working on sling for many years doing a mixture of
>>>>>> bundle
>>>>>> and UI work, mainly using the FileSystemResolver bundle, I realise now
>>>>>> if
>>>>>> VLT had been available with sync mode (ie auto syncing the repo and
>> the
>>>>>> file system), we (the team I was working with at the time) would have
>>>>>> made
>>>>>> much more rapid progress. UI dev work needs file-save-refresh. The in
>>>>>> browser editing UIs deliver this, as does VLT in sync mode, but
>>>>>> unfortunately native eclipse based tooling is just too slow (on my
>>>>>> machine,
>>>>>> might be my machine). Using VLT since I joined Adobe, has been a joy,
>>>>>> and I
>>>>>> am very glad to know its being donated to the ASF.
>>>>>> 
>>>>>> Had we had VLT then, we would have developed in a very different way,
>>>>>> and
>>>>>> might not have had half the problems we had with tooling and team
>>>>>> structure.
>>>>>> Ian
>>>>>> 
>>>>>> 
>>>>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>>> I would strongly suggest that this effort be based on VLT. As
>> mentioned
>>>>>>> 
>>>>>> on
>>>>>> 
>>>>>>> the wiki page, we're in the process of moving that to ASF and I think
>>>>>>> 
>>>>>> once
>>>>>> 
>>>>>>> the code is available, it will be clear that it provides a good
>>>>>>> low-level
>>>>>>> interface for this type of UI.
>>>>>>> 
>>>>>>> While it is true that VLT currently only works with DavEX servers, I
>>>>>>> suspect it would not be hard to isolate the "Ex" bits and have a
>>>>>>> "WebDAV"
>>>>>>> only driver which could be used on non-JCR applications for basic
>> file
>>>>>>> operations.
>>>>>>> 
>>>>>>> My concern is that we end up building one more abstraction which is
>>>>>>> going
>>>>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
>>>>>>> 
>>>>>> etc.).
>>>>>> 
>>>>>>> I know VLT has some baggage, but I'd just ask that people keep an
>> open
>>>>>>> mind.
>>>>>>> 
>>>>>>> Separately, I'm going to start a child page of this wiki page to
>> gather
>>>>>>> 
>>>>>> use
>>>>>> 
>>>>>>> cases. There are some functional areas listed on the main page, but I
>>>>>>> 
>>>>>> think
>>>>>> 
>>>>>>> we should try to capture individual use cases.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Justin
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
>> rombert@apache.org
>>>>>>> 
>>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Following Antonio's kick-start of the Sling developer tooling [1]
>> I've
>>>>>>>> gathered some thoughts about the initial goals and implementation of
>>>>>>>> 
>>>>>>> our
>>>>>> 
>>>>>>> Sling IDE tooling.
>>>>>>>> 
>>>>>>>> The document is at [2] so please have a look and let me know what
>> your
>>>>>>>> thoughts are. I intend to take a pass at the code next week and
>> align
>>>>>>>> 
>>>>>>> it
>>>>>> 
>>>>>>> to the proposed structure, as a foundation for feature work.
>>>>>>>> 
>>>>>>>> Robert
>>>>>>>> 
>>>>>>>> [1]: https://cwiki.apache.org/**SLING/slingclipse.html<
>> https://cwiki.apache.org/SLING/slingclipse.html>
>>>>>>>> [2]:
>>>>>>>> 
>>>>>>> https://cwiki.apache.org/**confluence/display/SLING/**
>>>>>> Sling+IDE+tooling<
>> https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Alexander Klimetschek <ak...@adobe.com>]

Including Toby, who is planning to contribute vault to Apache Jackrabbit.

I think the plan was to simplify vault CLI & sync along the way, and only allow full pushs in either direction, instead of having commit & update work on individual files. This would mean some operation like "get all changes from the server".

Cheers,
Alex

On 02.06.2013, at 10:41, Carsten Ziegeler <cz...@apache.org> wrote:

> I think a sync in both directions is problematic and I wouldn't go there -
> but I know that there only a few having this opinion.
> In my opinion, when I'm talking about a developer that's someone who
> develops code including scripts and usually Java - this might also include
> coding in client side stuff like js and css. There is the central tool you
> use for developing and that's the IDE with a strong integration into the
> SCM (svn, git etc). The dev never has to leave this IDE for anything. In
> this scenario, there is only a sync from IDE to Sling required - but not
> the other way round.
> Whenever that's needed (syncing data from Sling into the file system) this
> should imho be an explicit decision by the dev - simply by invoking an
> action from the IDE. An automatic sync in both directions is dangerous and
> imho in most cases not wanted/desired/required.
> 
> As soon as we're talking about automatic sync from Sling to the project
> checkout, this has a different style of development in mind - which I think
> we should not support when talking about IDE support. Either we support IDE
> development and then we do it right and have a style of working that does
> not require to leave the IDE - or we do something different, but then let's
> make it clear that we don't plan to provide a true dev experience.
> 
> 
> Carsten
> 
> 
> 2013/6/1 Ian Boston <ie...@tfd.co.uk>
> 
>> Hi,
>> I've added the requirements for autosync to [1]. Although VLT does a good
>> job of this once setup I don't use CLI for editing and manipulating. I use
>> the IDE 100% with all its other tooling and just File Save.
>> Setup with VLT is 2 commands and a 1 line config file edit, which could
>> easily be converted into a IDE plugin.
>> 
>> Having thought about it, I think the reason vlt sync works well is that
>> Sling is on the same box, monitoring the file system for changes, (I think
>> thats right, there is no local process with vlt sync) and monitoring JCR
>> for changes, which avoids lots of processing and http traffic. When I have
>> used other forms of integration on large repositories, the volume http
>> traffic and speed of response has nearly always made them unusable.
>> 
>> What ever is used or reimplemented it must not rely on scanning a
>> repository to know what has changed. It must relay on notification of some
>> form so that Edit->Save->Refresh is never more than a few seconds, and
>> doesn't impact the Sling server resource usage. Ideally notification should
>> not rely on the IDE, since changes can be made without the IDE running, and
>> routing it via the IDE is going to get really confusing with 3 or more
>> potential sources of updates. (assuming code under version control)
>> 
>> HTH
>> Ian
>> 
>> 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases
>> 
>> 
>> On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:
>> 
>>> @Justin, will do.
>>> 
>>> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
>>> internals).
>>> 
>>> 
>>> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
>>> 
>>>> is the vlt sync now actually updating .content.xml files? I thought it
>>>> can only sync regular files.
>>>> 
>>>> Ruben
>>>> 
>>>> 
>>>> On 5/30/2013 7:24 PM, Justin Edelson wrote:
>>>> 
>>>>> Ian - please do add the autosync use case to the wiki page I created.
>>>>> 
>>>>> 
>>>>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>>> 
>>>>> Hi,
>>>>>> +1 to that. After working on sling for many years doing a mixture of
>>>>>> bundle
>>>>>> and UI work, mainly using the FileSystemResolver bundle, I realise now
>>>>>> if
>>>>>> VLT had been available with sync mode (ie auto syncing the repo and
>> the
>>>>>> file system), we (the team I was working with at the time) would have
>>>>>> made
>>>>>> much more rapid progress. UI dev work needs file-save-refresh. The in
>>>>>> browser editing UIs deliver this, as does VLT in sync mode, but
>>>>>> unfortunately native eclipse based tooling is just too slow (on my
>>>>>> machine,
>>>>>> might be my machine). Using VLT since I joined Adobe, has been a joy,
>>>>>> and I
>>>>>> am very glad to know its being donated to the ASF.
>>>>>> 
>>>>>> Had we had VLT then, we would have developed in a very different way,
>>>>>> and
>>>>>> might not have had half the problems we had with tooling and team
>>>>>> structure.
>>>>>> Ian
>>>>>> 
>>>>>> 
>>>>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>>> I would strongly suggest that this effort be based on VLT. As
>> mentioned
>>>>>>> 
>>>>>> on
>>>>>> 
>>>>>>> the wiki page, we're in the process of moving that to ASF and I think
>>>>>>> 
>>>>>> once
>>>>>> 
>>>>>>> the code is available, it will be clear that it provides a good
>>>>>>> low-level
>>>>>>> interface for this type of UI.
>>>>>>> 
>>>>>>> While it is true that VLT currently only works with DavEX servers, I
>>>>>>> suspect it would not be hard to isolate the "Ex" bits and have a
>>>>>>> "WebDAV"
>>>>>>> only driver which could be used on non-JCR applications for basic
>> file
>>>>>>> operations.
>>>>>>> 
>>>>>>> My concern is that we end up building one more abstraction which is
>>>>>>> going
>>>>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
>>>>>>> 
>>>>>> etc.).
>>>>>> 
>>>>>>> I know VLT has some baggage, but I'd just ask that people keep an
>> open
>>>>>>> mind.
>>>>>>> 
>>>>>>> Separately, I'm going to start a child page of this wiki page to
>> gather
>>>>>>> 
>>>>>> use
>>>>>> 
>>>>>>> cases. There are some functional areas listed on the main page, but I
>>>>>>> 
>>>>>> think
>>>>>> 
>>>>>>> we should try to capture individual use cases.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Justin
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
>> rombert@apache.org
>>>>>>> 
>>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Following Antonio's kick-start of the Sling developer tooling [1]
>> I've
>>>>>>>> gathered some thoughts about the initial goals and implementation of
>>>>>>>> 
>>>>>>> our
>>>>>> 
>>>>>>> Sling IDE tooling.
>>>>>>>> 
>>>>>>>> The document is at [2] so please have a look and let me know what
>> your
>>>>>>>> thoughts are. I intend to take a pass at the code next week and
>> align
>>>>>>>> 
>>>>>>> it
>>>>>> 
>>>>>>> to the proposed structure, as a foundation for feature work.
>>>>>>>> 
>>>>>>>> Robert
>>>>>>>> 
>>>>>>>> [1]: https://cwiki.apache.org/**SLING/slingclipse.html<
>> https://cwiki.apache.org/SLING/slingclipse.html>
>>>>>>>> [2]:
>>>>>>>> 
>>>>>>> https://cwiki.apache.org/**confluence/display/SLING/**
>>>>>> Sling+IDE+tooling<
>> https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> cziegeler@apache.org

RE: [tooling] Moving forward with IDE tooling

[Dan Klco <da...@sixdimensions.com>]

Seems like that would require a lot of content to be potentially updated.  Would this be possible to handle as part of the node type definition?   It may require coordination with the JackRabbit team, but it would seem to me that this would be something you'd want to handle at the type definition level and persist across repositories instead of being saved within the IDE.

-Dan

-----Original Message-----
From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org] 
Sent: Monday, June 03, 2013 8:42 AM
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward with IDE tooling

On Mon, Jun 3, 2013 at 2:34 PM, Robert Munteanu <ro...@apache.org> wrote:
> ...I'm not sure how we would achieve a fine control over 
> serialisation. Is think something you would see as user-controllable?...

Maybe just a someNamespace:deepSerialize resource property would be sufficient?

If it's set on a subtree, that subtree gets serialized as a single file, otherwise each resource is serialized in a single file.

-Bertrand


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6378 - Release Date: 06/02/13

Re: [tooling] Moving forward with IDE tooling

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Jun 3, 2013 at 2:34 PM, Robert Munteanu <ro...@apache.org> wrote:
> ...I'm not sure how we would achieve a fine control over
> serialisation. Is think something you would see as user-controllable?...

Maybe just a someNamespace:deepSerialize resource property would be sufficient?

If it's set on a subtree, that subtree gets serialized as a single
file, otherwise each resource is serialized in a single file.

-Bertrand

Re: [tooling] Moving forward with IDE tooling

[Dominik Süß <do...@gmail.com>]

I think usercontroll is here the essential point. Serialization FS -> Sling
does not have this problem since it completely unfolds the structure.
Looking at CQ as sample does come up with some usecases where you want to
handle complete structures in one file for a proper overview like the
dialog definitions. Like stated earlier vault seems to have this
capabilities but it is just implictly bound to specific nodetypes which
might be confusing for devs. An IDE tool covering this whould need to mark
constellations that do not cover the current behavior (so FS currently has
another structure then a fresh checkout would create) and have all the
tooling required to transform the structure and/or the
serializationdefinition.

Dominik


On Mon, Jun 3, 2013 at 2:34 PM, Robert Munteanu <ro...@apache.org> wrote:

> On Mon, 2013-06-03 at 14:25 +0200, Dominik Süß wrote:
> > Hi Robert,
> >
> > regarding your sample - this kind of annotation does work for sure, what
> I
> > was talking about is the finegrained control over serialisation and
> > breakpoints (when to build a complete serialized file and where to split
> up
> > in subfolder and subsequent metafiles) - I'm sure someone can come up
> with
> > an intelligent more or less selfexplaing solution, but I'm not aware of
> > something existing that could be taken as bluepint.
>
> I see. That's something that Carsten also pointed out and I've noted at
> [1] . I'm not sure how we would achieve a fine control over
> serialisation. Is think something you would see as user-controllable?
>
> Also, what sort of breakpoints do you have in mind? ( I only know of
> debugger breakpoints :-) ).
>
> Robert
>
>
> [1]:
>
> https://cwiki.apache.org/SLING/sling-ide-tooling.html#SlingIDEtooling-Resourceserializationformat
>
> >
> > Cheers
> > Dominik
> >
> >
> > On Mon, Jun 3, 2013 at 2:18 PM, Robert Munteanu <ro...@apache.org>
> wrote:
> >
> > >
> > > > I have found Sling -> FS auto syncing useful for several reasons.
> > > > 1. The IDE lets me know if files in the repo are being changed, with
> the
> > > > message, '....do you want to reload this file.'
> > > > 2. When I do a svn status, or git status I know I am looking at an
> exact
> > > > copy of what I just tested.
> > > > 3. Because of 1 and 2 I can be certain that what I am editing is
> what I
> > > am
> > > > testing and the repo:
> > > > a) Hasn't mysteriously branched.
> > > > b) Hasn't overwritten the change I just made with one of its own.
> (try
> > > one
> > > > way sync to experience this, its very frustrating until you work out
> > > whats
> > > > happening)
> > > > 4. I can load things into the repo and have them appear in the IDE.
> > > >
> > > > But I dont want to steer this thread if the intention was for tooling
> > > that
> > > > would only work if everything is done in the IDE.
> > >
> > > I agree that we must allow developers to sync repository -> IDE
> > > workspace. I believe that this must be under the developer's control
> all
> > > the time nevertheless.
> > >
> > > A visual paradigm that Eclipse uses is the Synchronize view [1] , which
> > > is something we can build upon. For IntelliJ we should use what makes
> > > most sense in its visual paradigm.
> > >
> > > IMO this action should be manually triggered.
> > >
> > > Robert
> > >
> > > [1]: http://imgur.com/Zht175G
> > >
> > >
>
>
>
>

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

On Mon, 2013-06-03 at 14:25 +0200, Dominik Süß wrote:
> Hi Robert,
> 
> regarding your sample - this kind of annotation does work for sure, what I
> was talking about is the finegrained control over serialisation and
> breakpoints (when to build a complete serialized file and where to split up
> in subfolder and subsequent metafiles) - I'm sure someone can come up with
> an intelligent more or less selfexplaing solution, but I'm not aware of
> something existing that could be taken as bluepint.

I see. That's something that Carsten also pointed out and I've noted at
[1] . I'm not sure how we would achieve a fine control over
serialisation. Is think something you would see as user-controllable?

Also, what sort of breakpoints do you have in mind? ( I only know of
debugger breakpoints :-) ).

Robert


[1]:
https://cwiki.apache.org/SLING/sling-ide-tooling.html#SlingIDEtooling-Resourceserializationformat

> 
> Cheers
> Dominik
> 
> 
> On Mon, Jun 3, 2013 at 2:18 PM, Robert Munteanu <ro...@apache.org> wrote:
> 
> >
> > > I have found Sling -> FS auto syncing useful for several reasons.
> > > 1. The IDE lets me know if files in the repo are being changed, with the
> > > message, '....do you want to reload this file.'
> > > 2. When I do a svn status, or git status I know I am looking at an exact
> > > copy of what I just tested.
> > > 3. Because of 1 and 2 I can be certain that what I am editing is what I
> > am
> > > testing and the repo:
> > > a) Hasn't mysteriously branched.
> > > b) Hasn't overwritten the change I just made with one of its own. (try
> > one
> > > way sync to experience this, its very frustrating until you work out
> > whats
> > > happening)
> > > 4. I can load things into the repo and have them appear in the IDE.
> > >
> > > But I dont want to steer this thread if the intention was for tooling
> > that
> > > would only work if everything is done in the IDE.
> >
> > I agree that we must allow developers to sync repository -> IDE
> > workspace. I believe that this must be under the developer's control all
> > the time nevertheless.
> >
> > A visual paradigm that Eclipse uses is the Synchronize view [1] , which
> > is something we can build upon. For IntelliJ we should use what makes
> > most sense in its visual paradigm.
> >
> > IMO this action should be manually triggered.
> >
> > Robert
> >
> > [1]: http://imgur.com/Zht175G
> >
> >

Re: [tooling] Moving forward with IDE tooling

[Dominik Süß <do...@gmail.com>]

Hi Robert,

regarding your sample - this kind of annotation does work for sure, what I
was talking about is the finegrained control over serialisation and
breakpoints (when to build a complete serialized file and where to split up
in subfolder and subsequent metafiles) - I'm sure someone can come up with
an intelligent more or less selfexplaing solution, but I'm not aware of
something existing that could be taken as bluepint.

Cheers
Dominik


On Mon, Jun 3, 2013 at 2:18 PM, Robert Munteanu <ro...@apache.org> wrote:

>
> > I have found Sling -> FS auto syncing useful for several reasons.
> > 1. The IDE lets me know if files in the repo are being changed, with the
> > message, '....do you want to reload this file.'
> > 2. When I do a svn status, or git status I know I am looking at an exact
> > copy of what I just tested.
> > 3. Because of 1 and 2 I can be certain that what I am editing is what I
> am
> > testing and the repo:
> > a) Hasn't mysteriously branched.
> > b) Hasn't overwritten the change I just made with one of its own. (try
> one
> > way sync to experience this, its very frustrating until you work out
> whats
> > happening)
> > 4. I can load things into the repo and have them appear in the IDE.
> >
> > But I dont want to steer this thread if the intention was for tooling
> that
> > would only work if everything is done in the IDE.
>
> I agree that we must allow developers to sync repository -> IDE
> workspace. I believe that this must be under the developer's control all
> the time nevertheless.
>
> A visual paradigm that Eclipse uses is the Synchronize view [1] , which
> is something we can build upon. For IntelliJ we should use what makes
> most sense in its visual paradigm.
>
> IMO this action should be manually triggered.
>
> Robert
>
> [1]: http://imgur.com/Zht175G
>
>

RE: [tooling] Moving forward with IDE tooling

[Dan Klco <da...@sixdimensions.com>]

I am definitely a fan of the synchronization idea using something like the Source Control Synchronization dialog in Eclipse.   This would be a must have feature in my mind.   It would be useful in the case where a developer may have deployed say another package and isn't 100% sure they're not about to overwrite something someone else did or needs to confirm they changed what they thought they'd changed, etc.

As for auto-sync, I am not 100% sure it's that great of an idea.  There is definitely a potential for disruptive changes, I am not 100% sure there's a great way to configure it and at least in Eclipse it may end up with either the potential for concurrent changes and unpredictable results or locking the IDE until the changes have been completely loaded into Sling.  This is what happens in CRXDE, it's almost useable when using localhost, but any sort of network traffic and the IDE is frustrating beyond belief.  

I just feel like a common use case is to make a few changes in 2+ files, save both, then load the changes into the repository and test.  I don't think developers are always or necessarily most of the time making changes in just a single file at a time.

-Dan

-----Original Message-----
From: Robert Munteanu [mailto:rombert@apache.org] 
Sent: Monday, June 03, 2013 8:18 AM
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward with IDE tooling


> I have found Sling -> FS auto syncing useful for several reasons.
> 1. The IDE lets me know if files in the repo are being changed, with 
> the message, '....do you want to reload this file.'
> 2. When I do a svn status, or git status I know I am looking at an 
> exact copy of what I just tested.
> 3. Because of 1 and 2 I can be certain that what I am editing is what 
> I am testing and the repo:
> a) Hasn't mysteriously branched.
> b) Hasn't overwritten the change I just made with one of its own. (try 
> one way sync to experience this, its very frustrating until you work 
> out whats
> happening)
> 4. I can load things into the repo and have them appear in the IDE.
> 
> But I dont want to steer this thread if the intention was for tooling 
> that would only work if everything is done in the IDE.

I agree that we must allow developers to sync repository -> IDE workspace. I believe that this must be under the developer's control all the time nevertheless.

A visual paradigm that Eclipse uses is the Synchronize view [1] , which is something we can build upon. For IntelliJ we should use what makes most sense in its visual paradigm.

IMO this action should be manually triggered.

Robert

[1]: http://imgur.com/Zht175G



-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6378 - Release Date: 06/02/13

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

> I have found Sling -> FS auto syncing useful for several reasons.
> 1. The IDE lets me know if files in the repo are being changed, with the
> message, '....do you want to reload this file.'
> 2. When I do a svn status, or git status I know I am looking at an exact
> copy of what I just tested.
> 3. Because of 1 and 2 I can be certain that what I am editing is what I am
> testing and the repo:
> a) Hasn't mysteriously branched.
> b) Hasn't overwritten the change I just made with one of its own. (try one
> way sync to experience this, its very frustrating until you work out whats
> happening)
> 4. I can load things into the repo and have them appear in the IDE.
> 
> But I dont want to steer this thread if the intention was for tooling that
> would only work if everything is done in the IDE.

I agree that we must allow developers to sync repository -> IDE
workspace. I believe that this must be under the developer's control all
the time nevertheless.

A visual paradigm that Eclipse uses is the Synchronize view [1] , which
is something we can build upon. For IntelliJ we should use what makes
most sense in its visual paradigm.

IMO this action should be manually triggered.

Robert

[1]: http://imgur.com/Zht175G

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler <cz...@apache.org>]

Hi Ian,

2013/6/2 Ian Boston <ie...@tfd.co.uk>

>
>
> If by "true dev" you mean IDE only, then I will find that too restrictive,
> others may too. I use whatever is most efficient to get the job done,
> sometimes thats the IDE (refactoring), sometimes its the command line
> (branch management, full scale rebuilds). To say to use Sling tooling you
> can only use the IDE will be too restrictive.
>
> right, I totally agree. And usually I use the most efficient tool
available for the job as well - however, I believe that most jobs where
today I have to leave the IDE can be done as efficient (and even more
efficient) through the IDE with the right tooling.


> However the question you raise is not should developers be allowed to use
> command line, its should changes in a Sling repo be automatically reflected
> on the filesystem ? (I agree auto syncing between Sling and the internal
> IDE state without reference to the file system is not useful).
>
> Yepp.


> I have found Sling -> FS auto syncing useful for several reasons.
> 1. The IDE lets me know if files in the repo are being changed, with the
> message, '....do you want to reload this file.'
> 2. When I do a svn status, or git status I know I am looking at an exact
> copy of what I just tested.
> 3. Because of 1 and 2 I can be certain that what I am editing is what I am
> testing and the repo:
> a) Hasn't mysteriously branched.
> b) Hasn't overwritten the change I just made with one of its own. (try one
> way sync to experience this, its very frustrating until you work out whats
> happening)
> 4. I can load things into the repo and have them appear in the IDE.
>
> But I dont want to steer this thread if the intention was for tooling that
> would only work if everything is done in the IDE.
>
> I think you're bringing up very good points - and I totally agree to
address them in one way or the other. But :) we should really think before
we implement the "we need everything in all possible combinations" solution
(I'm exaggerating here of course to make a point).
For example in the above scenario, it's pretty easy to accidentally change
content in the repo which then overwrites your project checkout without
noticing it, especially if you haven't opened your IDE in that time. Which
in turn would require to check all changes in your project checkout before
committing it back. Doable, but I've seen many problems in this area where
people blindly commit their project changes without thinking about why they
are in their project. Sure, we can't prevent every potential human error -
but I would like to define a workflow which covers mostly everything from
working within the IDE. This would also be inline with efforts in the OSGi
world where you would be able to do everything within your IDE.
And of course, things like Maven would still be used for automated building
etc.

Carsten



-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Ian Boston <ie...@tfd.co.uk>]

Hi Carsten,


On 2 June 2013 18:41, Carsten Ziegeler <cz...@apache.org> wrote:

> I think a sync in both directions is problematic and I wouldn't go there -
> but I know that there only a few having this opinion.

In my opinion, when I'm talking about a developer that's someone who
> develops code including scripts and usually Java - this might also include
> coding in client side stuff like js and css. There is the central tool you
> use for developing and that's the IDE with a strong integration into the
> SCM (svn, git etc). The dev never has to leave this IDE for anything.

In
> this scenario, there is only a sync from IDE to Sling required - but not
> the other way round.
>
Whenever that's needed (syncing data from Sling into the file system) this
> should imho be an explicit decision by the dev - simply by invoking an
> action from the IDE. An automatic sync in both directions is dangerous and
> imho in most cases not wanted/desired/required.


> As soon as we're talking about automatic sync from Sling to the project
> checkout, this has a different style of development in mind - which I think
> we should not support when talking about IDE support.

Either we support IDE development and then we do it right and have a style
> of working that does
> not require to leave the IDE - or we do something different, but then let's
> make it clear that we don't plan to provide a true dev experience.


If by "true dev" you mean IDE only, then I will find that too restrictive,
others may too. I use whatever is most efficient to get the job done,
sometimes thats the IDE (refactoring), sometimes its the command line
(branch management, full scale rebuilds). To say to use Sling tooling you
can only use the IDE will be too restrictive.

However the question you raise is not should developers be allowed to use
command line, its should changes in a Sling repo be automatically reflected
on the filesystem ? (I agree auto syncing between Sling and the internal
IDE state without reference to the file system is not useful).

I have found Sling -> FS auto syncing useful for several reasons.
1. The IDE lets me know if files in the repo are being changed, with the
message, '....do you want to reload this file.'
2. When I do a svn status, or git status I know I am looking at an exact
copy of what I just tested.
3. Because of 1 and 2 I can be certain that what I am editing is what I am
testing and the repo:
a) Hasn't mysteriously branched.
b) Hasn't overwritten the change I just made with one of its own. (try one
way sync to experience this, its very frustrating until you work out whats
happening)
4. I can load things into the repo and have them appear in the IDE.

But I dont want to steer this thread if the intention was for tooling that
would only work if everything is done in the IDE.

Best Regards
Ian



>
>
> Carsten
>
>
> 2013/6/1 Ian Boston <ie...@tfd.co.uk>
>
> > Hi,
> > I've added the requirements for autosync to [1]. Although VLT does a good
> > job of this once setup I don't use CLI for editing and manipulating. I
> use
> > the IDE 100% with all its other tooling and just File Save.
> > Setup with VLT is 2 commands and a 1 line config file edit, which could
> > easily be converted into a IDE plugin.
> >
> > Having thought about it, I think the reason vlt sync works well is that
> > Sling is on the same box, monitoring the file system for changes, (I
> think
> > thats right, there is no local process with vlt sync) and monitoring JCR
> > for changes, which avoids lots of processing and http traffic. When I
> have
> > used other forms of integration on large repositories, the volume http
> > traffic and speed of response has nearly always made them unusable.
> >
> > What ever is used or reimplemented it must not rely on scanning a
> > repository to know what has changed. It must relay on notification of
> some
> > form so that Edit->Save->Refresh is never more than a few seconds, and
> > doesn't impact the Sling server resource usage. Ideally notification
> should
> > not rely on the IDE, since changes can be made without the IDE running,
> and
> > routing it via the IDE is going to get really confusing with 3 or more
> > potential sources of updates. (assuming code under version control)
> >
> > HTH
> > Ian
> >
> > 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases
> >
> >
> > On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:
> >
> > > @Justin, will do.
> > >
> > > @Ruben, it doesnt :(, but IMHO it should. (knowing very little about
> its
> > > internals).
> > >
> > >
> > > On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
> > >
> > >> is the vlt sync now actually updating .content.xml files? I thought it
> > >> can only sync regular files.
> > >>
> > >> Ruben
> > >>
> > >>
> > >> On 5/30/2013 7:24 PM, Justin Edelson wrote:
> > >>
> > >>> Ian - please do add the autosync use case to the wiki page I created.
> > >>>
> > >>>
> > >>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > >>>
> > >>>  Hi,
> > >>>> +1 to that. After working on sling for many years doing a mixture of
> > >>>> bundle
> > >>>> and UI work, mainly using the FileSystemResolver bundle, I realise
> now
> > >>>> if
> > >>>> VLT had been available with sync mode (ie auto syncing the repo and
> > the
> > >>>> file system), we (the team I was working with at the time) would
> have
> > >>>> made
> > >>>> much more rapid progress. UI dev work needs file-save-refresh. The
> in
> > >>>> browser editing UIs deliver this, as does VLT in sync mode, but
> > >>>> unfortunately native eclipse based tooling is just too slow (on my
> > >>>> machine,
> > >>>> might be my machine). Using VLT since I joined Adobe, has been a
> joy,
> > >>>> and I
> > >>>> am very glad to know its being donated to the ASF.
> > >>>>
> > >>>> Had we had VLT then, we would have developed in a very different
> way,
> > >>>> and
> > >>>> might not have had half the problems we had with tooling and team
> > >>>> structure.
> > >>>> Ian
> > >>>>
> > >>>>
> > >>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
> > wrote:
> > >>>>
> > >>>>  Hi,
> > >>>>> I would strongly suggest that this effort be based on VLT. As
> > mentioned
> > >>>>>
> > >>>> on
> > >>>>
> > >>>>> the wiki page, we're in the process of moving that to ASF and I
> think
> > >>>>>
> > >>>> once
> > >>>>
> > >>>>> the code is available, it will be clear that it provides a good
> > >>>>> low-level
> > >>>>> interface for this type of UI.
> > >>>>>
> > >>>>> While it is true that VLT currently only works with DavEX servers,
> I
> > >>>>> suspect it would not be hard to isolate the "Ex" bits and have a
> > >>>>> "WebDAV"
> > >>>>> only driver which could be used on non-JCR applications for basic
> > file
> > >>>>> operations.
> > >>>>>
> > >>>>> My concern is that we end up building one more abstraction which is
> > >>>>> going
> > >>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
> > >>>>>
> > >>>> etc.).
> > >>>>
> > >>>>> I know VLT has some baggage, but I'd just ask that people keep an
> > open
> > >>>>> mind.
> > >>>>>
> > >>>>> Separately, I'm going to start a child page of this wiki page to
> > gather
> > >>>>>
> > >>>> use
> > >>>>
> > >>>>> cases. There are some functional areas listed on the main page,
> but I
> > >>>>>
> > >>>> think
> > >>>>
> > >>>>> we should try to capture individual use cases.
> > >>>>>
> > >>>>> Regards,
> > >>>>> Justin
> > >>>>>
> > >>>>>
> > >>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
> > rombert@apache.org
> > >>>>>
> > >>>>>> wrote:
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> Following Antonio's kick-start of the Sling developer tooling [1]
> > I've
> > >>>>>> gathered some thoughts about the initial goals and implementation
> of
> > >>>>>>
> > >>>>> our
> > >>>>
> > >>>>> Sling IDE tooling.
> > >>>>>>
> > >>>>>> The document is at [2] so please have a look and let me know what
> > your
> > >>>>>> thoughts are. I intend to take a pass at the code next week and
> > align
> > >>>>>>
> > >>>>> it
> > >>>>
> > >>>>> to the proposed structure, as a foundation for feature work.
> > >>>>>>
> > >>>>>> Robert
> > >>>>>>
> > >>>>>> [1]: https://cwiki.apache.org/**SLING/slingclipse.html<
> > https://cwiki.apache.org/SLING/slingclipse.html>
> > >>>>>> [2]:
> > >>>>>>
> > >>>>> https://cwiki.apache.org/**confluence/display/SLING/**
> > >>>> Sling+IDE+tooling<
> > https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
> > >>>>
> > >>>>>
> > >>>>>>
> > >>
> > >
> >
>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
>

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler <cz...@apache.org>]

I think a sync in both directions is problematic and I wouldn't go there -
but I know that there only a few having this opinion.
In my opinion, when I'm talking about a developer that's someone who
develops code including scripts and usually Java - this might also include
coding in client side stuff like js and css. There is the central tool you
use for developing and that's the IDE with a strong integration into the
SCM (svn, git etc). The dev never has to leave this IDE for anything. In
this scenario, there is only a sync from IDE to Sling required - but not
the other way round.
Whenever that's needed (syncing data from Sling into the file system) this
should imho be an explicit decision by the dev - simply by invoking an
action from the IDE. An automatic sync in both directions is dangerous and
imho in most cases not wanted/desired/required.

As soon as we're talking about automatic sync from Sling to the project
checkout, this has a different style of development in mind - which I think
we should not support when talking about IDE support. Either we support IDE
development and then we do it right and have a style of working that does
not require to leave the IDE - or we do something different, but then let's
make it clear that we don't plan to provide a true dev experience.


Carsten


2013/6/1 Ian Boston <ie...@tfd.co.uk>

> Hi,
> I've added the requirements for autosync to [1]. Although VLT does a good
> job of this once setup I don't use CLI for editing and manipulating. I use
> the IDE 100% with all its other tooling and just File Save.
> Setup with VLT is 2 commands and a 1 line config file edit, which could
> easily be converted into a IDE plugin.
>
> Having thought about it, I think the reason vlt sync works well is that
> Sling is on the same box, monitoring the file system for changes, (I think
> thats right, there is no local process with vlt sync) and monitoring JCR
> for changes, which avoids lots of processing and http traffic. When I have
> used other forms of integration on large repositories, the volume http
> traffic and speed of response has nearly always made them unusable.
>
> What ever is used or reimplemented it must not rely on scanning a
> repository to know what has changed. It must relay on notification of some
> form so that Edit->Save->Refresh is never more than a few seconds, and
> doesn't impact the Sling server resource usage. Ideally notification should
> not rely on the IDE, since changes can be made without the IDE running, and
> routing it via the IDE is going to get really confusing with 3 or more
> potential sources of updates. (assuming code under version control)
>
> HTH
> Ian
>
> 1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases
>
>
> On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:
>
> > @Justin, will do.
> >
> > @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
> > internals).
> >
> >
> > On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
> >
> >> is the vlt sync now actually updating .content.xml files? I thought it
> >> can only sync regular files.
> >>
> >> Ruben
> >>
> >>
> >> On 5/30/2013 7:24 PM, Justin Edelson wrote:
> >>
> >>> Ian - please do add the autosync use case to the wiki page I created.
> >>>
> >>>
> >>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> >>>
> >>>  Hi,
> >>>> +1 to that. After working on sling for many years doing a mixture of
> >>>> bundle
> >>>> and UI work, mainly using the FileSystemResolver bundle, I realise now
> >>>> if
> >>>> VLT had been available with sync mode (ie auto syncing the repo and
> the
> >>>> file system), we (the team I was working with at the time) would have
> >>>> made
> >>>> much more rapid progress. UI dev work needs file-save-refresh. The in
> >>>> browser editing UIs deliver this, as does VLT in sync mode, but
> >>>> unfortunately native eclipse based tooling is just too slow (on my
> >>>> machine,
> >>>> might be my machine). Using VLT since I joined Adobe, has been a joy,
> >>>> and I
> >>>> am very glad to know its being donated to the ASF.
> >>>>
> >>>> Had we had VLT then, we would have developed in a very different way,
> >>>> and
> >>>> might not have had half the problems we had with tooling and team
> >>>> structure.
> >>>> Ian
> >>>>
> >>>>
> >>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
> wrote:
> >>>>
> >>>>  Hi,
> >>>>> I would strongly suggest that this effort be based on VLT. As
> mentioned
> >>>>>
> >>>> on
> >>>>
> >>>>> the wiki page, we're in the process of moving that to ASF and I think
> >>>>>
> >>>> once
> >>>>
> >>>>> the code is available, it will be clear that it provides a good
> >>>>> low-level
> >>>>> interface for this type of UI.
> >>>>>
> >>>>> While it is true that VLT currently only works with DavEX servers, I
> >>>>> suspect it would not be hard to isolate the "Ex" bits and have a
> >>>>> "WebDAV"
> >>>>> only driver which could be used on non-JCR applications for basic
> file
> >>>>> operations.
> >>>>>
> >>>>> My concern is that we end up building one more abstraction which is
> >>>>> going
> >>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
> >>>>>
> >>>> etc.).
> >>>>
> >>>>> I know VLT has some baggage, but I'd just ask that people keep an
> open
> >>>>> mind.
> >>>>>
> >>>>> Separately, I'm going to start a child page of this wiki page to
> gather
> >>>>>
> >>>> use
> >>>>
> >>>>> cases. There are some functional areas listed on the main page, but I
> >>>>>
> >>>> think
> >>>>
> >>>>> we should try to capture individual use cases.
> >>>>>
> >>>>> Regards,
> >>>>> Justin
> >>>>>
> >>>>>
> >>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <
> rombert@apache.org
> >>>>>
> >>>>>> wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Following Antonio's kick-start of the Sling developer tooling [1]
> I've
> >>>>>> gathered some thoughts about the initial goals and implementation of
> >>>>>>
> >>>>> our
> >>>>
> >>>>> Sling IDE tooling.
> >>>>>>
> >>>>>> The document is at [2] so please have a look and let me know what
> your
> >>>>>> thoughts are. I intend to take a pass at the code next week and
> align
> >>>>>>
> >>>>> it
> >>>>
> >>>>> to the proposed structure, as a foundation for feature work.
> >>>>>>
> >>>>>> Robert
> >>>>>>
> >>>>>> [1]: https://cwiki.apache.org/**SLING/slingclipse.html<
> https://cwiki.apache.org/SLING/slingclipse.html>
> >>>>>> [2]:
> >>>>>>
> >>>>> https://cwiki.apache.org/**confluence/display/SLING/**
> >>>> Sling+IDE+tooling<
> https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
> >>>>
> >>>>>
> >>>>>>
> >>
> >
>



-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Ian Boston <ie...@tfd.co.uk>]

Hi,
I've added the requirements for autosync to [1]. Although VLT does a good
job of this once setup I don't use CLI for editing and manipulating. I use
the IDE 100% with all its other tooling and just File Save.
Setup with VLT is 2 commands and a 1 line config file edit, which could
easily be converted into a IDE plugin.

Having thought about it, I think the reason vlt sync works well is that
Sling is on the same box, monitoring the file system for changes, (I think
thats right, there is no local process with vlt sync) and monitoring JCR
for changes, which avoids lots of processing and http traffic. When I have
used other forms of integration on large repositories, the volume http
traffic and speed of response has nearly always made them unusable.

What ever is used or reimplemented it must not rely on scanning a
repository to know what has changed. It must relay on notification of some
form so that Edit->Save->Refresh is never more than a few seconds, and
doesn't impact the Sling server resource usage. Ideally notification should
not rely on the IDE, since changes can be made without the IDE running, and
routing it via the IDE is going to get really confusing with 3 or more
potential sources of updates. (assuming code under version control)

HTH
Ian

1. https://cwiki.apache.org/confluence/display/SLING/Use+Cases


On 31 May 2013 14:07, Ian Boston <ie...@tfd.co.uk> wrote:

> @Justin, will do.
>
> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
> internals).
>
>
> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
>
>> is the vlt sync now actually updating .content.xml files? I thought it
>> can only sync regular files.
>>
>> Ruben
>>
>>
>> On 5/30/2013 7:24 PM, Justin Edelson wrote:
>>
>>> Ian - please do add the autosync use case to the wiki page I created.
>>>
>>>
>>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>>
>>>  Hi,
>>>> +1 to that. After working on sling for many years doing a mixture of
>>>> bundle
>>>> and UI work, mainly using the FileSystemResolver bundle, I realise now
>>>> if
>>>> VLT had been available with sync mode (ie auto syncing the repo and the
>>>> file system), we (the team I was working with at the time) would have
>>>> made
>>>> much more rapid progress. UI dev work needs file-save-refresh. The in
>>>> browser editing UIs deliver this, as does VLT in sync mode, but
>>>> unfortunately native eclipse based tooling is just too slow (on my
>>>> machine,
>>>> might be my machine). Using VLT since I joined Adobe, has been a joy,
>>>> and I
>>>> am very glad to know its being donated to the ASF.
>>>>
>>>> Had we had VLT then, we would have developed in a very different way,
>>>> and
>>>> might not have had half the problems we had with tooling and team
>>>> structure.
>>>> Ian
>>>>
>>>>
>>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com> wrote:
>>>>
>>>>  Hi,
>>>>> I would strongly suggest that this effort be based on VLT. As mentioned
>>>>>
>>>> on
>>>>
>>>>> the wiki page, we're in the process of moving that to ASF and I think
>>>>>
>>>> once
>>>>
>>>>> the code is available, it will be clear that it provides a good
>>>>> low-level
>>>>> interface for this type of UI.
>>>>>
>>>>> While it is true that VLT currently only works with DavEX servers, I
>>>>> suspect it would not be hard to isolate the "Ex" bits and have a
>>>>> "WebDAV"
>>>>> only driver which could be used on non-JCR applications for basic file
>>>>> operations.
>>>>>
>>>>> My concern is that we end up building one more abstraction which is
>>>>> going
>>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
>>>>>
>>>> etc.).
>>>>
>>>>> I know VLT has some baggage, but I'd just ask that people keep an open
>>>>> mind.
>>>>>
>>>>> Separately, I'm going to start a child page of this wiki page to gather
>>>>>
>>>> use
>>>>
>>>>> cases. There are some functional areas listed on the main page, but I
>>>>>
>>>> think
>>>>
>>>>> we should try to capture individual use cases.
>>>>>
>>>>> Regards,
>>>>> Justin
>>>>>
>>>>>
>>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <rombert@apache.org
>>>>>
>>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Following Antonio's kick-start of the Sling developer tooling [1] I've
>>>>>> gathered some thoughts about the initial goals and implementation of
>>>>>>
>>>>> our
>>>>
>>>>> Sling IDE tooling.
>>>>>>
>>>>>> The document is at [2] so please have a look and let me know what your
>>>>>> thoughts are. I intend to take a pass at the code next week and align
>>>>>>
>>>>> it
>>>>
>>>>> to the proposed structure, as a foundation for feature work.
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>> [1]: https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.apache.org/SLING/slingclipse.html>
>>>>>> [2]:
>>>>>>
>>>>> https://cwiki.apache.org/**confluence/display/SLING/**
>>>> Sling+IDE+tooling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
>>>>
>>>>>
>>>>>>
>>
>

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

On Fri, 2013-05-31 at 05:10 +0000, Dan Klco wrote:
> I am open to the idea of using VLT as a base, but we will have to do some pretty extensive work to clean up the error handling and messaging.  I haven't taken a look at the newest version, but 2.4.18 is still a black box when it doesn't work, which seems to happen unpredictably.  I am assuming we would be skipping the CLI stuff and invoking whatever APIs VLT uses internally to handle imports/exports, correct?

Yes, I plan to use the VLT APIs, not the CLI.

> 
> Another idea I've been thinking about would be some sort of .content.xml file editor.  Nothing too fancy, more of a helper than a full featured node editor.  I haven't come up with a UI yet, but is this something that might be worth looking into as well?

Yes, definitely. We should have a friendly content editor. Eclipse, for
instance, has a 'Design' tab for XML files which has a basic view [1]
which can be customised later.

Robert

[1]: http://docs.oracle.com/cd/E15919_01/wlp.1032/e14244/img/servlet.gif

> 
> -Dan
> 
> -----Original Message-----
> From: ianboston@gmail.com [mailto:ianboston@gmail.com] On Behalf Of Ian Boston
> Sent: Friday, May 31, 2013 12:07 AM
> To: dev@sling.apache.org
> Subject: Re: [tooling] Moving forward with IDE tooling
> 
> @Justin, will do.
> 
> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its internals).
> 
> 
> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
> 
> > is the vlt sync now actually updating .content.xml files? I thought it 
> > can only sync regular files.
> >
> > Ruben
> >
> >
> > On 5/30/2013 7:24 PM, Justin Edelson wrote:
> >
> >> Ian - please do add the autosync use case to the wiki page I created.
> >>
> >>
> >> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> >>
> >>  Hi,
> >>> +1 to that. After working on sling for many years doing a mixture of
> >>> bundle
> >>> and UI work, mainly using the FileSystemResolver bundle, I realise 
> >>> now if VLT had been available with sync mode (ie auto syncing the 
> >>> repo and the file system), we (the team I was working with at the 
> >>> time) would have made much more rapid progress. UI dev work needs 
> >>> file-save-refresh. The in browser editing UIs deliver this, as does 
> >>> VLT in sync mode, but unfortunately native eclipse based tooling is 
> >>> just too slow (on my machine, might be my machine). Using VLT since 
> >>> I joined Adobe, has been a joy, and I am very glad to know its being 
> >>> donated to the ASF.
> >>>
> >>> Had we had VLT then, we would have developed in a very different 
> >>> way, and might not have had half the problems we had with tooling 
> >>> and team structure.
> >>> Ian
> >>>
> >>>
> >>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com> wrote:
> >>>
> >>>  Hi,
> >>>> I would strongly suggest that this effort be based on VLT. As 
> >>>> mentioned
> >>>>
> >>> on
> >>>
> >>>> the wiki page, we're in the process of moving that to ASF and I 
> >>>> think
> >>>>
> >>> once
> >>>
> >>>> the code is available, it will be clear that it provides a good 
> >>>> low-level interface for this type of UI.
> >>>>
> >>>> While it is true that VLT currently only works with DavEX servers, 
> >>>> I suspect it would not be hard to isolate the "Ex" bits and have a 
> >>>> "WebDAV"
> >>>> only driver which could be used on non-JCR applications for basic 
> >>>> file operations.
> >>>>
> >>>> My concern is that we end up building one more abstraction which is 
> >>>> going to sit on top of all the other abstractions (VLT, Dav(Ex), 
> >>>> JCR, MK,
> >>>>
> >>> etc.).
> >>>
> >>>> I know VLT has some baggage, but I'd just ask that people keep an 
> >>>> open mind.
> >>>>
> >>>> Separately, I'm going to start a child page of this wiki page to 
> >>>> gather
> >>>>
> >>> use
> >>>
> >>>> cases. There are some functional areas listed on the main page, but 
> >>>> I
> >>>>
> >>> think
> >>>
> >>>> we should try to capture individual use cases.
> >>>>
> >>>> Regards,
> >>>> Justin
> >>>>
> >>>>
> >>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu 
> >>>> <rombert@apache.org
> >>>>
> >>>>> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Following Antonio's kick-start of the Sling developer tooling [1] 
> >>>>> I've gathered some thoughts about the initial goals and 
> >>>>> implementation of
> >>>>>
> >>>> our
> >>>
> >>>> Sling IDE tooling.
> >>>>>
> >>>>> The document is at [2] so please have a look and let me know what 
> >>>>> your thoughts are. I intend to take a pass at the code next week 
> >>>>> and align
> >>>>>
> >>>> it
> >>>
> >>>> to the proposed structure, as a foundation for feature work.
> >>>>>
> >>>>> Robert
> >>>>>
> >>>>> [1]: 
> >>>>> https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.ap
> >>>>> ache.org/SLING/slingclipse.html>
> >>>>> [2]:
> >>>>>
> >>>> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+too
> >>>> ling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+to
> >>>> oling>
> >>>
> >>>>
> >>>>>
> >
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3343 / Virus Database: 3184/6366 - Release Date: 05/29/13
> 

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler <cz...@apache.org>]

2013/5/31 Robert Munteanu <ro...@apache.org>

>
> > In addition the file name .content.xml is really bad as it is
> > hidden nearly in all OS, IDEs etc. Something like [content].xml is way
> > nicer - it's an illegal JCR name btw as well.
>
> +1 . Although we do need to think about compatibility with command-line
> VLT checkouts as well.
>

I don't see this as a hard requirement - however, I'm not against this -
but I would do this as a second step. So let us do the right think first
without thinking about this compatibility and once we have the perfect
solution we can add something on top which provides this.
If we start with compatibility to vlt in mind, this will definitely
restrain us

Carsten


>
> Robert
>
>
> >
> > Carsten
> >
> >
> > 2013/5/31 Dan Klco <da...@sixdimensions.com>
> >
> > > I am open to the idea of using VLT as a base, but we will have to do
> some
> > > pretty extensive work to clean up the error handling and messaging.  I
> > > haven't taken a look at the newest version, but 2.4.18 is still a
> black box
> > > when it doesn't work, which seems to happen unpredictably.  I am
> assuming
> > > we would be skipping the CLI stuff and invoking whatever APIs VLT uses
> > > internally to handle imports/exports, correct?
> > >
> > > Another idea I've been thinking about would be some sort of
> .content.xml
> > > file editor.  Nothing too fancy, more of a helper than a full featured
> node
> > > editor.  I haven't come up with a UI yet, but is this something that
> might
> > > be worth looking into as well?
> > >
> > > -Dan
> > >
> > > -----Original Message-----
> > > From: ianboston@gmail.com [mailto:ianboston@gmail.com] On Behalf Of
> Ian
> > > Boston
> > > Sent: Friday, May 31, 2013 12:07 AM
> > > To: dev@sling.apache.org
> > > Subject: Re: [tooling] Moving forward with IDE tooling
> > >
> > > @Justin, will do.
> > >
> > > @Ruben, it doesnt :(, but IMHO it should. (knowing very little about
> its
> > > internals).
> > >
> > >
> > > On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
> > >
> > > > is the vlt sync now actually updating .content.xml files? I thought
> it
> > > > can only sync regular files.
> > > >
> > > > Ruben
> > > >
> > > >
> > > > On 5/30/2013 7:24 PM, Justin Edelson wrote:
> > > >
> > > >> Ian - please do add the autosync use case to the wiki page I
> created.
> > > >>
> > > >>
> > > >> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > > >>
> > > >>  Hi,
> > > >>> +1 to that. After working on sling for many years doing a mixture
> of
> > > >>> bundle
> > > >>> and UI work, mainly using the FileSystemResolver bundle, I realise
> > > >>> now if VLT had been available with sync mode (ie auto syncing the
> > > >>> repo and the file system), we (the team I was working with at the
> > > >>> time) would have made much more rapid progress. UI dev work needs
> > > >>> file-save-refresh. The in browser editing UIs deliver this, as does
> > > >>> VLT in sync mode, but unfortunately native eclipse based tooling is
> > > >>> just too slow (on my machine, might be my machine). Using VLT since
> > > >>> I joined Adobe, has been a joy, and I am very glad to know its
> being
> > > >>> donated to the ASF.
> > > >>>
> > > >>> Had we had VLT then, we would have developed in a very different
> > > >>> way, and might not have had half the problems we had with tooling
> > > >>> and team structure.
> > > >>> Ian
> > > >>>
> > > >>>
> > > >>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com>
> wrote:
> > > >>>
> > > >>>  Hi,
> > > >>>> I would strongly suggest that this effort be based on VLT. As
> > > >>>> mentioned
> > > >>>>
> > > >>> on
> > > >>>
> > > >>>> the wiki page, we're in the process of moving that to ASF and I
> > > >>>> think
> > > >>>>
> > > >>> once
> > > >>>
> > > >>>> the code is available, it will be clear that it provides a good
> > > >>>> low-level interface for this type of UI.
> > > >>>>
> > > >>>> While it is true that VLT currently only works with DavEX servers,
> > > >>>> I suspect it would not be hard to isolate the "Ex" bits and have a
> > > >>>> "WebDAV"
> > > >>>> only driver which could be used on non-JCR applications for basic
> > > >>>> file operations.
> > > >>>>
> > > >>>> My concern is that we end up building one more abstraction which
> is
> > > >>>> going to sit on top of all the other abstractions (VLT, Dav(Ex),
> > > >>>> JCR, MK,
> > > >>>>
> > > >>> etc.).
> > > >>>
> > > >>>> I know VLT has some baggage, but I'd just ask that people keep an
> > > >>>> open mind.
> > > >>>>
> > > >>>> Separately, I'm going to start a child page of this wiki page to
> > > >>>> gather
> > > >>>>
> > > >>> use
> > > >>>
> > > >>>> cases. There are some functional areas listed on the main page,
> but
> > > >>>> I
> > > >>>>
> > > >>> think
> > > >>>
> > > >>>> we should try to capture individual use cases.
> > > >>>>
> > > >>>> Regards,
> > > >>>> Justin
> > > >>>>
> > > >>>>
> > > >>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu
> > > >>>> <rombert@apache.org
> > > >>>>
> > > >>>>> wrote:
> > > >>>>> Hi,
> > > >>>>>
> > > >>>>> Following Antonio's kick-start of the Sling developer tooling [1]
> > > >>>>> I've gathered some thoughts about the initial goals and
> > > >>>>> implementation of
> > > >>>>>
> > > >>>> our
> > > >>>
> > > >>>> Sling IDE tooling.
> > > >>>>>
> > > >>>>> The document is at [2] so please have a look and let me know what
> > > >>>>> your thoughts are. I intend to take a pass at the code next week
> > > >>>>> and align
> > > >>>>>
> > > >>>> it
> > > >>>
> > > >>>> to the proposed structure, as a foundation for feature work.
> > > >>>>>
> > > >>>>> Robert
> > > >>>>>
> > > >>>>> [1]:
> > > >>>>> https://cwiki.apache.org/**SLING/slingclipse.html<
> https://cwiki.ap
> > > >>>>> ache.org/SLING/slingclipse.html>
> > > >>>>> [2]:
> > > >>>>>
> > > >>>>
> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+too
> > > >>>> ling<
> https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+to
> > > >>>> oling>
> > > >>>
> > > >>>>
> > > >>>>>
> > > >
> > >
> > > -----
> > > No virus found in this message.
> > > Checked by AVG - www.avg.com
> > > Version: 2013.0.3343 / Virus Database: 3184/6366 - Release Date:
> 05/29/13
> > >
> > >
> >
> >
>
>
>
>


-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [tooling] Moving forward with IDE tooling

[Robert Munteanu <ro...@apache.org>]

On Fri, 2013-05-31 at 14:20 +0900, Carsten Ziegeler wrote:
> I've two major comments - first of all, I think the tooling should be based
> on Sling resource API to be able to handle all potential resource
> providers. 

+1

> In addition the file name .content.xml is really bad as it is
> hidden nearly in all OS, IDEs etc. Something like [content].xml is way
> nicer - it's an illegal JCR name btw as well.

+1 . Although we do need to think about compatibility with command-line
VLT checkouts as well.

Robert


> 
> Carsten
> 
> 
> 2013/5/31 Dan Klco <da...@sixdimensions.com>
> 
> > I am open to the idea of using VLT as a base, but we will have to do some
> > pretty extensive work to clean up the error handling and messaging.  I
> > haven't taken a look at the newest version, but 2.4.18 is still a black box
> > when it doesn't work, which seems to happen unpredictably.  I am assuming
> > we would be skipping the CLI stuff and invoking whatever APIs VLT uses
> > internally to handle imports/exports, correct?
> >
> > Another idea I've been thinking about would be some sort of .content.xml
> > file editor.  Nothing too fancy, more of a helper than a full featured node
> > editor.  I haven't come up with a UI yet, but is this something that might
> > be worth looking into as well?
> >
> > -Dan
> >
> > -----Original Message-----
> > From: ianboston@gmail.com [mailto:ianboston@gmail.com] On Behalf Of Ian
> > Boston
> > Sent: Friday, May 31, 2013 12:07 AM
> > To: dev@sling.apache.org
> > Subject: Re: [tooling] Moving forward with IDE tooling
> >
> > @Justin, will do.
> >
> > @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
> > internals).
> >
> >
> > On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
> >
> > > is the vlt sync now actually updating .content.xml files? I thought it
> > > can only sync regular files.
> > >
> > > Ruben
> > >
> > >
> > > On 5/30/2013 7:24 PM, Justin Edelson wrote:
> > >
> > >> Ian - please do add the autosync use case to the wiki page I created.
> > >>
> > >>
> > >> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> > >>
> > >>  Hi,
> > >>> +1 to that. After working on sling for many years doing a mixture of
> > >>> bundle
> > >>> and UI work, mainly using the FileSystemResolver bundle, I realise
> > >>> now if VLT had been available with sync mode (ie auto syncing the
> > >>> repo and the file system), we (the team I was working with at the
> > >>> time) would have made much more rapid progress. UI dev work needs
> > >>> file-save-refresh. The in browser editing UIs deliver this, as does
> > >>> VLT in sync mode, but unfortunately native eclipse based tooling is
> > >>> just too slow (on my machine, might be my machine). Using VLT since
> > >>> I joined Adobe, has been a joy, and I am very glad to know its being
> > >>> donated to the ASF.
> > >>>
> > >>> Had we had VLT then, we would have developed in a very different
> > >>> way, and might not have had half the problems we had with tooling
> > >>> and team structure.
> > >>> Ian
> > >>>
> > >>>
> > >>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com> wrote:
> > >>>
> > >>>  Hi,
> > >>>> I would strongly suggest that this effort be based on VLT. As
> > >>>> mentioned
> > >>>>
> > >>> on
> > >>>
> > >>>> the wiki page, we're in the process of moving that to ASF and I
> > >>>> think
> > >>>>
> > >>> once
> > >>>
> > >>>> the code is available, it will be clear that it provides a good
> > >>>> low-level interface for this type of UI.
> > >>>>
> > >>>> While it is true that VLT currently only works with DavEX servers,
> > >>>> I suspect it would not be hard to isolate the "Ex" bits and have a
> > >>>> "WebDAV"
> > >>>> only driver which could be used on non-JCR applications for basic
> > >>>> file operations.
> > >>>>
> > >>>> My concern is that we end up building one more abstraction which is
> > >>>> going to sit on top of all the other abstractions (VLT, Dav(Ex),
> > >>>> JCR, MK,
> > >>>>
> > >>> etc.).
> > >>>
> > >>>> I know VLT has some baggage, but I'd just ask that people keep an
> > >>>> open mind.
> > >>>>
> > >>>> Separately, I'm going to start a child page of this wiki page to
> > >>>> gather
> > >>>>
> > >>> use
> > >>>
> > >>>> cases. There are some functional areas listed on the main page, but
> > >>>> I
> > >>>>
> > >>> think
> > >>>
> > >>>> we should try to capture individual use cases.
> > >>>>
> > >>>> Regards,
> > >>>> Justin
> > >>>>
> > >>>>
> > >>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu
> > >>>> <rombert@apache.org
> > >>>>
> > >>>>> wrote:
> > >>>>> Hi,
> > >>>>>
> > >>>>> Following Antonio's kick-start of the Sling developer tooling [1]
> > >>>>> I've gathered some thoughts about the initial goals and
> > >>>>> implementation of
> > >>>>>
> > >>>> our
> > >>>
> > >>>> Sling IDE tooling.
> > >>>>>
> > >>>>> The document is at [2] so please have a look and let me know what
> > >>>>> your thoughts are. I intend to take a pass at the code next week
> > >>>>> and align
> > >>>>>
> > >>>> it
> > >>>
> > >>>> to the proposed structure, as a foundation for feature work.
> > >>>>>
> > >>>>> Robert
> > >>>>>
> > >>>>> [1]:
> > >>>>> https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.ap
> > >>>>> ache.org/SLING/slingclipse.html>
> > >>>>> [2]:
> > >>>>>
> > >>>> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+too
> > >>>> ling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+to
> > >>>> oling>
> > >>>
> > >>>>
> > >>>>>
> > >
> >
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2013.0.3343 / Virus Database: 3184/6366 - Release Date: 05/29/13
> >
> >
> 
> 

Re: [tooling] Moving forward with IDE tooling

[Carsten Ziegeler <cz...@apache.org>]

I've two major comments - first of all, I think the tooling should be based
on Sling resource API to be able to handle all potential resource
providers. In addition the file name .content.xml is really bad as it is
hidden nearly in all OS, IDEs etc. Something like [content].xml is way
nicer - it's an illegal JCR name btw as well.

Carsten


2013/5/31 Dan Klco <da...@sixdimensions.com>

> I am open to the idea of using VLT as a base, but we will have to do some
> pretty extensive work to clean up the error handling and messaging.  I
> haven't taken a look at the newest version, but 2.4.18 is still a black box
> when it doesn't work, which seems to happen unpredictably.  I am assuming
> we would be skipping the CLI stuff and invoking whatever APIs VLT uses
> internally to handle imports/exports, correct?
>
> Another idea I've been thinking about would be some sort of .content.xml
> file editor.  Nothing too fancy, more of a helper than a full featured node
> editor.  I haven't come up with a UI yet, but is this something that might
> be worth looking into as well?
>
> -Dan
>
> -----Original Message-----
> From: ianboston@gmail.com [mailto:ianboston@gmail.com] On Behalf Of Ian
> Boston
> Sent: Friday, May 31, 2013 12:07 AM
> To: dev@sling.apache.org
> Subject: Re: [tooling] Moving forward with IDE tooling
>
> @Justin, will do.
>
> @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
> internals).
>
>
> On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:
>
> > is the vlt sync now actually updating .content.xml files? I thought it
> > can only sync regular files.
> >
> > Ruben
> >
> >
> > On 5/30/2013 7:24 PM, Justin Edelson wrote:
> >
> >> Ian - please do add the autosync use case to the wiki page I created.
> >>
> >>
> >> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> >>
> >>  Hi,
> >>> +1 to that. After working on sling for many years doing a mixture of
> >>> bundle
> >>> and UI work, mainly using the FileSystemResolver bundle, I realise
> >>> now if VLT had been available with sync mode (ie auto syncing the
> >>> repo and the file system), we (the team I was working with at the
> >>> time) would have made much more rapid progress. UI dev work needs
> >>> file-save-refresh. The in browser editing UIs deliver this, as does
> >>> VLT in sync mode, but unfortunately native eclipse based tooling is
> >>> just too slow (on my machine, might be my machine). Using VLT since
> >>> I joined Adobe, has been a joy, and I am very glad to know its being
> >>> donated to the ASF.
> >>>
> >>> Had we had VLT then, we would have developed in a very different
> >>> way, and might not have had half the problems we had with tooling
> >>> and team structure.
> >>> Ian
> >>>
> >>>
> >>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com> wrote:
> >>>
> >>>  Hi,
> >>>> I would strongly suggest that this effort be based on VLT. As
> >>>> mentioned
> >>>>
> >>> on
> >>>
> >>>> the wiki page, we're in the process of moving that to ASF and I
> >>>> think
> >>>>
> >>> once
> >>>
> >>>> the code is available, it will be clear that it provides a good
> >>>> low-level interface for this type of UI.
> >>>>
> >>>> While it is true that VLT currently only works with DavEX servers,
> >>>> I suspect it would not be hard to isolate the "Ex" bits and have a
> >>>> "WebDAV"
> >>>> only driver which could be used on non-JCR applications for basic
> >>>> file operations.
> >>>>
> >>>> My concern is that we end up building one more abstraction which is
> >>>> going to sit on top of all the other abstractions (VLT, Dav(Ex),
> >>>> JCR, MK,
> >>>>
> >>> etc.).
> >>>
> >>>> I know VLT has some baggage, but I'd just ask that people keep an
> >>>> open mind.
> >>>>
> >>>> Separately, I'm going to start a child page of this wiki page to
> >>>> gather
> >>>>
> >>> use
> >>>
> >>>> cases. There are some functional areas listed on the main page, but
> >>>> I
> >>>>
> >>> think
> >>>
> >>>> we should try to capture individual use cases.
> >>>>
> >>>> Regards,
> >>>> Justin
> >>>>
> >>>>
> >>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu
> >>>> <rombert@apache.org
> >>>>
> >>>>> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Following Antonio's kick-start of the Sling developer tooling [1]
> >>>>> I've gathered some thoughts about the initial goals and
> >>>>> implementation of
> >>>>>
> >>>> our
> >>>
> >>>> Sling IDE tooling.
> >>>>>
> >>>>> The document is at [2] so please have a look and let me know what
> >>>>> your thoughts are. I intend to take a pass at the code next week
> >>>>> and align
> >>>>>
> >>>> it
> >>>
> >>>> to the proposed structure, as a foundation for feature work.
> >>>>>
> >>>>> Robert
> >>>>>
> >>>>> [1]:
> >>>>> https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.ap
> >>>>> ache.org/SLING/slingclipse.html>
> >>>>> [2]:
> >>>>>
> >>>> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+too
> >>>> ling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+to
> >>>> oling>
> >>>
> >>>>
> >>>>>
> >
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3343 / Virus Database: 3184/6366 - Release Date: 05/29/13
>
>


-- 
Carsten Ziegeler
cziegeler@apache.org

RE: [tooling] Moving forward with IDE tooling

[Dan Klco <da...@sixdimensions.com>]

I am open to the idea of using VLT as a base, but we will have to do some pretty extensive work to clean up the error handling and messaging.  I haven't taken a look at the newest version, but 2.4.18 is still a black box when it doesn't work, which seems to happen unpredictably.  I am assuming we would be skipping the CLI stuff and invoking whatever APIs VLT uses internally to handle imports/exports, correct?

Another idea I've been thinking about would be some sort of .content.xml file editor.  Nothing too fancy, more of a helper than a full featured node editor.  I haven't come up with a UI yet, but is this something that might be worth looking into as well?

-Dan

-----Original Message-----
From: ianboston@gmail.com [mailto:ianboston@gmail.com] On Behalf Of Ian Boston
Sent: Friday, May 31, 2013 12:07 AM
To: dev@sling.apache.org
Subject: Re: [tooling] Moving forward with IDE tooling

@Justin, will do.

@Ruben, it doesnt :(, but IMHO it should. (knowing very little about its internals).


On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:

> is the vlt sync now actually updating .content.xml files? I thought it 
> can only sync regular files.
>
> Ruben
>
>
> On 5/30/2013 7:24 PM, Justin Edelson wrote:
>
>> Ian - please do add the autosync use case to the wiki page I created.
>>
>>
>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>  Hi,
>>> +1 to that. After working on sling for many years doing a mixture of
>>> bundle
>>> and UI work, mainly using the FileSystemResolver bundle, I realise 
>>> now if VLT had been available with sync mode (ie auto syncing the 
>>> repo and the file system), we (the team I was working with at the 
>>> time) would have made much more rapid progress. UI dev work needs 
>>> file-save-refresh. The in browser editing UIs deliver this, as does 
>>> VLT in sync mode, but unfortunately native eclipse based tooling is 
>>> just too slow (on my machine, might be my machine). Using VLT since 
>>> I joined Adobe, has been a joy, and I am very glad to know its being 
>>> donated to the ASF.
>>>
>>> Had we had VLT then, we would have developed in a very different 
>>> way, and might not have had half the problems we had with tooling 
>>> and team structure.
>>> Ian
>>>
>>>
>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com> wrote:
>>>
>>>  Hi,
>>>> I would strongly suggest that this effort be based on VLT. As 
>>>> mentioned
>>>>
>>> on
>>>
>>>> the wiki page, we're in the process of moving that to ASF and I 
>>>> think
>>>>
>>> once
>>>
>>>> the code is available, it will be clear that it provides a good 
>>>> low-level interface for this type of UI.
>>>>
>>>> While it is true that VLT currently only works with DavEX servers, 
>>>> I suspect it would not be hard to isolate the "Ex" bits and have a 
>>>> "WebDAV"
>>>> only driver which could be used on non-JCR applications for basic 
>>>> file operations.
>>>>
>>>> My concern is that we end up building one more abstraction which is 
>>>> going to sit on top of all the other abstractions (VLT, Dav(Ex), 
>>>> JCR, MK,
>>>>
>>> etc.).
>>>
>>>> I know VLT has some baggage, but I'd just ask that people keep an 
>>>> open mind.
>>>>
>>>> Separately, I'm going to start a child page of this wiki page to 
>>>> gather
>>>>
>>> use
>>>
>>>> cases. There are some functional areas listed on the main page, but 
>>>> I
>>>>
>>> think
>>>
>>>> we should try to capture individual use cases.
>>>>
>>>> Regards,
>>>> Justin
>>>>
>>>>
>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu 
>>>> <rombert@apache.org
>>>>
>>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Following Antonio's kick-start of the Sling developer tooling [1] 
>>>>> I've gathered some thoughts about the initial goals and 
>>>>> implementation of
>>>>>
>>>> our
>>>
>>>> Sling IDE tooling.
>>>>>
>>>>> The document is at [2] so please have a look and let me know what 
>>>>> your thoughts are. I intend to take a pass at the code next week 
>>>>> and align
>>>>>
>>>> it
>>>
>>>> to the proposed structure, as a foundation for feature work.
>>>>>
>>>>> Robert
>>>>>
>>>>> [1]: 
>>>>> https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.ap
>>>>> ache.org/SLING/slingclipse.html>
>>>>> [2]:
>>>>>
>>>> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+too
>>>> ling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+to
>>>> oling>
>>>
>>>>
>>>>>
>

-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3343 / Virus Database: 3184/6366 - Release Date: 05/29/13

Re: [tooling] Moving forward with IDE tooling

[Ian Boston <ie...@tfd.co.uk>]

@Justin, will do.

@Ruben, it doesnt :(, but IMHO it should. (knowing very little about its
internals).


On 31 May 2013 13:48, Ruben Reusser <rr...@headwire.com> wrote:

> is the vlt sync now actually updating .content.xml files? I thought it can
> only sync regular files.
>
> Ruben
>
>
> On 5/30/2013 7:24 PM, Justin Edelson wrote:
>
>> Ian - please do add the autosync use case to the wiki page I created.
>>
>>
>> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>  Hi,
>>> +1 to that. After working on sling for many years doing a mixture of
>>> bundle
>>> and UI work, mainly using the FileSystemResolver bundle, I realise now if
>>> VLT had been available with sync mode (ie auto syncing the repo and the
>>> file system), we (the team I was working with at the time) would have
>>> made
>>> much more rapid progress. UI dev work needs file-save-refresh. The in
>>> browser editing UIs deliver this, as does VLT in sync mode, but
>>> unfortunately native eclipse based tooling is just too slow (on my
>>> machine,
>>> might be my machine). Using VLT since I joined Adobe, has been a joy,
>>> and I
>>> am very glad to know its being donated to the ASF.
>>>
>>> Had we had VLT then, we would have developed in a very different way, and
>>> might not have had half the problems we had with tooling and team
>>> structure.
>>> Ian
>>>
>>>
>>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com> wrote:
>>>
>>>  Hi,
>>>> I would strongly suggest that this effort be based on VLT. As mentioned
>>>>
>>> on
>>>
>>>> the wiki page, we're in the process of moving that to ASF and I think
>>>>
>>> once
>>>
>>>> the code is available, it will be clear that it provides a good
>>>> low-level
>>>> interface for this type of UI.
>>>>
>>>> While it is true that VLT currently only works with DavEX servers, I
>>>> suspect it would not be hard to isolate the "Ex" bits and have a
>>>> "WebDAV"
>>>> only driver which could be used on non-JCR applications for basic file
>>>> operations.
>>>>
>>>> My concern is that we end up building one more abstraction which is
>>>> going
>>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
>>>>
>>> etc.).
>>>
>>>> I know VLT has some baggage, but I'd just ask that people keep an open
>>>> mind.
>>>>
>>>> Separately, I'm going to start a child page of this wiki page to gather
>>>>
>>> use
>>>
>>>> cases. There are some functional areas listed on the main page, but I
>>>>
>>> think
>>>
>>>> we should try to capture individual use cases.
>>>>
>>>> Regards,
>>>> Justin
>>>>
>>>>
>>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <rombert@apache.org
>>>>
>>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Following Antonio's kick-start of the Sling developer tooling [1] I've
>>>>> gathered some thoughts about the initial goals and implementation of
>>>>>
>>>> our
>>>
>>>> Sling IDE tooling.
>>>>>
>>>>> The document is at [2] so please have a look and let me know what your
>>>>> thoughts are. I intend to take a pass at the code next week and align
>>>>>
>>>> it
>>>
>>>> to the proposed structure, as a foundation for feature work.
>>>>>
>>>>> Robert
>>>>>
>>>>> [1]: https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.apache.org/SLING/slingclipse.html>
>>>>> [2]:
>>>>>
>>>> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+tooling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling>
>>>
>>>>
>>>>>
>

Re: [tooling] Moving forward with IDE tooling

[Ruben Reusser <rr...@headwire.com>]

is the vlt sync now actually updating .content.xml files? I thought it 
can only sync regular files.

Ruben

On 5/30/2013 7:24 PM, Justin Edelson wrote:
> Ian - please do add the autosync use case to the wiki page I created.
>
>
> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> Hi,
>> +1 to that. After working on sling for many years doing a mixture of bundle
>> and UI work, mainly using the FileSystemResolver bundle, I realise now if
>> VLT had been available with sync mode (ie auto syncing the repo and the
>> file system), we (the team I was working with at the time) would have made
>> much more rapid progress. UI dev work needs file-save-refresh. The in
>> browser editing UIs deliver this, as does VLT in sync mode, but
>> unfortunately native eclipse based tooling is just too slow (on my machine,
>> might be my machine). Using VLT since I joined Adobe, has been a joy, and I
>> am very glad to know its being donated to the ASF.
>>
>> Had we had VLT then, we would have developed in a very different way, and
>> might not have had half the problems we had with tooling and team
>> structure.
>> Ian
>>
>>
>> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com> wrote:
>>
>>> Hi,
>>> I would strongly suggest that this effort be based on VLT. As mentioned
>> on
>>> the wiki page, we're in the process of moving that to ASF and I think
>> once
>>> the code is available, it will be clear that it provides a good low-level
>>> interface for this type of UI.
>>>
>>> While it is true that VLT currently only works with DavEX servers, I
>>> suspect it would not be hard to isolate the "Ex" bits and have a "WebDAV"
>>> only driver which could be used on non-JCR applications for basic file
>>> operations.
>>>
>>> My concern is that we end up building one more abstraction which is going
>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
>> etc.).
>>> I know VLT has some baggage, but I'd just ask that people keep an open
>>> mind.
>>>
>>> Separately, I'm going to start a child page of this wiki page to gather
>> use
>>> cases. There are some functional areas listed on the main page, but I
>> think
>>> we should try to capture individual use cases.
>>>
>>> Regards,
>>> Justin
>>>
>>>
>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <rombert@apache.org
>>>> wrote:
>>>> Hi,
>>>>
>>>> Following Antonio's kick-start of the Sling developer tooling [1] I've
>>>> gathered some thoughts about the initial goals and implementation of
>> our
>>>> Sling IDE tooling.
>>>>
>>>> The document is at [2] so please have a look and let me know what your
>>>> thoughts are. I intend to take a pass at the code next week and align
>> it
>>>> to the proposed structure, as a foundation for feature work.
>>>>
>>>> Robert
>>>>
>>>> [1]: https://cwiki.apache.org/SLING/slingclipse.html
>>>> [2]:
>> https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
>>>>

Re: [tooling] Moving forward with IDE tooling

[Justin Edelson <ju...@justinedelson.com>]

Ian - please do add the autosync use case to the wiki page I created.


On Thu, May 30, 2013 at 9:47 PM, Ian Boston <ie...@tfd.co.uk> wrote:

> Hi,
> +1 to that. After working on sling for many years doing a mixture of bundle
> and UI work, mainly using the FileSystemResolver bundle, I realise now if
> VLT had been available with sync mode (ie auto syncing the repo and the
> file system), we (the team I was working with at the time) would have made
> much more rapid progress. UI dev work needs file-save-refresh. The in
> browser editing UIs deliver this, as does VLT in sync mode, but
> unfortunately native eclipse based tooling is just too slow (on my machine,
> might be my machine). Using VLT since I joined Adobe, has been a joy, and I
> am very glad to know its being donated to the ASF.
>
> Had we had VLT then, we would have developed in a very different way, and
> might not have had half the problems we had with tooling and team
> structure.
> Ian
>
>
> On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com> wrote:
>
> > Hi,
> > I would strongly suggest that this effort be based on VLT. As mentioned
> on
> > the wiki page, we're in the process of moving that to ASF and I think
> once
> > the code is available, it will be clear that it provides a good low-level
> > interface for this type of UI.
> >
> > While it is true that VLT currently only works with DavEX servers, I
> > suspect it would not be hard to isolate the "Ex" bits and have a "WebDAV"
> > only driver which could be used on non-JCR applications for basic file
> > operations.
> >
> > My concern is that we end up building one more abstraction which is going
> > to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,
> etc.).
> >
> > I know VLT has some baggage, but I'd just ask that people keep an open
> > mind.
> >
> > Separately, I'm going to start a child page of this wiki page to gather
> use
> > cases. There are some functional areas listed on the main page, but I
> think
> > we should try to capture individual use cases.
> >
> > Regards,
> > Justin
> >
> >
> > On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <rombert@apache.org
> > >wrote:
> >
> > > Hi,
> > >
> > > Following Antonio's kick-start of the Sling developer tooling [1] I've
> > > gathered some thoughts about the initial goals and implementation of
> our
> > > Sling IDE tooling.
> > >
> > > The document is at [2] so please have a look and let me know what your
> > > thoughts are. I intend to take a pass at the code next week and align
> it
> > > to the proposed structure, as a foundation for feature work.
> > >
> > > Robert
> > >
> > > [1]: https://cwiki.apache.org/SLING/slingclipse.html
> > > [2]:
> https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
> > >
> > >
> >
>

Re: [tooling] Moving forward with IDE tooling

[Ian Boston <ie...@tfd.co.uk>]

Hi,
+1 to that. After working on sling for many years doing a mixture of bundle
and UI work, mainly using the FileSystemResolver bundle, I realise now if
VLT had been available with sync mode (ie auto syncing the repo and the
file system), we (the team I was working with at the time) would have made
much more rapid progress. UI dev work needs file-save-refresh. The in
browser editing UIs deliver this, as does VLT in sync mode, but
unfortunately native eclipse based tooling is just too slow (on my machine,
might be my machine). Using VLT since I joined Adobe, has been a joy, and I
am very glad to know its being donated to the ASF.

Had we had VLT then, we would have developed in a very different way, and
might not have had half the problems we had with tooling and team structure.
Ian


On 31 May 2013 10:16, Justin Edelson <ju...@justinedelson.com> wrote:

> Hi,
> I would strongly suggest that this effort be based on VLT. As mentioned on
> the wiki page, we're in the process of moving that to ASF and I think once
> the code is available, it will be clear that it provides a good low-level
> interface for this type of UI.
>
> While it is true that VLT currently only works with DavEX servers, I
> suspect it would not be hard to isolate the "Ex" bits and have a "WebDAV"
> only driver which could be used on non-JCR applications for basic file
> operations.
>
> My concern is that we end up building one more abstraction which is going
> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.).
>
> I know VLT has some baggage, but I'd just ask that people keep an open
> mind.
>
> Separately, I'm going to start a child page of this wiki page to gather use
> cases. There are some functional areas listed on the main page, but I think
> we should try to capture individual use cases.
>
> Regards,
> Justin
>
>
> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <rombert@apache.org
> >wrote:
>
> > Hi,
> >
> > Following Antonio's kick-start of the Sling developer tooling [1] I've
> > gathered some thoughts about the initial goals and implementation of our
> > Sling IDE tooling.
> >
> > The document is at [2] so please have a look and let me know what your
> > thoughts are. I intend to take a pass at the code next week and align it
> > to the proposed structure, as a foundation for feature work.
> >
> > Robert
> >
> > [1]: https://cwiki.apache.org/SLING/slingclipse.html
> > [2]: https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
> >
> >
>

Re: [tooling] Moving forward with IDE tooling

[Justin Edelson <ju...@justinedelson.com>]

Hi,
I would strongly suggest that this effort be based on VLT. As mentioned on
the wiki page, we're in the process of moving that to ASF and I think once
the code is available, it will be clear that it provides a good low-level
interface for this type of UI.

While it is true that VLT currently only works with DavEX servers, I
suspect it would not be hard to isolate the "Ex" bits and have a "WebDAV"
only driver which could be used on non-JCR applications for basic file
operations.

My concern is that we end up building one more abstraction which is going
to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, etc.).

I know VLT has some baggage, but I'd just ask that people keep an open mind.

Separately, I'm going to start a child page of this wiki page to gather use
cases. There are some functional areas listed on the main page, but I think
we should try to capture individual use cases.

Regards,
Justin


On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <ro...@apache.org>wrote:

> Hi,
>
> Following Antonio's kick-start of the Sling developer tooling [1] I've
> gathered some thoughts about the initial goals and implementation of our
> Sling IDE tooling.
>
> The document is at [2] so please have a look and let me know what your
> thoughts are. I intend to take a pass at the code next week and align it
> to the proposed structure, as a foundation for feature work.
>
> Robert
>
> [1]: https://cwiki.apache.org/SLING/slingclipse.html
> [2]: https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling
>
>