Hi Carsten,
On 2 June 2013 18:41, Carsten Ziegeler <cziege...@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 <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 >
