Skip navigation
All Places > Alfresco Content Services (ECM) > Blog > 2015 > October

Changes in the Developer Platform

Posted by ohej Employee Oct 19, 2015

Since our last major Alfresco One release we've been working hard to improve and shift gears on the developer platform. Over the coming months, Gab and I will be travelling around to the different Alfresco Days where we will be presenting on this topic. You can view our slides here.

You may have heard of Release Agility and Share Separation, which is just one of the things we've invested in since.

With Alfresco One 5.1 on its way, we wanted to share some of changes in the Alfresco Platform and explain how they affect you.

Share Separation

We covered this in-depth a while back, but the overall goal here is to split Share from the Repository. This way we can be more agile and release Share separately from the Repository and we provide compatibility between the different versions. This way you can upgrade the repository and leave Share as it is, or the other way around, which ultimately makes upgrading easier and more flexible

Upgrade Task Force

To make updates easier we're working on a tool called 'Update Assistant'. This tool will streamline and automate the process of installing hotfixes and service packs. It takes your customizations into account and only touches on the resources that has actually been changed for the update.

This tool will help you keep up to date on the latest service packs and hotfixes with ease. The tool will be available early next year and will support service packs and hotfixes for both the 5.0 and 5.1 code base.

Supported Extension Points

Alfresco is designed with customization in mind, but we have never defined a clear set of supported extension points, and we have not been doing a good job at hardening those extension points and APIs.

In the beginning of the year we did a big round of research where we talked to our customers and partners about various pain points relating to upgrades. One of the biggest issues we identified was customizations breaking between Alfresco releases.

With Alfresco One 5.1 and the Developer Platform project we aim to solve this by defining a clear set of supported Platform and Share Extensions.

Each extension point will be fully documented in the documentation. Eventually as we iterate through the list we will add both complete code samples, a test suite and a tutorial. You can already see some of the work in the docs. The testsuite will be running as part of the build, which helps us ensure we do not break customizations.

The list of extension points are not set in stone, and we will keep adding extension points as we find and validate them with our customers, partners and community. If you feel an extension point is missing we want to know about it! Leave a comment in JIRA, here on the blog or reach out to us by email.

The key take away from the idea of supported extension points: If you are customizing Alfresco and you keep your customizations within the supported extension points, your customizations are safe and should not break between upgrades within a major version.

Module support

Beginning from 5.1, we introduce a new way of loading modules. This means that there will be a new 'modules' folder in the installation directory. Here you can place your modules, and they will be loaded from here. No need to use MMT to install, simply drop your AMP or JAR in here - yes, we will officially support JARs as a packaging format beginning from 5.1.

We are working on Alfresco SDK 3.0 which will feature JAR support, while still supporting AMPs.

You can still continue using MMT to install AMPs, but the recommended way of installing modules will be to place them in the modules folder.

Developer Documentation revamp

We are in the process of completely revamping the developer section of the official docs. We have a completely new 'Developer Guide', 'Architecture Guide' and a 'Reference Guide'. We are taking a use case/task driven based approach, which means that the extension points will be the basis for most of the developer guide, along with tutorials and samples which lives on GitHub.

We will continue to update and publish more in-depth blog posts about these topics as we get closer to the release. We look forward to your feedback!


Alfresco SDK 2.1.1 released

Posted by ohej Employee Oct 19, 2015

I'm pleased to announce that we have just released Alfresco SDK 2.1.1.

This is a minor release, so we have fixed a number of bugs, you can see the full list here.

The biggest change for this release is that we reverted back to Java 7 for the SDK. This means that you are no longer forced to use Java 8 while using the SDK, but the SDK will support both using Java 7 and 8.

Please note that this release does not fully support Alfresco 5.1 just yet. We have started work on the next iteration of the SDK, we hope to have it ready in the coming months.

As always, we welcome your feedback! Raise an issue on GitHub or catch us on #Alfresco on FreeNode.

I also want to thank our community for their contributions, various bug reports and pull requests. We really appreciate your work and feedback, thanks!

Amongst all the bug fixes and features added since my last post, in the 1.0.39 release of Aikau we've added a useful addition to our forms capabilities that I thought would be worth calling out. It's actually something that I've been meaning to add for a while but have never had a use-case to drive its inclusion. If you're not familiar with the different ways in which you can provide a from control with options, then you should review the information in this tutorial before reading any further.


When using a form control (e.g. Select, ComboBox, MultiSelectInput, RadioButtons), you can provide a “publishTopic” attribute that will be used to request the options for that form control to use, however the published payload didn't provide any data about the the current values of the other fields in the form. We've now updated the Form widget to subscribe to a new topic that can be used to update the options-requesting payload with the current form values and then forward the request onto another topic.


In the specific use-case we needed to solve, we needed to get the available sites on the currently selected Cloud network. When the user changed the network we wanted to update a FilteringSelect widget to show the sites for that network.


This extract from one of our form models shows how this can be configured

  name: 'alfresco/forms/controls/FilteringSelect',
  config: {
    fieldId: 'CLOUD_SYNC_TENANT',
    name: 'remoteTenantId',
    label: '',
    optionsConfig: {
      queryAttribute: 'value',
      labelAttribute: 'value',
      valueAttribute: 'value',
      publishTopic: topics.GET_CLOUD_TENANTS,
      publishPayload: {
        resultsProperty: 'response'
  name: 'alfresco/forms/controls/FilteringSelect',
  config: {
    fieldId: 'CLOUD_SYNC_SITE',
    name: 'remoteSiteId',
    label: '',
    optionsConfig: {
      changesTo: [
          targetId: 'CLOUD_SYNC_TENANT'
      queryAttribute: 'title',
      labelAttribute: 'title',
      valueAttribute: 'shortName',
      publishTopic: topics.GET_FORM_VALUE_DEPENDENT_OPTIONS,
      publishPayload: {
        publishTopic: topics.GET_CLOUD_SITES,
        resultsProperty: 'response'
      publishGlobal: false

The key things to notice here are:

    1. We're now using constants for all our topics. As well as reducing the number of string values to maintain, it means that we are able to improve our JSDoc for the topics to include information about the publishers and subscribers of those topics as well as the parameters that should be included in the payloads.
    2. We use topics.GET_FORM_VALUE_DEPENDENT_OPTIONS as the optionsConfig.publishTopic to request that the form (in which the control is placed) should add the current value of all the other fields into the payload provided.
    3. The optionsConfig.publishPayload.publishTopic is assigned the topic that is then published by the form using the updated payload. The subscriber to this topic should provide the options to be displayed.
    4. The optionsConfig.publishGlobal is configured to be false to ensure that the form detects the publication (a Form will generate a unique pubSubScope and pass it on to its child controls in order to scope communication within the form).
    5. It’s also worth noting how the optionsConfig.changesTo configuration is used to trigger a reloading of options as the user switches tenants (networks).


In this example the options retrieval is handled by a service subscribing to the topics.GET_CLOUD_SITES. This is able to check the published payload to find the tenant from which to retrieve the sites, e.g:


if (payload.username && payload.remoteTenantId)
    url : AlfConstants.PROXY_URI + 'cloud/people/' + payload.username + '/sites?network=' + payload.remoteTenantId,
    method: 'GET',
    data: payload


This is obviously just a single example of how this feature could be used. No doubt there will be plenty of other use cases in the future that need to take advantage of this capability.

Cross-skilling seems to be a hot topic amongst our Scrum Teams at the moment. But what does this actually mean and why should anyone want to do it?

What is cross-skilling?

Cross-skilling refers to the breadth and depth of skills that a person may have. We can consider three alternatives.

1. The Specialist has a great depth of skill within just one particular area.


2. The Jack of all Trades has a great breadth of skills, and can cover many areas, but none of them in much depth.


3. The Cross-skilled person has a specialism but is also able to cross into other areas where they have a limited level of skill but can help out. We would call this a 'T-shaped' person.


Why is 'T-shaped-ness' so good? Every team benefits from people who are experts at what they do. They are able to work quickly and effectively in their area of expertise. But what if these  specialists also understand something about each other's areas of expertise? They can now collaborate more easily with each other, help out wherever they can and generally extend the reach of the team. Let's have a closer look at some of the reasons for cross-skilling.

Why cross-skill?

What would drive an individual to become more 'T-shaped' and to extend their skills into other areas?

1. To fill a gap that the team doesn’t have


This makes the team more capable, by extending the skills it can cover.

2. To help out when the team need more of a skill than they currently have available


This makes the team more resilient because it can cope better with changes in workload and absences within the team.

3. To further the skills and experience of the individual


This is a bonus side-effect for the individual, in addition to the advantages for the team.

When to cross-skill?

The motivators for the individual to extend their skill set may be driven by:

  1. Opportunity: The project has a need, perhaps for a new skill
  2. Team-focus: The team has a need, perhaps for more of one skill
  3. Interest: The individual has a desire to learn something new

Cross-skilling should not be driven by Management but should be enabled and supported by them.

How to cross-skill?

Let's have a look at some example scenarios which should explain these ideas.

Case Study 1:

Jason is a Java developer who works on a team where test resource is stretched. He helps to write the automated tests for the project, as defined by the test specialist in the team. He’s not a test expert but he can use his Java skills to facilitate the automated testing.

Case Study 2:

Carla is a UI developer who has a desire to extend her skill-set. She’s working on a team with only one back-end developer, who is due to take extended leave later in the year. Having done some Java training at Uni, she takes a refresher course and begins to do some back-end work, under the watchful eye of the experienced Java developer in the team.

Case Study 3:

Sally is a Scrum Master working on a team that currently has no testers. She wants to help out in this area so she builds up her domain knowledge by completing the available online training and tutorials. Working alongside the team, she carries out some exploratory testing of the stories that are being developed during the sprint, raising any issues she finds with the Product Manager and Developers.

In summary, cross-skilling is a natural, organic process which occurs via an individual’s desire to expand their skills alongside their choice to support the needs of the team. Investing in a new skill may have a short-term cost but this is likely to be out-weighed by the long-term gain for the individual, for the team and for the organisation.

Filter Blog

By date: By tag: