When skipping Javacode and Bundles (which I'm not so happy with) one option would also be to have something like a ResourceProvider that for "dev" time redirects and takes data from the FS. As long as we have the mentioned same machine scenario the synchronisation is IMHO not necessary, better have a FS Resourceprovider that gets more capabilities than the current one. IDE support could even have some trigger to switch between FS-mode and Repo-Mode with an automatic deployment/push when switching.
WDYT? Dominik On Mon, Jun 3, 2013 at 7:25 AM, Carsten Ziegeler <cziege...@apache.org>wrote: > For c) java code and bundles, I would suggest to leave this out for now and > see if we can integrate other tooling for that work. I'm currently > exploring options and maybe we can leverage other peoples work for that > > Carsten > > > 2013/6/2 Dominik Süß <dominik.su...@gmail.com> > > > 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 > > >>> > > >> > > > > > > > > > -- > Carsten Ziegeler > cziege...@apache.org >
