Cheesy Title

Do I need to recompile my AEM code for 6.2?

Wed, 27 Apr 2016 00:00:00 +0000

With the release last week of Adobe Experience Manager 6.2 many developers are going to start testing their applications on this new release. In the past, most AEM releases have been, at least at an API level, almost entirely backwards compatible, but with this release, the product management and engineering teams have taken the opportunity to remove some long-deprecated APIs. As a result, many applications will need to be either refactored or recompiled to work with AEM 6.2.

Now might be a good time to review the complete list of deprecated and removed features

You will know recompilation is necessary if, when you install your application into an AEM 6.2 instance, your bundles fail to start and the log messages complain about various unresolved dependencies. Something like:

Unable to resolve com.myco.myco-bundle [472](R 472.0):
missing requirement [com.myco.myco-bundle [472](R 472.0)]
osgi.wiring.package;
(&(osgi.wiring.package=com.day.cq.commons)(version>=5.7.0)(!(version>=6.0.0)))

The actual log message is more verbose, but this is the key part.

What this means is that the bundle com.myco.myco-bundle, which is bundle ID 472 has a dependency on a package named com.day.cq.commons, meaning that a bundle must be export this package. This dependency has a constraint on it which requires that the exported package’s version must be greater than or equal to 5.7.0 and less than 6.0.

This constraint got that way because, in general, OSGi tooling (such as the maven-bundle-plugin and bnd) will automatically generate package import constraits based on the version of the exported package on the classpath at build time and assuming that Semantic Versioning is being followed. In this case, the package com.day.cq.commons was exported in AEM 6.1 with the version 5.7.0.

But before doing some trial and error, it is actually possible to predict whether or not these types of errors will occur by looking at the changes in package versions. If your application depends upon any package which had a major version change between AEM 6.1 and 6.2, it will at minimum need to be recompiled. While every application will be different, what I have observed is that the key packages are these:

com.day.cq.commons
com.day.cq.commons.jcr
com.day.cq.replication
com.day.cq.security
com.day.cq.workflow
com.day.cq.workflow.exec

Click here for a list of the packages which have had major version changes between AEM 6.1 and 6.2.

In addition, there are some packages which have been entirely removed. These are long-deprecated features and, in some cases, packages which were never intended to be used. These have, at least in my observations, been much less problematic for early adopters, but one to call out specifically is org.apache.sling.event. Click here for the full list. If your application depends upon any of these, it will need to be refactored. To see an example of such a refactoring, you can take a look at the first set of changes made for 6.2 support in ACS AEM Commons.

Updating the UberJar

Assuming you need to recompile, the first thing you need to do is update your project to reference the AEM 6.2 UberJar. As documented on https://docs.adobe.com/docs/en/aem/6-2/develop/dev-tools/ht-projects-maven.html, the UberJar is available in two different versions:

An obfuscated version which is freely available on repo.adobe.com.
An unobfuscated version which can only be obtained by licensed customers and partners through Adobe Support (Daycare).

There are a variety of cases when you need the unobfuscated version – certain types of unit tests, certain Declarative Services use cases, etc. These are laid out in the documentation. It is worth noting that these use cases haven’t changed between AEM 6.1 and AEM 6.2. In other words, if you were using the obfuscated version before, you can continue to use the obfuscated version. And if you needed the unobfuscated version, you still need it.

To use the 6.2 UberJar, update the dependency in your project’s pom.xml file to:

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.2.0</version>
    <classifier>obfuscated-apis</classifier>
    <scope>provided</scope>
</dependency>

Or, if you are using the unobfuscated version:

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.2.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

Once this is done, simply build your application. If you have compiler errors, those are most likely due to removed packages or classes and the referencing code needs to be refactored.

ACS AEM Commons 2.4.2 and 3.0.2 Released

Wed, 27 Apr 2016 00:00:00 +0000

I’m pleased to announce the release of ACS AEM Commons 2.4.2 and 3.0.2.

This is a significant release in this project’s history as we are now doing dual releases for compatibility between AEM 6.0, 6.1, and 6.2. As described in this blog post, there are a variety of non-backwards compatible changes in Java packages between AEM 6.1 and 6.2 which requires that many projects, including ACS AEM Commons be recompiled.

If you are using 6.0 or 6.1, you will need to use versions in the 2.x line, 2.4.2 in this case. If you are using 6.2, you need to use versions in the 3.x line, 3.0.4 in this case.

We expect to maintain this dual version release process for a while, based on user feedback.

Aside from 6.2 compatibility, there are some new features in this release:

Fast Action Manager - A fluent API for parallization of synthetic workflows, replication and more.
Path-Based Render Condition - An implementation of the Granite UI Render Condition pattern which makes it easy to show and hide UI elements based on content paths.

There’s also the usual assortment of bug fixes and minor enhancements.

Thanks to the following individuals for their contributions, complaints, ideas, and support:

David Gonzalez (Adobe)
Brendan Robert (Adobe)
Kaushal Mall (Adobe)
Chris Pilsworth (Adobe)
Sreekanth Nalabotu (Adobe)
Steffen Roesinger (Adobe)
Johnny Yang (BizTech)
Dominik Förderreuther (Adobe)
Joseph Rignanese (Adobe)
Florian Brunswicker (Adobe)
Simo Tripodi (Adobe)

As always, while this projects are primarily produced and distributed within Adobe Consulting Services, it is available for usage by other Adobe groups, customers and partners. Contributions and feature suggestions from those groups are also most welcome. More information about this project, including detailed information about the included features, can be found here.

Adding JavaScript Functions for Sightly to Use

Mon, 18 Jan 2016 00:00:00 +0000

One of the great aspects of the addition of Sightly to Adobe Experience Manager is that it allows for standard web technologies (HTML, JavaScript) to be used to build AEM components, something which used to require a knowledge of Java Server Pages (JSP) even for the simplest of components. Structurally, an AEM Sightly template (an HTML page) can invoke a corresponding JavaScript script, called a Use object.

You can read more about how to use JavaScript Use objects in the AEM Documentation

JavaScript Use objects can do just about anything, but they are best suited to doing view-related data manipulation. For anything which is starting to look like complex business logic, you are going to want to refactor that into Java code, either a Java Use object, OSGi services, or a combination of both.

There’s a brief description of the pros and cons of the Java and JavaScript Use APIs here.

But let’s say you started with a JavaScript Use object and then “outgrew” it and now need to integrate some backend services. One way of approaching that is to invoke Java methods from inside your Use object. The implementation of Sightly used in AEM uses the Mozilla Rhino project’s implementation of JavaScript and Rhino provides a high level of interoperability between Java and JavaScript. But this can get a bit verbose. For example, a Use object which gets a list of AEM Assets tagged with a particular tag would look something like this:

use(function () {
    var tagManager = request.resourceResolver.adaptTo(Packages.com.day.cq.tagging.TagManager),
        tags = java.lang.reflect.Array.newInstance(java.lang.String, 1),
        taggedResources,
        taggedAssets = [],
        resource;
        
    tags[0] = "marketing:interest/product";
    taggedResources = tagManager.find("/content/dam", tags, true);

    while (taggedResources.hasNext()) {
        resource = taggedResources.next();
        if (resource.name === 'metadata') {
            taggedAssets.push(resource.parent.parent.adaptTo(com.day.cq.dam.api.Asset));
        }
    }
    
    return {
        assets : taggedAssets
    };
});

For the purpose of illustration, I’m hard coding the tag identifier, although in a real case, you’d likely read this property from the current resource’s properties.

This isn’t awful, but by needing to reference Java class names in our JavaScript code (not to mention the need to create a new instance of an array via reflection) means that we are pretty much back to the state we were with JSPs – component developers need to know some Java specifics in order to write a component. This code would also be pretty hard to unit test.

A different approach would be to further encapsulate this into an OSGi service and then invoke that service from your Use object with something like:

use(function () {
    var taggedAssetFinder = sling.getService(Packages.com.myco.assets.TaggedAssetFinder);
    
    return {
        assets : taggedAssetFinder.find(request.resourceResolver, "marketing:interest/product")
    };
});

This is a lot better, but what I want to illustrate is a different technique which removes all references to Java classes from our code by injecting a custom object into the scope of the Use object. Specifically we’re going to inject a function into the scope so that this code instead becomes:

use(function () {
    return {
        assets : findTaggedAssets("marketing:interest/product")
    };
});

For this, we’re going to use a relatively under-used, but very cool¹ Sling feature – the BindingsValuesProvider. When a script is invoked by the Sling scripting engine as part of request processing² an object is created to store the list of global variables – the request, the current resource, and so on. This object is called the script bindings and is an instance of javax.script.Bindings, a class defined in the Java Scripting API. The Sling scripting engine itself only adds a handful of global variables (listed here); applications built on top of Sling, including AEM, are able to add additional global variables. This is how, for example, the currentPage object is made available to scripts.

There are two ways to use this feature – an easy way and a less easy way. The easy way is that you can register an OSGi service using the java.util.Map interface and having a service property named javax.script.name. When Sling executes a script, it gets all of these services and adds their contents to the Bindings object which will be passed to the script engine. This way is useful for when are adding an object which doesn’t require access to any of the existing bindings. For example, if we wanted to make the Java runtime version available as a global variable named javaVersion we could do something like this:

@Component
@Service(Map.class)
@Property(name = "javax.script.name", value = "any")
public class JavaVersionBVP extends HashMap<String, Object> {

    public JavaVersionBVP() {
        put("javaVersion", System.getProperty("java.runtime.version"));
    }
}

The value any for the property javax.script.name indicates that this additional variable should be applied to any scripting language. If you only wanted to scope this to certain languages, the value would be the script engine name as we’ll see below.

Now in a Sightly template, we can simply write:

Currently running Java ${javaVersion}.

And see the value of that system property.

The less easy way is when we need access to objects from the current bindings. For this, you implement the interface org.apache.sling.scripting.api.BindingsValuesProvider. This interface has a single method, addBindings which is passed the current Bindings object. This allows you to get access to the current request, response, resource, and so on. Sling calls these services in the order of their OSGi service ranking, so you can ensure access to variables created by other BindingsValuesProviders as well.

A warning about performance - these BindingsValuesProviders get invoked on every script call, so you need to be very careful implementing them to ensure that they are performant. Use some kind of lazy loading or deferred invocation pattern wherever possible.

So now that we know how to add global variables, how do we create a new JavaScript function? As I mentioned above, the current implementation of Sightly uses the Rhino JavaScript implementation. Rhino provides a mechanism for new JavaScript functions to be defined in Java using the org.mozilla.javascript.Function interface, although in practice you will most likely use the org.mozilla.javascript.BaseFunction base class. There’s really a single method you need to implement, named call (JavaDoc here) which gets invoked when the function is… called. This method gets invoked with four parameters:

context - this is the Rhino scripting context associated with the current thread. It has some utility methods for doing type conversions and working with the current thread.
scope - the current JavaScript scope object.
thisObj - the value of this when the function is executed. In Sightly Use objects, scope and thisObj will always be identical.
args - an argument array.

If your function’s arguments are booleans, numbers or strings, they will be passed as part of the args array as their corresponding Java type (the wrapper type for primitives, java.lang.String for strings). If however, they are JavaScript objects or other Java objects, the args array will contain instances of these classes:

org.mozilla.javascript.NativeArray - represents a JavaScript array in Java.
org.mozilla.javascript.NativeObject - represents a JavaScript object in Java.
org.mozilla.javascript.NativeJavaObject - represents a Java object passed via JavaScript. The unwrap method can be called to access the original Java object.

Putting this all together, we can write a function to get the tagged assets:

public class FindTaggedAssetsFunction extends BaseFunction {

    private ResourceResolver resourceResolver;

    public FindTaggedAssetsFunction(ResourceResolver resourceResolver) {
        this.resourceResolver = resourceResolver;
    }

    @Override
    public Object call(Context cx, Scriptable scope, Scriptable thisObj, Object[] args) {
        if (args.length == 0) {
            return Undefined.instance;
        }
        String tagId = (String) args[0];
        List<Asset> assets = new ArrayList<Asset>();

        TagManager tagManager = resourceResolver.adaptTo(TagManager.class);
        RangeIterator<Resource> resources = tagManager.find("/content/dam", new String[] { tagId }, true);
        while (resources.hasNext()) {
            Resource r = resources.next();
            if (r.getName().equals("metadata")) {
                Asset asset = r.getParent().getParent().adaptTo(Asset.class);
                assets.add(asset);
            }
        }

        return new NativeArray(assets.toArray());
    }

}

This code gets the tag identifier from the args array and then interacts with the TagManager and assets API to obtain the proper list of assets. It then wraps that list of assets into a NativeArray so that the JavaScript engine understands it as an array and not just a Java object.

Strictly speaking, because Sightly is able to iterate over java.util.List objects, we don’t necessarily need the wrapping of the list into a NativeArray, but this would be important if the array was going to be used elsewhere in our JavaScript Use object.

The corresponding BindingsValuesProvider implementation would be:

@Component
@Service
@Property(name = "javax.script.name", value = "sightly")
public class FindTaggedAssetsFunctionBVP implements BindingsValuesProvider {

    @Override
    public void addBindings(Bindings bindings) {
        SlingHttpServletRequest request = (SlingHttpServletRequest) bindings.get(SlingBindings.REQUEST);
        if (request != null) {
            bindings.put("findTaggedAssets", new FindTaggedAssetsFunction(request.getResourceResolver());
        }
    }

}

I hope you have found this post enlightening and adds a new tool to your AEM development arsenal.

The code in this post can be found on GitHub.

I will admit to being biased because I originally added this feature to Sling. ↩
Or other contexts, but for the purpose of this post, we are just talking about request processing. ↩

Tracking Clicks in the AEM Interactive Video Viewer

Mon, 11 Jan 2016 00:00:00 +0000

AEM Assets includes a great feature called Interactive Video which allows for videos to be easily enhanced with links. While this is primarily intended for commerce use cases, it can be used for education, promotions, or really any case where you want to easily link a video to other content. You can read more about this feature in the Documentation and watch a great video walkthrough here.

Interactive Video supports two different types of links: quickviews and hyperlinks. Quickviews are designed allow the user to see further information such as product details and even add a product to their cart without navigating away from the current page. Hyperlinks are simple hyperlinks which can either open a new browser tab or navigate in the current tab.

Links are displayed in two separate contexts. While the video is playing, they are displayed in a sidebar. These links are context-sensitive, meaning that the links associated with the current video segment are displayed.¹ Upon completion of the video, all links are also displayed in a Call to Action screen.

In this post, I’ll describe how to add reporting calls so that you can track how many users are clicking on these links as well as in which context (sidebar or Call to Action). For the purpose of this post, I’m using Adobe’s Analytics and Adobe Dynamic Tag Management services, but the process would be the same for any analytics/tag management solution.

You can see this code in action on this demo page.

Register Event Listeners

The first thing we have to do is register some event listeners. In the code below videoViewer is an instance of the JavaScript class s7viewers.InteractiveVideoViewer created as part of the Interactive Video embed code. As part of the initialization code for the viewer, videoViewer’s setHandlers() method is called with a list of event handlers. In the initComplete handler, we can get access to two of the components within the viewer and register event listeners for user interactions. These two components interactiveSwatches and interactiveThumbnailGridView correspond to the sidebar and Call to Action end slates respectively. In this case, we use the same listener for both events

"initComplete":function() { 
  var interactiveSwatches = videoViewer.getComponent("interactiveSwatches"),
      callToAction = videoViewer.getComponent("interactiveThumbnailGridView"); 

  interactiveSwatches.addEventListener(s7sdk.event.UserEvent.NOTF_USER_EVENT, onUserEvent, false);
  callToAction.addEventListener(s7sdk.event.UserEvent.NOTF_USER_EVENT, onUserEvent, false);
}

User Interaction Event Listener

The event listener (onUserEvent in this case) is responsible for setting the proper variables in the data layer and then firing a DTM Direct Call Rule. As a data layer, we are using a global JavaScript object named digitalData. The event child object has these properties:

link - the link the user clicked on. Will either be a URL in the case of a hyperlink or a query-string style (e.g. sku=12345) collection of key/value pairs in the case of a quickview.
linkType - either hyperlink or quickview.
location - either sidebar or cta.

Note that we could have used two separate event listeners, but since the link parsing logic is the same in both cases, it made more sense to reuse the event handler and just have some conditional logic to specify the location property based on the event type.

function onUserEvent(event) {
    var trackLink = false,
        eventData = {};
    if (event.s7event.data.length > 0 &&
        typeof event.s7event.data[0] === "string") {

        eventData.link = event.s7event.data[0];
        eventData.linkType = "hyperlink";

        if (eventData.link.indexOf("quickview") === 0) {
            eventData.linkType = "quickview";
            eventData.link = eventData.link.substring(10); // strip off 'quickview:'
        }
        if (event.s7event.trackEvent === s7sdk.event.UserEvent.INTERACTIVE_SWATCH) {
            eventData.location = "sidebar";
            trackEvent = true;
        } else if (event.s7event.trackEvent === s7sdk.event.UserEvent.INTERACTIVE_THUMBNAIL_GRID_VIEW_SWATCH) {
            eventData.location = "cta";
            trackEvent = true;
        }
        if (trackEvent && _satellite) {
            digitalData.event = eventData;
            _satellite.track("video-click");            
        }
    }
}

DTM Data Elements

In DTM, we have some Data Elements set up to extract these variables from the data layer so that they can be passed easily to Analytics. For each of the properties of the global digitalData.event object, we have a corresponding Data Element. Since the value of this object will change during the lifespan of this page (i.e. if a user clicks on multiple images), each Data Element uses the Custom Script type.

The script for each one is simple returning the appropriate value:

return digitalData.event.linkType;

DTM Direct Call Rule

Finally, we can create a DTM Direct Call Rule² which fires the desired Analytics event when a user clicks on one of these images. We use the Data Elements created above to map to 3 separate eVars

Once all of the pieces are in place, clicking on any of the images in the sidebar or the end slate causes an Analytics call with the proper values passed as the eVars.

Conclusion

With a little bit of JavaScript additions, we can add click tracking to AEM’s Interactive Video viewers so that we know how many users are clicking on which of the links in our viewers.

Depending on the size on the player and the number of links associated with the current segment, links associated with other segments may also be displayed. ↩
While a DTM Event Based Rule could be fired based on the click, the link data is not easily accessible, so a Direct Call Rule is more effective. ↩

Does AEM Apps Require AngularJS?

Wed, 14 Oct 2015 00:00:00 +0000

TL;DR: No.

In talking with customers and partners about AEM Apps, one of the most frequently asked questions I hear is “If I want to build a hybrid mobile app with AEM Apps, do I need to use AngularJS?” Or sometimes this gets phrased as “Why do I need to use AngularJS to build hybrid apps with AEM Apps?” Or even “Why are you guys so in love with AngularJS? We’d rather use <fill in the blank>.” So let me start by saying that no, there’s no requirement to use AngularJS for hybrid app development with AEM Apps. There was one place where using AngularJS was highly beneficial, but that’s actually not the case anymore and I’ll come back to this later.

So where did this misconception come from? First and foremost, it comes from the pretty obvious fact that the hybrid sample application we ship with AEM Apps (Geometrixx Outdoors) uses AngularJS. And we do provide some specific utilities for building and exporting AngularJS views into a hybrid application. But the sample app is just that – a sample and those utilities are specifically there to make AngularJS application management easier. Neither is meant to suggest a requirement to use AngularJS. At the end of the day (or, in this case, the beginning of the day), we had to choose something. If we chose ReactJS, odds are we would have this same misconception, just about ReactJS instead of AngularJS.

So no, you don’t have to use AngularJS.

Except for one little thing…

With the version of AEM Apps available with the AEM 6.1 release this year, even if the application itself didn’t use AngularJS, the splash screen (the screen displayed for the brief window of time when the application is initializing) did use AngularJS. And whereas customer applications could write their own splash screen JavaScript code, that probably wouldn’t be a high priority item. However, that has recently changed.

A few weeks ago, Adobe release AEM 6.1 Apps Feature Pack 2. The high profile features in this feature pack are Deep Links for Push Messaging and App Templates. Less heralded, but interesting for the question posed in this entry’s title is a new PhoneGap plugin – the Content Sync Phonegap plugin. This replaces a combination of JavaScript code and the Chromium Zip Cordova plugin with a single point of entry. The end result is reduced client-side code (thereby making the removal of AngularJS easy) and a significant performance boost, about 10x on Android and 2x on iOS.

If you have already built a hybrid app using AEM Apps, updating it to use the new Content Sync plugin is simply a matter of adding the new plugin to your config.xml file and updating a few client library references. Examples of the changes can be found here and here. I’ve also updated my Anatomy of a Hello World App document (described here) to reflect these changes.

With the release of Feature Pack 2, we should remove any doubt that you must use AngularJS with AEM Apps. And if you still have doubts, let me know in the comments and we’ll try to clear up any outstanding misconceptions.

Hello World for AEM Apps - What? Why?

Tue, 29 Sep 2015 00:00:00 +0000

In recent weeks, I’ve been working on a small project to publish a “Hello World” mobile application using AEM Apps. That’s now done, and visible at https://github.com/justinedelson/pgehello, but I also wanted to write up a bit of background on why I did this and how it might be useful to others. First, a bit of background. AEM Apps is a solution within the best-in-class Adobe Experience Manager digital experience management platform focused on mobile application development and management. At its essence, AEM Apps allows for the same separation of concerns which AEM Sites (and before that CQ) has done for websites, namely to allow developers to create a set of components and templates which marketers can then use to build and update digital experiences. And let me stress update here as that’s really where AEM Apps (and in fact AEM in general) shines – the ability for non-technical users to change the content of a mobile application without developer/IT intervention and without resubmitting applications to the various app stores. There’s more to AEM Apps than just this, which you can read all about at http://www.adobe.com/marketing-cloud/enterprise-content-management/mobile-app-management.html. AEM Apps supports a variety of application types: hybrid (using Adobe’s PhoneGap), native (using either embedded web views or direct integration with AEM for content synchronization), and digital publications (using Adobe’s Digital Publishing Solution). For the purpose of this project, my focus was on a hybrid/PhoneGap Enterprise application.

In tradition (Tradition!), a Hello World application simply outputs the text “Hello World” to the console. There are a variety of ways to generate Hello World applications for PhoneGap (or other mobile development systems). But for AEM Apps, this really doesn’t capture the spirit of what the solution can do. So I took a bit of creative license with the definition of a Hello World application in two significant ways. First, rather than just being an application containing static text, the text in the application is authorable and updatable over the air. So while the application outputs “Hello World” if you simply install it from GitHub, you can also change this text using the AEM authoring interface and get the updated text in the application over the air. You can also add images and again, get those updates over the air. Second, this application is integrated with Adobe Mobile Services. This is an optional, but highly recommended, integration for AEM Apps which provides rich application analytics and in-app messaging.

So, why create a Hello World application in AEM Apps? In general, I’ve found there are two different ways in which we learn something new, specifically software development, but it true in other areas in life. These are taking something pre-built apart (and putting it back together) and building something up from nothing. Personally, I tend to prefer the latter. I think this probably comes from when I started programming 30 years ago by copying BASIC programs out of magazines line by line, making typos, fixing them, making more typos, etc. etc. Now we’d call that ‘iterative’ I guess. To bring this back to AEM Apps, the Apps development team has a “Starter Kit” available on GitHub at https://github.com/adobe-marketing-cloud/aem-phonegap-starter-kit for jumpstarting AEM Apps projects. For most projects, the Starter Kit is the right place to start. But for the purpose of building something up from the ground, there’s a bit too much magic in the Starter Kit.

There was a second goal, which is perhaps more important than the actual Hello World application project itself, which was to create an Anatomy document, visible at https://github.com/justinedelson/pgehello/blob/master/anatomy.md. This document describes, in detail, each file in the project and what it does. This was actually much more time consuming that building the application itself as I wanted to ensure that no stone was left unturned. It clocks in at 13 pages. And since the Hello World application is a subset of the Starter Kit (and thus any application based on the Starter Kit), everything in it would apply to the Starter Kit as well.

If you’re interested in AEM Apps development, I’d recommend checking out this project and let me know if you have any questions, either in the comments, GitHub Issues, or by tweeting @justinedelson.

Now get to building some apps!

ACS AEM Commons 2.0.0 Released

Wed, 26 Aug 2015 00:00:00 +0000

I’m pleased to announce the release of ACS AEM Commons 2.0.0

This is a significant release in that we are removing support for AEM 5.6.1. For this release (and any future releases in the 2.x line), AEM 6.0 is considered the minimum platform.

New Features in ACS AEM Commons 2.0.0 include:

Font Awesome Icon Picker widget (for both Classic and Touch UI)
Authorizable Packager
Version Comparison Tool
Synthetic Workflow engine supports Workflow Models

We also ported all of the custom CoralUI 1.x interfaces to use CoralUI 2.x. As part of this work, a handful of AngularJS directives were created. Although these are primarily intended to be used within the project, they may be of use outside the project. More information can be found here.

Related to the removal of support for AEM 5.6.1 is that the Dynamic Tag Management cloud service is now deprecated. Anyone using it should be migrating to the out of the box cloud service.

Thanks to the following individuals for their contributions, complaints, ideas, and support:

David Gonzalez (Adobe)
Sreekanth Nalabotu (Adobe)
Steffen Roesinger (Adobe)
Simo Tripodi (Adobe)
Brian Johnson (3Share)
Koorosh Davoodian (Stanford University School of Medicine)