Hi Andreas,
This is kind of a controversial issue ;-)
Am Donnerstag, den 19.06.2008, 13:46 +0200 schrieb Andreas Hartmann:
> Hi Sling devs,
>
> I'm sorry if this basic question has already been answered, I couldn't
> find something in the list.
>
> My understanding of the "standard scheme" of developing apps with Sling
> is as follows:
>
> Option A: Use scripts which are stored in the JCR repository under /apps
>
> Option B: Use Java classes (servlets) in OSGi bundles
>
> Is this correct?
Both options are valid and :
> Option A seems suitable if all developers have access to a common Sling
> server, and one would probably use the JCR capabilities for code
> versioning.
This is exactly a problem right now. Day is currently working on a
commercial solution to this problem, which is able to export/import data
to/from an revision control system...
I personally prefer a different approach outline below.
> But for a distributed development environment, I'd rather
> use the good old SVN. Is it possible to keep the scripts outside the JCR
> repository? Or would I have to do a roundtrip (export from JCR, commit
> to SVN, update form SVN, import to JCR)? How do you handle this when you
> change for instance the lauchpad webapp code?
You can export your scripts into a JCR system view export file or a JSON
file which you embed into your bundle(s) as content to be loaded when
the bundle is installed. See [1] for more information. You can of course
also just provide the files in as initial content without requiring
more-or-less complex JSON/system view exports.
My favourite is the following though:
* Each developper works in his scripts in his local JCR workspace
* When done the scripts are copied to the bundle and used from within
the bundle without copying them to the repository.
The advantage of this approach is, that the scripts are managed in terms
of OSGi lifecycle management just like any other class in the bundles.
There is no danger of some user tampering with the scripts: You know
exactly what is there. Another advantage used to be easier upgrade
(today, loaded content may also be updated easily) -- still loaded
content has absolutely no versioning guarantees. Thirdly: scripts in the
repository are always available whereas scripts in the bundle are only
available when the respective bundle is active.
The disadvantage of this mechanism is of course, that changing and
testing scripts directly in the repository is much easier. This is why I
suggest using JCR-based scripts during development and bundle-based
scripts for release deployment.
For both approaches you will find an example in the samples/simple-demo
module:
* Scripts to be loaded under src/main/resources/SLING-INF/content
* Scripts loaded from the bundle under src/main/scripts
Hope this helps.
Regards
Felix
[1] http://incubator.apache.org/sling/site/content-loading.html
