2013/5/31 Robert Munteanu <romb...@apache.org> > > > 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. >
I don't see this as a hard requirement - however, I'm not against this - but I would do this as a second step. So let us do the right think first without thinking about this compatibility and once we have the perfect solution we can add something on top which provides this. If we start with compatibility to vlt in mind, this will definitely restrain us Carsten > > Robert > > > > > > Carsten > > > > > > 2013/5/31 Dan Klco <dan.k...@sixdimensions.com> > > > > > 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: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of > Ian > > > Boston > > > Sent: Friday, May 31, 2013 12:07 AM > > > To: dev@sling.apache.org > > > 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 <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.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 > > > > > > > > > > > > > > -- Carsten Ziegeler cziege...@apache.org
