Month: October 2016

October 26, 2016

Alfresco Maven SDK: Declaring other AMPs as dependencies

I’ve seen a few questions about how to configure an Alfresco project to depend on other add-ons when using the Alfresco Maven SDK, so I thought I’d do a quick write-up on that.

When you use the Alfresco Maven SDK Archetypes to bootstrap a project, you can select one of three project types:

alfresco-allinone-archetype: Referred to simply as “All-in-One”, this type, as the name implies, gives you a project that facilitates creating both a repository tier AMP and a Share tier AMP, plus it includes a working Solr installation.
alfresco-amp-archetype: This sets up a project that generates only a repository tier AMP.
share-amp-archetype: This sets up a project that generates only a Share tier AMP.

In my Alfresco Maven SDK Tutorial I use both the alfresco-amp-archetype and the share-amp-archetype but I don’t really talk about the All-in-One archetype at all. The reason is two-fold. First, I think for most beginners, the smaller, more focused archetypes are less confusing. Second, on the vast majority of my client projects, that’s the setup I use. Usually, I feel like the All-in-One archetype is overkill.

However, there is an advantage the All-in-One archetype has over the other two. It is able to pull in other AMPs as dependencies. With the single-purpose archetypes, your goal is simply to build an AMP. You can run integration tests against that AMP using the embedded Tomcat server, but if you want to test the AMP with other AMPs, you have to deal with that manually. Usually I just deploy the AMPs to a test Alfresco installation that already has the other AMPs deployed.

But with the All-in-One archetype, you can declare those other AMPs as dependencies, and Maven will go grab them from a repository and install them into your local test environment using something called an “overlay”.

Here’s an example. Suppose you are developing some customizations that you know will be deployed to an Alfresco server that will be running the following add-ons: Share Site Creators, Share Site Space Templates, Share Login Announcements, and Share Inbound Calendar Invites. You’d like to test your code alongside these add-ons.

One approach would be to go grab the source for each of these projects and build them locally to produce their AMPs (or download pre-built AMPs), then deploy all of those AMPs to a test server, then deploy your custom AMP and test.

But all of those add-ons happen to live on a public Maven artifact repository called Maven Central. So a better alternative might be to simply list those modules as dependencies and let Maven take care of the rest.

Here’s how it works. When you generate an all-in-one project, the structure includes not only folders that contain your repo and Share AMP source, but also folders representing the Alfresco and Share web applications. For example, here are the files and folders in the root folder of a project called “test-allinone-220”:

pom.xml
repo
run.bat
run.sh
runner
share
solr-config
test-allinone-220-repo-amp
test-allinone-220-share-amp

In our example, your custom code for the repo tier would go in test-allinone-220-repo-amp and your Share tier code would go in test-allinone-220-share-amp.

The repo and share directories are used to build the respective WAR files and they each have their own pom.xml. So to add the other add-ons to our setup, first edit repo/pom.xml. You need to add the add-ons as dependencies, like:

<dependency>
    <groupId>com.metaversant</groupId>
    <artifactId>inbound-invites-repo</artifactId>
    <version>1.1.0</version>
    <type>amp</type>
</dependency>
<dependency>
    <groupId>com.metaversant</groupId>
    <artifactId>share-site-space-templates-repo</artifactId>
    <version>1.1.2</version>
    <type>amp</type>
</dependency>
<dependency>
    <groupId>com.metaversant</groupId>
    <artifactId>share-login-ann-repo</artifactId>
    <version>0.0.2</version>
    <type>amp</type>
</dependency>
<dependency>
    <groupId>com.metaversant</groupId>
    <artifactId>share-site-creators-repo</artifactId>
    <version>0.0.5</version>
    <type>amp</type>
</dependency>

Then, add them again to the overlays section (without the “version” element), like this:

<overlay>
    <groupId>com.metaversant</groupId>
    <artifactId>inbound-invites-repo</artifactId>
    <type>amp</type>
</overlay>
<overlay>
    <groupId>com.metaversant</groupId>
    <artifactId>share-site-space-templates-repo</artifactId>
    <type>amp</type>
</overlay>
<overlay>
    <groupId>com.metaversant</groupId>
    <artifactId>share-login-ann-repo</artifactId>
    <type>amp</type>
</overlay>
<overlay>
    <groupId>com.metaversant</groupId>
    <artifactId>share-site-creators-repo</artifactId>
    <type>amp</type>
</overlay>

That covers the Alfresco WAR. Now for the Share WAR, edit share/pom.xml and add the Share tier dependencies, like:

<dependency>
    <groupId>com.metaversant</groupId>
    <artifactId>share-login-ann-share</artifactId>
    <version>0.0.2</version>
    <type>amp</type>
</dependency>
<dependency>
    <groupId>com.metaversant</groupId>
    <artifactId>share-site-creators-share</artifactId>
    <version>0.0.5</version>
    <type>amp</type>
</dependency>

And then the overlays:

<overlay>
    <groupId>com.metaversant</groupId>
    <artifactId>share-login-ann-share</artifactId>
    <type>amp</type>
</overlay>
<overlay>
    <groupId>com.metaversant</groupId>
    <artifactId>share-site-creators-share</artifactId>
    <type>amp</type>
</overlay>

Now you can run the whole thing–your custom AMPs plus all of the dependencies–by running ./run.sh. As part of the build, you should see the dependencies being downloaded from Maven Central. As the server starts up, if you watch the log, you’ll see the modules get initialized. And when you log in, you’ll be able to test all of the functionality together.

When you are ready to deploy to one of your actual server environments, you have a choice. You can either copy all of your AMPs to the amps and amps_share directories, then run bin/apply_amps.sh. Or you can deploy the WAR files that are now sitting under repo/target and share/target. Personally, I think re-applying the AMPs against a fresh WAR on the target server is less confusing and less error-prone, but I’ve seen it done both ways.

If the add-ons you want to depend on are not on a public Maven artifact repository like Maven Central, you can still build them locally, run “mvn install” to install them into your local Maven repository, then depend on them as shown.

October 15, 2016

Activiti founders fork the project to create Flowable, an open source BPM engine

On Thursday the news broke that Activiti had been forked to create a new open source Business Process Management (BPM) engine called Flowable. Activiti is a BPM engine that Alfresco Software, Inc. funded to replace JBoss jBPM. The Activiti engine can automate business processes as a standalone application, but it is also the embedded workflow engine that Alfresco ships as part of its ECM platform.

A fork is when the evolution of an open source project intentionally diverges. Instead of one code base controlled by a single entity, a fork creates a second code base from the first, allowing each project to evolve separately going forward in accordance with their own distinct roadmap and governance model.

Forks happen fairly frequently, and in places like GitHub, where a lot of collaboration around open source software takes place, they happen constantly, by design. But when a significant fork happens to a project, especially one that has commercial backing, like this one, it is worth taking note. Alfresco depends on Activiti for its ECM platform, so now it will be forced to either continue to develop Activiti under their own direction, or switch to the new project like any other upstream dependency.

The news of the fork comes about a month after my blog post reporting that multiple Activiti engineers had resigned from Alfresco. It is now public that those engineers were Joram Barrez and Tijs Rademakers, who were absolutely the heart and soul of the Activiti project. Those departures left a big question mark hanging over the future of Activiti.

Then the big news came on Thursday. Tijs Rademakers released this tweet, announcing a new project, Flowable, with a link to a blog post.

The blog post outlined some high-level reasons for the fork:

“We acknowledge Alfresco’s stewardship of the Activiti.org project, and as employees we enjoyed considerable freedom to develop the project over several years. However, things didn’t work out as we expected or hoped. We came to the conclusion the only way to continue evolving our ideas was to fork.”

The blog post goes on to talk about forks, in general, and their potential impact.

I wanted more detail so I spent some time talking to members of the new Flowable project last week to understand why they forked Activiti and what we can expect going forward.

The first thing that is immediately obvious when talking to any of the former Activiti engineers is how much passion they have for the project. Leaving Alfresco was clearly a hard decision. But the hardest part was feeling disconnected from the software they created and the fear that the project would no longer have the stewardship it enjoyed prior to their departure. “We couldn’t just leave it there,” said one of the engineers. Indeed, looking at the Activiti forum as well as the commits for Activiti on GitHub, it is obvious that Alfresco is still working to rebuild the Activiti team.

After their departure, the former employees continued to discuss with Alfresco Software how they might be able to move forward, but the two sides could not reach an agreement. It soon became obvious to the team that in order to move the project forward they would have to take more direct control, and the only way to do that was to fork.

Specifically, the team started with the latest Activiti release, 5.21.0, and added a new feature called “transient variables” and some other small enhancements as well as bug fixes, and released that as Flowable 5.22.0 (GitHub).

It’s actually not unlike the creation of MariaDB after Oracle acquired Sun (and then became owners of MySQL). In fact, it is the stated goal of the engineers for Flowable to be a drop-in replacement for Activiti, just like MariaDB is for MySQL.

The engineers say they are looking forward to getting back to their open source roots. “In true open source fashion, we want people to get involved in whatever way they can, whether that’s documentation, testing, or code contributions,” said the team. The Flowable project will run as a meritocracy, with trusted developers earning commit rights over time, regardless of their commercial affiliation.

The fork has actually made many people in the community a lot more comfortable with the direction of the project because the engineers who created the software and made the vast majority of the commits during its life are now committed to moving it forward, and this fork gives them the freedom to do it. “Everyone has been supportive so far,” the team said, “Now the burden is on us to start releasing.”

Clearly, Alfresco Software is unhappy with the fork. In a blog post published Friday, John Newton, Alfresco co-founder and CTO, said he was hoping for a different outcome:

“Unfortunately, some of my early friends on the Activiti project have disagreed with our direction and have taken the step of forking the Activiti code. This is disappointing, because the work that they have done is very good and has generally been in the spirit of open source. However, the one thing that we could not continue to give them was exclusive control of the project. I truly wish that we could have found a way to work with them within a community framework.”

John’s post indicates that the company intends to continue to develop Activiti. John writes, “We are redoubling our determination to grow Activiti faster, better and more openly.”

Growing Activiti faster will be key. If Alfresco is slow to field a new Activiti team and then fails to give the market what it wants at the pace it wants it, those stuck on a lagging codebase may become frustrated, particularly if Flowable is able to out-innovate Alfresco. Flowable has the advantage here because they are the original core team, they are more nimble, and they can hit the ground running. But without Alfresco as a sponsor, Flowable engineers must find a way to earn a living as well as move the project forward. Ideally they will be able to make the two intersect by finding clients to pay them to stay focused on the project.

Alfresco’s product and strategy depends heavily on Activiti. From a purely commercial perspective it is understandable they would want as much control over the codebase as possible. However, there are other commercial open source companies that have strategic dependencies on upstream open source projects they don’t fully control. Elastic’s dependency on Lucene comes to mind. If Alfresco could participate in the Flowable project in a similar way it could potentially benefit everyone, but John’s post seems to indicate that is not in the cards. The next few months will tell us just how committed the company is to continuing with Activiti as a separate project.

Personally, regardless of what happens with Activiti, I hope Flowable flourishes. If team member passion was the only predictor of success I’d say it’s a sure bet it will.