You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2013/06/01 00:27:46 UTC
Re: [tooling] Moving forward with IDE tooling
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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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