Sling/Groovy Development with OSGI

After having evaded this whole OSGI/Maven topic, I think it is time that I delve into the whole issue. Lars Trieloff and other helpful people alredy gave me a hint about when to change from webdav/scripting mode to OSGI/Maven bundles.

After several hours and reading several blogs and webpages, I came up with the following pom.xml:



<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>SlingControlmanagement</groupId>
<artifactId>SlingControlmanagement</artifactId>
<version>1.0</version>
<packaging>bundle</packaging>
<build>
<plugins>
<!--
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-scr-plugin</artifactId>
<version>1.0.8</version>
</plugin>
-->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>
test;version=1.0.0
</Export-Package>
<Bundle-SymbolicName>controlmanagement</Bundle-SymbolicName>
<Bundle-Name>controlmanagement</Bundle-Name>
<Import-Package>
org.osgi.framework;version="1.3.0",groovy.lang;version=1.6.0,org.codehaus.groovy.reflection;version=1.6.0,org.codehaus.groovy.runtime;version=1.6.0,org.codehaus.groovy.runtime.callsite;version=1.6.0
</Import-Package>
<Sling-Initial-Content>
SLING-INF/initial-content/libs/myapp;overwrite:=true;path:=/libs/myapp
</Sling-Initial-Content>
</instructions>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>maven-sling-plugin</artifactId>
<executions>
<execution>
<id>install-bundle</id>
<goals>
<goal>validate</goal>
<goal>install</goal>
</goals>
<configuration>
<mountByFS>true</mountByFS>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>generateStubs</goal>
<goal>compile</goal>
<goal>generateTestStubs</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>

</plugins>
</build>
<repositories>
<repository>
<id>apache.incubating</id>
<name>Apache Incubating Repository</name>
<url>http://people.apache.org/repo/m2-incubating-repository</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>apache.incubating.plugins</id>
<name>Apache Incubating Plugin Repository</name>
<url>http://people.apache.org/repo/m2-incubating-repository</url>
</pluginRepository>
</pluginRepositories>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>1.6.3</version>
</dependency>
</dependencies>
</project>


There are several things to point out:

1. I am by no means a OSGI/Maven expert, so consider this to be a first draft
2. the commented out scr plugin is used for declarative OSGI services, details here.
3. the groovy version used for compilation (1.6.3) and within OSGI (1.6.0) are different. This might lead to problem. Best thing to do would be to reinstall groovy-all.jar into the OSGI environment
4. the "Sling-Inital-Content" tag is a convenience used to supply initial content to sling
5. the <mountByFS>true</mountByFS> tag should theoretically allow to have all changes done within the filesystem be propagated to sling. Doesn't work atm, although, unsure why
   
   

So where in REST is the MVC?

Still trying to get my head around REST. Looking at sling, I do see two different approaches:

• view/model combined: a resource is represented by a markup (html), which contains both view and model information. The controller (browser) is responsible for the correct representation and the hypermedia functionality (hyperlinks, forms), which allows navigation and manipulation of the represented data
  
• model exclusively: the resource is represented by a data structure (json), which is both rendered to the controllers (browser) taste as view

Now, from a design point of view, the second one seems cleaner, and very compatible with the MVC pattern. But the first approach is the one the web is build upon, soooo there has to be something about it ...

The idea spinning around in my head is to implement the first approach with Griffon and Sling: Sling will deliver SwingBuilder fragments which then will be interpreted by Griffon. Stay tuned...

Apache's mime-type list

Just stumbled on this while reading the sling mailing list:

Apache's web server default mime-type list, together with associated extensions: might come handy, includes the relevant RFCs in the comment