At first, I want to highlight that an AMP module is not the recommended way to extend or develop against ACS 6. Instead, you should build a (micro-)service that sits next to the repository and use the v1 REST API to talk to the repository.
However, there are certain requirements that cannot yet be met by an extension outside the ACS repository. And, of course, you simply might want to port existing extension projects to ACS 6.
There is also the official "Alfresco SDK" that can help you to jump start extension projects. But this SDK is not updated until after the release of a new ACS version. So we in engineering need to build AMPs independent of the SDK. In this post, I want to share our experiences in the hope that it contains some useful background information.
Basic project structure
We provide plugins for maven to build AMP files. The smallest possible AMP project has a pom.xml file that looks like this:
This defines amp as the packaging type of your project and brings in our alfresco-maven-plugin which provides this packaging. Our plugin is available through maven central so that you do not need to define an additional plugin repository.
Each AMP project should consist at least of these files:
The module.properties file defines this module and helps our module manager to do its job. It basically looks like this:
module.id=my-awesome-module module.title=My awesome module module.description=This is an awesome module module.version=1.0 module.repo.version.min=6.0
The second file is the entry point to the Spring context that makes up the ACS server. You can define new beans in there that will be instantiated during startup and that can be wired up with other components of ACS.
If your project contains Java code, as almost all AMP projects do, then you need to define certain artifacts from the ACS 6 repository as dependencies:
From ACS 6 onwards, each artifact is on its own lifecycle. You can look up the version numbers of each artifact either in the release notes or simply take a look in your ACS 6 deployment. It is important to define each artifact as provided so that it is only used during the compilation of your Java classes, but it is not packaged into the AMP file. If your customization depends on enterprise specific bits, then you need to include the artifacts alfresco-enterprise-repository and alfresco-enterprise-remote-api as well.
Since our artifacts are not always available through maven central, you should add our artifact repository to your build as shown above.
During the test phase in maven, you should only run isolated jUnit tests that do not require a full ACS repository. Tests that require a repository, e.g. to create or modify nodes, should be run as integration tests. The default configuration of the "surefire" (test) and "failsafe" (integration-test) plugins define wildcards for test cases. All classes in src/main/test with a name like *Test are run during the test phase and all classes with a name like *IT are run during the integration-test phase. Your integration tests then might look like this:
This definition of a jUnit test executes the tests in a Spring environment.The @ContextConfiguration of the spring jUnit runner then loads the main ACS context file which starts up the entire ACS 6 repository.
These jUnit tests require additional dependencies in your pom.xml file:
This pulls the image postgres in version 9.4.12 from DockerHub and starts a new, clean container from this image. After running the integration tests, it stops and removes this image again. This requires that you have Docker installed and set up properly on your machine.