I’d like to truly encourage all AEM developers that have a chance to setup AEM application build for giving a try to new approach based on Gradle instead of Maven.
After about 2 years of battle testing Gradle AEM Plugin, I could definitely say that this is stable and powerful alternative of Content Package Maven Plugin. It is not just building CRX packages, because:
- could deploy CRX packages to many instances in parallel
- supports two types of deployment (upload then install to both author and publish or upload then install on author then replicate to publishers / distributing)
- allows to deploy dependent packages before deploying AEM applications being built (satisfying),
- has an ability to setup local AEM instances by specifying only instance JAR and license file (within running single command there will be created AEM author and publish instances with opened debug ports, then after checking that all bundles are active, dependent packages will be installed, then again after performing bundles stability checking, our AEM application will be deployed.
- has embedded VLT tool for e.g archiving JCR content in VCS (sync) or copying JCR content between instances (RCP)
- creates CRX packages when even no VLT files are defined / default files will be generated for projects containing Java sources only
- has an ability to easily combine multiple CRX packages to single all-in-one CRX package dynamically
- builds CRX packages about 3 times faster (the bigger project is the more time is being reduced comparing to Maven approach)
- it has much more features 😉
Generally speaking, I love convention over configuration paradigm. In that way Gradle AEM plugin have been designed. Assuming that we have our JCR content under ‘src/main/content’ and Java sources under ‘src/main/java’ there is nothing to configure to build OSGi bundle and and include it in composed CRX package containing also our components, design etc. The minimal configuration requires only to: specify from where Gradle AEM Plugin should be downloaded, which version should be taken and just applying plugin to concrete project.
Additional configuration presents all default configuration being used when plugin is being applied to concrete project. All this values could be copied to buildscripts using plugin and customized.
However, instead of configuring plugin from the scratch, I am definitelly recommending to start using Gradle AEM Plugin by using Quickstart. It is based on separate Gradle Fork Plugin which allows to fork (generate new project basing on existing / reversed Maven archetype mechanism) Gradle AEM Example project. While forking we need only to fill few properties, absolutely trivial like instance JAR url which could be:
Optionally, there is possibility to specify credentials when type of protocols needs it e.g SMB / SFTP of HTTP with basic auth. In a same way url to license file need to be defined.
Also there is possibility to change port number (e.g from 4502 to any other) in local author / publish url property.
After executing forking and entering newly created project in separate directory, AEM setup could be performed and our local development environment will be ready to use.
As you are probably AEM developer, let’s count… how many times have you been forced to perform these steps manually? To copy JAR to some folder, prepare a script which will run that JAR with openning a debug port. Then you probably had to install service packs, Groovy Console, ACS Commons and other dependent CRX packages which were required by your AEM application to work properly. After doing this n-times I have been very frustrated and you probably also. Now there is a chance that you could say… nah I have a virtualized environment based on Vagrant. I just need to run ‘vagrant up’ and I am done. But…what if we rather want to have native AEM with native performance, man, how about that? Gradle AEM Plugin comes with a help.
What is more, Gradle AEM Example comes with fancy default build configuration. It contains an example of Kotlin code used to develop AEM application (sample OSGi service, Sling model). As you can see, Kotlin is fully interoperable, so it means that it is working on AEM without any kind of side effects and even source code could be mixed with Java so you could start writing Kotlin at any moment, really! What else you could find in Gradle AEM Example? Interesting could be also usages of special keywords: ‘aemInstall’ for including jars under CRX package bundle install path or ‘aemEmbed’ for appending classes from 3rd party JAR library (which is not a OSGi bundle) to classpath of bundle being built.
To sum up, Gradle AEM Plugin and Gradle AEM Example illustrating the plugin usage could be a perfect way for moving AEM development to the next level in future projects using that completly new approach. Mostly if we think about build speed and a gained comfort that AEM developers will love while experiencing it in a daily routine.