Alfresco SDK 3.0 Walkthrough, Part 1

In our previous post we discussed the new version of Alfresco’s SDK and broke down what the main talking points are surrounding it. In this post we’ll go through a basic walkthrough on creating an SDK project and the nuances surrounding it.

Note: For the initial setup of the SDK build we’ll be shadowing this guide here, and will assume you have the prerequisites mentioned there. This walkthrough will be split into two segments.

Archetype Generator

Because the new SDK structure is so different, we’ll need to start from scratch. Don’t worry, it’s not as difficult as you might think.

mvn archetype:generate -Dfilter=org.alfresco:

The above command will list out the possible project archetypes shown below.

Choose archetype:
1: remote -> org.alfresco.maven.archetype:activiti-jar-archetype (Sample project with full support for lifecycle and rapid development of Activiti JARs)
2: remote -> org.alfresco.maven.archetype:alfresco-allinone-archetype (Sample multi-module project for All-in-One development on the Alfresco plaftorm. Includes modules for Platform/Repository JAR and Share JAR)
3: remote -> org.alfresco.maven.archetype:alfresco-amp-archetype (Sample project with full support for lifecycle and rapid development of Repository AMPs (Alfresco Module Packages))
4: remote -> org.alfresco.maven.archetype:alfresco-platform-jar-archetype (Sample project with full support for lifecycle and rapid development of Platform/Repository JARs and AMPs (Alfresco Module Packages))
5: remote -> org.alfresco.maven.archetype:alfresco-share-jar-archetype (Share project with full support for lifecycle and rapid development of JARs and AMPs (Alfresco Module
        Packages))
6: remote -> org.alfresco.maven.archetype:share-amp-archetype (Share project with full support for lifecycle and rapid development of AMPs (Alfresco Module
        Packages))

For this demo we’ll be choosing the 2nd option, the allinone archetype. From there we’ll have to choose an SDK version.

Choose org.alfresco.maven.archetype:alfresco-allinone-archetype version: 
1: 2.0.0-beta-1
2: 2.0.0-beta-2
3: 2.0.0-beta-3
4: 2.0.0-beta-4
5: 2.0.0
6: 2.1.0
7: 2.1.1
8: 2.2.0
9: 3.0.0

And since we want to work with SDK version 3.0, we’ll choose option 9. Now we’ll define project properties as such.

Define value for property 'groupId': : fikaGroupId
Define value for property 'artifactId': : fikaArtifactId
[INFO] Using property: version = 1.0-SNAPSHOT
Define value for property 'package':  fikaGroupId: : fikaGroupId
Confirm properties configuration:
groupId: fikaGroupId
artifactId: fikaArtifactId
version: 1.0-SNAPSHOT
package: fikaGroupId
 Y: : Y

Though it is important to note, that under most circumstances the group id, and ‘package’ property would usually be labeled in such a format ‘com.companyname’ or ‘org.companyname’, but for this demo we kept it short and simple.

The Project Structure

Once you generate the new project, you’ll immediately notice a few distinct differences, compared to the previous SDK versions. There’s no longer a runner, repo, or share directory. There’s also a few new directories called ‘integration-tests’, and ‘src’. Shown below is the folder structure of the generated archetype.

The Main Pom File

The main pom file has had some changes, compared to the pom file you may be used to from previous versions of the Alfresco SDK.

Properties

The main project pom is a little different than the previous one. There are many properties to be configured, as shown below.

Where the default values for “maven.alfresco.edition” is ‘community’, “maven.compiler.source” (and “maven.compiler.target”) is ‘1.7’, and “alfresco.platform.version” (and “alfresco.share.version”) is ‘5.2’.x, but you’ll notice the versions for surf and the locations for solr information are now included where they were elsewhere, previously.

Dependencies

As the comments in the screenshot below will say, this section will be used to define libraries used in Unit and Integration tests.

It is also important to note, that some other dependencies may need to be defined here as well when you’re extending your project.

Dependency Management

These dependencies (shown below) are required for the Alfresco Maven Plugin to work. Including dependencies here allows you to reference them in the Platform or Share poms without including the version or scope tags if needed.

You’ll notice that none of the dependencies have an actual version number attached to them, and instead refer to properties defined earlier in the pom. When you make additions to this sections as you extend your project, it is recommended that you follow that structure, and keep version numbers as properties.

AMP Assembly Plugin

By default this plugin shown below is commented out, but it is required for builds where you intend to create AMP file distributions.

It is important to note that using this plugin may require additional configuration on the assembly.xml file in order to customize the layout of the AMP.

Alfresco Maven Plugin

This plugin is the bread and butter of the project. This is where you’ll declare all the ins and outs of what you’re developing, whether it be a single share extension or a full all-in-one platform extension. Shown below you’ll be able to see the out of the box configuration for an all in one project.

Under platform modules is where you’ll define JARs and AMPs that will be overlaid with and interact with your extension when they get built into their WARs for the run process. The configuration options for the different databases are: <enableMySQL>, <enableH2> (default), <enablePostgreSQL>, or <enableEnterpriseDb>. Each option has its own configuration properties file under “src/test/properties/local” in the main project directory. It is important to note, for any database other than H2, the database must be up and already exist in order for it to work.

The Platform Pom

The out of the box Platform pom shown below is, for the most part, empty. The build plugin defined in both this pom and the Share pom, allows each portion of the project to be built into their respective formats.

It is important to note, that any extensions that will rely on external dependencies, may need those dependencies defined here as well as the parent pom.

The Share Pom

The out of the box Share pom shown below is also, for the most part, empty.

Similar to the Platform pom, any extensions that rely on external dependencies may need the dependencies defined here as well as the parent pom. It is also important to point out that by default the Share pom already has a few dependencies defined.

This will end part one of the walkthrough. Look out for our next installment where we’ll discuss the directory structure, so you’ll know where to put any customizations, and extensions.

Happy Building!

Leave a Reply

Your email address will not be published. Required fields are marked *

From our Blog...

Configuring Alfresco SAML SSO Module with Okta IdP

Alfresco recently released a new patch for their SAML Single Sign On solution module. This module allows Alfresco user’s to configure their Alfresco installation with their Single Sign On (SSO) Identity Provider. In this tutorial, I’ll explain the process of configuring Okta to be used with the module. Note: This tutorial is assuming you’ve followed… Read more »

Read More

Content Migration: Being Prepared

Much like negotiating a treaty between two countries who do not share a common language, someone will be faced with the task of translating. If that translator is not properly prepared the outcome might create more problems than it solves.

Read More

Debugging and Integration Testing in Alfresco SDK 3.0

Alfresco has updated its SDK! See our articles here and here about the basics. In its current state, SDK 3.0 doesn’t support unit testing. It does, however, have a robust Integration Testing framework which, in many ways, covers the same ground and then some. In this article I’ll be going into the basics of Integration… Read more »

Read More