Alfresco SDK 4.0 has not been released yet, but it is in beta and developers are starting to use it.
To help developers who want to learn the platform using SDK 4.0 and Alfresco 6, I’ve created an sdk-4.0 branch on the Alfresco Developer Series tutorials project. The tutorials on that branch have been upgraded to the new SDK 4.0 structure.
Aside from the project reorganization and the introduction of the Docker modules the underlying code did not have to change.
In addition to the tutorial source code projects, I also updated the tutorial content bodies to reflect the Docker and Docker Compose features of SDK 4.0 and the minor changes regarding how projects are run and tested. While I was in there I enhanced the markdown with syntax highlighting for code snippets.
Once SDK 4.0 goes GA I will merge the sdk-4.0 branch in the tutorials project into master. Those needing tutorials that leverage the old SDK 3.0.1 will still be able to get them via the sdk-3.0.1 tag.
Incidentally, I used the Alfresco SDK Upgrader script to upgrade these projects and it saved me a lot of time. If you want to know more about upgrading your 3.0 projects to 4.0, either manually or via the script, see this blog post on upgrading.
So, if you are going to learn Alfresco using the latest release, give the updated tutorials a try. If you find any issues, please create an issue on GitHub, or, better yet, fix the issue and open a pull request.
Photo Credit: Veere: tools, by docman, CC BY-NC 2.0
I’ve known Michael Uzquiano, Cloud CMS CTO, and Malcolm Teasdale, Cloud CMS CEO, for at least a decade, so it’s been fun to watch as Cloud CMS has matured over the years.
As a Cloud CMS partner, I often talk to them about issues or ideas related to projects I’m doing for clients with Cloud CMS. Over the years we’ve occassionally found time to chat about more strategic topics. Both the tactical and strategic conversations have been valuable for both sides, but they were definitely ad hoc.
Recently, Malcolm asked if I’d be up for making those conversations more regular and potentially a bit deeper by making me part of the advisory team. Liking both the people and the tech, this sounded like a great idea to me.
Nothing changes for my clients or my company, Metaversant Group, other than the additional insight I might gain from discussions with the Cloud CMS team.
As far as this blog goes, I’ll continue to write about Cloud CMS and others in this space as I’ve done in the past, on topics that interest me. My friends at Cloud CMS might help inform me on technical details for Cloud CMS-related posts, but they won’t be making any editorial decisions. I know my readers value my transparency and openness and that will continue.
I think de-coupled content management is just starting to hit its stride and I’ve enjoyed working with Cloud CMS thus far. I’m definitely looking forward to continuing the discussions with the Cloud CMS crew about company and product direction.
Alfresco recently announced the beta release of SDK 4.0. The release is long-overdue. Developers had become frustrated that Alfresco published generally-available releases of the platform while seemingly ignoring the fact that there was no compatible SDK that could be used to customize and extend version 6.x of the platform. At DevCon this week, Alfresco said they recognize that was not handled as best as it could have been and pushed hard to get the new release out.
Version 4.0 of the SDK uses the same familiar structure that developers used in previous versions and continues to use Maven for dependency management and packaging. But there are some significant changes happening under-the-covers.
Prior releases of the SDK used an embedded version of Tomcat and an in-memory database to allow devs to launch and run Alfresco, along with their customizations, without having to separately download and install the platform. Adding in a tool that does hot Java class reloading such as JRebel or Hotswap Agent adds a greater productivity boost because changes to things like actions, behaviors, and web scripts can be run immediately, with no restart in most cases.
From a developer’s perspective, your “flow” doesn’t change–the SDK still bootstraps your project into a familiar structure and runs Alfresco with your changes, along with hot-swapping, if you want. The SDK no longer uses embedded Tomcat and H2. Instead, it relies on Docker and Docker Compose. When developers run an SDK project, images from Docker Hub (Community Edition) or Quay.io (Enterprise Edition) are downloaded, overlayed with the developer’s customizations, and launched.
If that sounds painful, relax, it’s not that bad. And the SDK 4.0 docs have everything you need to get productive quickly.
If you’re like me, though, you have many projects, open source and otherwise, that you must now upgrade so you can test them against 6.x. Doing it manually isn’t terrible but it is a bit mind-numbing and can be error-prone. Never fear, though; for help, read on!
Lots of projects to upgrade? DevCon hackers have you covered!
I had the pleasure of participating in the Hack-a-Thon at DevCon again this year, organized, as usual, by community icon, Axel Faust. I wasn’t sure what project I would work on when I woke up that morning, but when I saw there was a group of folks interested in working with SDK 4.0, I joined the team.
First, the group of eight fellow hackers started testing the SDK. For many it was their first time working with SDK 4.0. Windows, MacOS, and Linux were all represented and the group covered the various types of archetypes (all-in-one, repo-only, share-only). Every developer was successful bootstrapping a project and launching the Docker containers using the script that ships with the SDK.
JRebel has worked fine for me in SDK 4.0 for both Community Edition and Enterprise Edition, but no one in the group could get HotSwap Agent, the free alternative to JRebel, working. Filip promised to file a issue on Github, so hopefully it is easy to fix.
While the crew of testers were hammering away, I documented the steps needed to upgrade from 3.0 to 4.0 and filed a pull request to add that to the already-helpful SDK 4.0 documentation. Ole has already merged it. Thanks, Ole!
With the upgrade steps documented and the rest of the team familiar with the tool, we moved on to the next phase: Automating the upgrade. The result is a new Github project called alfresco-sdk-upgrader that you can leverage to upgrade your own SDK projects. It isn’t as full-featured as we wanted. For example, if you’ve customized your SDK pom files you’ll need to manually merge those changes. But I think it is still useful in its current state.
Here’s a video of the script in action:
You can see that I start out with a project based on SDK 3.0.1. The alfresco-sdk-upgrader script does everything needed to convert it from SDK 3.0.1 to 4.0. After it runs, the video shows the new project structure and then you can see that the run script fires up the Docker containers.
Mitch and Omar did a lot of work on the script. I don’t think any of us were planning on writing bash when we arrived that morning, but they happily rolled up their sleeves and knocked it out. We’d love it if you’d test it out on your projects and, if you feel so inclined, make it better by filing a pull request.
Even if you don’t want to use the script, you should give SDK 4.0 a try while it is still in beta so you can provide your feedback. And, if you’re curious about what other fun stuff got cranked out a the Hack-a-Thon, take a look here.
Alfresco SDK 4.0 has not been released yet, but it is in beta and developers are starting to use it.
I’ve known Michael Uzquiano, Cloud CMS CTO, and Malcolm Teasdale, Cloud CMS CEO, for at least a decade, so it’s been fun to watch as Cloud CMS has matured over the years.