On Fri, 2013-05-31 at 14:20 +0900, Carsten Ziegeler wrote: > I've two major comments - first of all, I think the tooling should be based > on Sling resource API to be able to handle all potential resource > providers.
+1 > In addition the file name .content.xml is really bad as it is > hidden nearly in all OS, IDEs etc. Something like [content].xml is way > nicer - it's an illegal JCR name btw as well. +1 . Although we do need to think about compatibility with command-line VLT checkouts as well. Robert > > Carsten > > > 2013/5/31 Dan Klco <[email protected]> > > > I am open to the idea of using VLT as a base, but we will have to do some > > pretty extensive work to clean up the error handling and messaging. I > > haven't taken a look at the newest version, but 2.4.18 is still a black box > > when it doesn't work, which seems to happen unpredictably. I am assuming > > we would be skipping the CLI stuff and invoking whatever APIs VLT uses > > internally to handle imports/exports, correct? > > > > Another idea I've been thinking about would be some sort of .content.xml > > file editor. Nothing too fancy, more of a helper than a full featured node > > editor. I haven't come up with a UI yet, but is this something that might > > be worth looking into as well? > > > > -Dan > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of Ian > > Boston > > Sent: Friday, May 31, 2013 12:07 AM > > To: [email protected] > > Subject: Re: [tooling] Moving forward with IDE tooling > > > > @Justin, will do. > > > > @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its > > internals). > > > > > > On 31 May 2013 13:48, Ruben Reusser <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > >>>> <[email protected] > > >>>> > > >>>>> wrote: > > >>>>> Hi, > > >>>>> > > >>>>> Following Antonio's kick-start of the Sling developer tooling [1] > > >>>>> I've gathered some thoughts about the initial goals and > > >>>>> implementation of > > >>>>> > > >>>> our > > >>> > > >>>> Sling IDE tooling. > > >>>>> > > >>>>> The document is at [2] so please have a look and let me know what > > >>>>> your thoughts are. I intend to take a pass at the code next week > > >>>>> and align > > >>>>> > > >>>> it > > >>> > > >>>> to the proposed structure, as a foundation for feature work. > > >>>>> > > >>>>> Robert > > >>>>> > > >>>>> [1]: > > >>>>> https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.ap > > >>>>> ache.org/SLING/slingclipse.html> > > >>>>> [2]: > > >>>>> > > >>>> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+too > > >>>> ling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+to > > >>>> oling> > > >>> > > >>>> > > >>>>> > > > > > > > ----- > > No virus found in this message. > > Checked by AVG - www.avg.com > > Version: 2013.0.3343 / Virus Database: 3184/6366 - Release Date: 05/29/13 > > > > > >
