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