TLDR; Assuming things are meant to scale, I think the Alfresco extension module infrastructure is lacking critical functionality. This post about what, why and my conclusions.
About runtime modules
Extensible runtime environments provide you with various interfaces to plug in third party code. Those interfaces usually come at different scale and nature. You have REST-API for interactions beyond process boundaries and a programming language based API for in-process communication. Runtime discovery and wiring of lifecycle management is the bare minimum required by in-process extensions (frequently called modules or plugins).
As a platform vendor, you’ll likely prefer people staying out of your house (process), because misbehaving guests cause all sorts of issues. In practice, this is hardly possible.
Depending on quantity and volatility of modules and their respective environments, you might want a bit more. Take WordPress as an example. You could likely update themes and plugins interactively once a day – and even core, and even automatically. Surely, you want to try things out every once in a while. At scale you want to be provided with mechanisms to easily install, uninstall, upgrade, start, stop, enable and disable modules.
Module functionality provided by the Alfresco runtime
In Javaland, amongst other things, there is OSGI, Spring and (soon) Jigsaw at our disposal. In Alfrescoland, they decided to build upon Spring. Today, we have two types of modules to choose from, and there has been a heated debate about pros and cons of the proprietary AMP file type promoted by Alfresco Inc. Personally I stopped using them years ago (went with plain jar) and have not missed them since. Seems Alfresco just recently changed its mind and now also favors jar modules (The great value of Alfresco Jar Modules). Some might argue it is great to have somewhat alternative approaches „addressing different use cases“. I disagree because that very fact makes matters complex.
With regards to lifecycle, we are supposed to hook our components into application events fired by the Spring context. Other than that, we have base module components dealing with applicability and dependencies (Module Components) and support for conditional import of bootstrap content (Importing Module Data). There are restartable child context based units called subsystems which do not directly relate to module extensions.
Module infrastructure missing in Alfresco runtime
At the end of the day, whether something is missing or not depends on demand. Assuming that we are aiming at a healthy ecosystem built to scale, I’d like to see:
- One single promoted module extension solution
- Uninstall reliably working
- Downgrade working
- Dead easy/fool proof install/uninstall/upgrade/start/stop (interactive like what we have in WordPress would be awesome)
Some might argue module code isolation (as in OSGI) is a must. Personally I disagree (again due to complexity), and I’d argue that if this is really what you need, a microservice might do as well.
Some of the items listed may not be critical. But still I think we are missing essential functionality and this is pretty remarkable given that the platform has been around for a while.
The current state of the module eco-system stems from what we are given. I’d love to see a flourishing extension market (as in 💰), but I feel we are far far away and we are not even driving towards. In fact, I’d be interested to know whether there is a single profitable extension out there.
I would volunteer helping to move things forward, but again (as with Share), this is not reasonably possible without support from Alfresco. I have asked them about their opinion on modules in general. I am still waiting for a response. Please note that I am not complaining.
Finally, you might want to look at how things are handled over at Nuxeo. I think they got this right – early on.