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 <i...@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 <i...@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 <r...@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 <i...@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 <jus...@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 < > romb...@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 cziege...@apache.org
