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