Important Changes in Alfresco Community Edition 5.0.b

This fall has been a hectic time as we juggled Summit and the preparations for the release of Alfresco One Enterprise Edition 5.0. In the middle of Summit, our team completed the scheduled 5.0 features and got Community Edition 5.0.b out the door in order to receive feedback.

Unfortunately we failed to communicate about some of the important changes in that release. I want to apologize for that, and provide the additional details.

Removed Features

We took advantage of a major version release of Alfresco to do significant spring cleaning of the Alfresco code base. With the release of Alfresco One Enterprise 5.0 we are dropping support for a number of platform features. Consequently, while completing our development effort for the Enterprise Edition release we removed that functionality. These changes were included in the Community Edition 5.0.b release.

When we released the Share UI in Alfresco 3.0 we made clear that the Explorer UI would eventually go away. With the release of Alfresco 4.0 we officially deprecated the AVM functionality. When we added Solr to Alfresco 4, we deprecated Lucene. These changes were all first released in Community Edition 5.0.b.

We also worked with our customers to identify features that were obsolete or not broadly used and thus could be eliminated. Most of the features we removed were superseded by something better. We also removed a few integrations that had been deprecated by the other party. Rather than repeating them all here, you can get the details in the 5.0.b Release Notes.

We failed to list these major changes in the release notes, and we regret that our failure to communicate caused some painful upgrades. We have improved our processes and I believe that we will avoid making this mistake in the future.

As soon as we get a breather with the release of Alfresco One Enterprise 5.0, we will commit the Explorer UI to GitHub as a separate project so that those who want to continue to use it have the option of self maintenance. We will only spend engineering resources spinning the other components out as independent projects if someone steps forward to maintain them. Of course, the code for them is still in the history of the Community Edition repository.

If your implementation depends on the removed features, we recommend that you do not upgrade beyond 5.0.a until you have a migration strategy in place.

With the release of Alfresco 5.0, we are officially deprecating the NFS and jBPM subsystems. These are still present and functional in 5.0.b, but will be removed in a future version. You can see the list of features that are deprecated and scheduled to be removed on the official Product Support Status page. The Support Policies section of the Alfresco Support Handbook is where we keep the official policies that govern how we end maintenance for a product.

Administration Console

For historical reasons, many of the administrative tools in Alfresco relied on UI components in Alfresco Explorer. With the removal of Explorer, we had to re-implement these tools and relied on the UI of the new Enterprise-only Administration console. This affected the consoles for tenants, workflows, and dynamic models. The details are in ALF-21133.

Rather than being a deliberate decision to make these tools Enterprise-only, the removal from Community Edition was an unintended consequence of the removal of Explorer. We are evaluating how best to restore this functionality in Community Edition with a 5.1 release.

Options we are considering include:

  • adding them to the Share console
  • making the framework for the repository tier available in Community Edition so that administrative tools for Community Edition functionality can leverage it.

When we make a decision, I will update ALF-21133.

Configuration Files

Another important change for 5.0 that I should explain is how we are handling configuration files. When we moved the product build system to Maven, we started bundling the configuration files inside JARs, alongside the code that uses that configuration. Overriding the default configuration can still be done in all the previous ways, including by putting override files into the correct location within ${TOMCAT_HOME}/shared/classes or by putting properties into the file.

This change has a few important consequences:

  • It is easier for Alfresco to package and distribute those libraries.
  • It discourages implementers from changing configuration in unsupported ways, by making such approaches more difficult.
  • It makes it easier to maintain system properties because all such changes can be made in a single, centralized location (
  • It makes it harder to find a specific property simply by examining the unzipped WAR.
  • It makes some of our documentation, wiki articles, and forum posts obsolete.

That last two points will take some adjustment.

System administrators will appreciate that we will have updated documentation for the release of Alfresco One Enterprise 5.0. It will provide sample configuration files that can be downloaded into an installed Alfresco instance and customized as appropriate. This has the benefit of providing the files as part of the documentation, so administrators who are attempting to perform a given configuration task have both the descriptive instructions (the documentation) and the sample configuration files relevant to that task.

Developers will be able to find the correct configuration files (properties files, Spring contexts, XML configuration files, etc.) by examining the source code, available via “source JARs” from our Maven artifacts repository or our Subversion repository. Given that this is a requirement to build Alfresco AMP extensions, most developers will already be setup to access these JARs.

The main issues for this topic are ALF21120 and ACE3025.

We Will Communicate More

We are sorry that we did not handle these issues better. These mistakes are opportunities for us to improve how we communicate and collaborate with members of our open source and developer communities.

The Alfresco team will be growing a lot over the next few months, and we are specifically increasing the number of people working with our open source and developer communities. I will be transitioning to a product management role tasked with managing our Community Edition releases, and will be in a better position to check the release notes for accuracy and completeness. I will be complimenting the efforts of Kevin Roast who has been our main product advocate up to this point. This will be in addition to our current community efforts, which we manage by adding people to the team.

We appreciate your feedback and look forward to future conversations.

Next entry

Previous entry

Related entries

Similar entries


Comments are closed.


Pingbacks are closed.