I'm trying to summarize my thoughts including the several opinions scenarios stated: a) The main usecase seems to be development from IDE (persisted to FS and therefore to be integreated with any FS based versioning tool of choice) b) a (on save) sync the application from FS to Sling via IDE seems what everybody needs and agrees on c) Not directly mentioned but what I think should be defined as well how and when bundlebased (JAVA) code gets synced to the repository d) where I didn't hear consensus is about syncing from Sling to FS. The reason why I have my problem with that, is that autosync needs an explicit definition how structures get mapped. In direction repository this is easy since this unwraps the filebased (xml or json) wrappers and creates a lot of finegrained strucures, but the other way around there would be the need of an implicit way how those structures get serialized to the FS or some (potentially) complex definition that a dev would have to make (possible with vault afaik, but IMHO errorprone). e) one of the main reasons for d is to see changes from the repository within the IDE. I here fully second Carsten that this shouldn't be automagically resolved but be controlled from the dev. The IDE here can create some tooling to identify and display changes and support the job to reestablish synchronity (this might be the hardest part for the tooling since I havent seen a proper ui doing such a job). f) regarding "sample" content mentioned by Ruben I think some packagingmechanism and a maven task to upload/download this package should besufficient (lock package, upload, change content in repo, download package, check in vcs)
Cheers Dominik On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser <r...@headwire.com> wrote: > we frequently have a content project during development with a sample site > that can be deployed over maven to a local dev instance. Maintaining the > sample content in the project requires to author in the cms and then sync > back to file system. Making bulk changes to the structure (for example, > globally rename a sling:resourceSuperType) is easier done in the IDE. > Content is then pushed back into the repository. I am not saying a constant > sync is needed, but a way for the IDE to 'update from repository' would > really help. > > The vlt sync command has another issue. Since it stores its state in the > local file system but relies on the server to manage the files your server > instance and file system can get out of sync (say your server crashes and > you have to reinstall it). Switching instances (say current version vs new > version) for testing purposes (is everything still working fine) is not > well supported either. > > Ruben > > > On 6/2/2013 6:35 AM, Antonio Sanso wrote: > >> On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler 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. >>> >> +1 >> >> 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. >>> >> +1 >> >> Regards >> >> Antonio >> >> >> 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<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> >>>>>>>>>> < >>>>>>>>>> >>>>>>>>> https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.apache.org/SLING/slingclipse.html> >>>> > >>>> >>>>> [2]: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://cwiki.apache.org/****confluence/display/SLING/**<https://cwiki.apache.org/**confluence/display/SLING/**> >>>>>>>>> >>>>>>>> Sling+IDE+tooling< >>>>>>>> >>>>>>> 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 >>> >> >
