Pictuer of a mixer in action

Mixing Grails and Alfresco Share

Alfresco Share and Spring Surf offer a nice extensible foundation for various kinds of content based applications. For some applications, it requires just a few tweaks to Share and you are done. In other situations, you might encounter bigger challenges remaining. Or maybe it is just that you do not feel comfortable with the way things are „usually“ done in Share – like Freemarker templating or its typical Javascript.

Lets be honest: The Share application and the framework also do have weaknesses and our mileage varies.

Personally, I don’t really like the server side Javascript (Link to other post below). Besides, I have seen other requirements, like database access or security which provided food for thought.

Make Sense … and Fun !

I like Grails and the Groovy way – because it can be really productive (and fun !) once you passed the first hurdles and left the initial pain behind.

For quite some time, I was thinking about how to make sense of Groovy/Grails and the Alfresco stack at the same time (… and I don’t care if I’m the only one on the planet ;). In the past, there have been efforts getting these together at small scale – e.g. the introduction of Groovy (Web)Scripting.

This is about a large scale approach. As both, Spring Surf and Grails are based on Spring MVC, I was wondering whether they can be mixed in a single webapp and how nice they play together. With Alfresco Share the only Spring Surf application at hand, I started merging the whole beast with Grails – as a plugin. The dependency (hell) problem to overcome was expected. The only other one was due to a problem with absolute paths used by Alfresco Share to resolve Javascript imports (patch coming). In the end, I think these technologies play together at better than expected.

Here is a short demo video of the Alfresco Share Grails Plugin:

If you would like to try it, out follow the steps below:

Where to go next

As the plugin code is standing there now, it almost required no tweaking to Alfresco code at all. The library-dependency situation should stay stable for a little while, so I hope overall maintainance effort is minimal. That is fairly important to me.

So Grails and Alfresco Share can be squeezed into one webapplication. I would be interested to know whether that can be done with the repo as well. ;)

Seriously, I have to say I’m not quite sure yet where to go from here – suggestions welcome.

Update: Jira issue with fix created

References:

Andreas Steffan
Pragmatic ? Scientist and DevOps Mind @ Contentreich. Believes in Open Source, the Open Web and Linux. Freelancing in DevOps-, Cloud-, Kubernetes, JVM- and Contentland and speaks Clojure, Kotlin, Groovy, Go, Python, JavaScript, Java, Alfresco and WordPress. Built infrastructure before it was cool. ❤️ Emacs.

2 thoughts on “Mixing Grails and Alfresco Share”

  1. Hi Andreas,
    we also have been looking for an approach to combine the advantages of grails and alfresco.
    However we were afraid of the „dependency hell“ and have created two separate contexts communicating over alfresco webservice. The obvious downside is the performance penalty and the missing features in the alfresco webservice.
    It would be really nice to find a way to combine both in one context.

  2. Hi Oliver,

    thanks for commenting.

    Looks like you considered merging the Alfresco repository with Grails.

    Honestly, I think at the end of the day, the advantage is the disadvantage.

    On the one hand HTTP based content retrieval from the repo is lightweight. On the other hand it introduces a more complex setup and you have to care about things you might not want to care about – e.g. serialization, security etc.

    The alternative is dropping a API and implementation for the CMS into your webapp. Java based CMSs I know have a faily big footprint. Not quite sure know big the bare minimum of an Alfresco (embedded repo) is, but with magnolia, the footprint is roughly 50MB. The real problem here is dependency hell of course – once again. I think Grails 3 is supposed to introduce OSGI for plugins. That should get us out.

    Until then we have to die – one way or another. ;)

    Regarding the API/Repo in Grails app idea, I think it should not be too difficult to come up with a Grails plugin providing the Alfresco Foundation services. I guess the lions of work will be untangling dependencies – just as it was with embedding Share.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.