Build rapidly AEM applications using Gradle Build System

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:

  • file:///c:/aem/6.3/aem-quickstart.jar
  • smb://host/dir/aem-quickstart.jar
  • sftp://host/dir/aem-quickstart.jar
  • https://host/dir/aem-quickstart.jar

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.

PS. Any kind of feedback is appreciated. I will be especially glad if there will be  new issues raised on GitHub or pull requests created helping me with plugin maintenance and development.

Javarel Framework – Web MVC on top of OSGi


I’d like to share with you results of my years of expertise in OSGi world. Few years ago I decided to learn how to build web application from the scratch using most low-level OSGi components.

The road to achieve a working web application using integrated libraries that I like mostly was very exhausting. Incompatibilities related with isolated classpaths, bundle start levels, encapsulation of packages being exported and many other problems are definitely a challenge for even experienced programmers to learn approach for modular Java which is OSGi.

Now I can tell that I can build platform like Adobe Experience Manager from the scratch, especially when I mean about the scale of modularity. I demystified most of its bundles and took the best and composed new solution – framework which is also built basing on OSGi, but concentrates around MVC pattern which most developers like or even know.

Javarel Framework

Project assumptions:

  • beautiful code (like in Laravel which inspires me a lot, thx Taylor!)
  • modern technologies
  • hot deployment
  • runtime configuration
  • none of XML
  • full REST
  • data layer abstraction
  • multiple SQL and NO-SQL storages
  • multiple template engines

I think it is quite stable right now.  Use it as a playground or try to be inspired how could you also integrate in your projects libraries that Javarel has included.

Also now I can tell that Kotlin language is definitely great – whole Javarel is written in this language.  I learned it very quickly (as a Groovy, maybe 1-2 d), but the flexibility which it gives and more error less code  (with controlled null pointers) … I loved it <3 Now sometimes I am even forgetting about Java syntax, because of Kotlin. Writing plain Java for me currently looks like writing mostly boilerplate code. Kotlin just reduces many LOC. To sum up – do same, but quicker – do Kotlin!

OSGi has its difficulties, but extending existing applications on the runtime just gives so power and scalability for long-term projects…  There is no so many developers that took deep drive in OSGi as I did. If you haven’t so much time, just don’t try to follow that road and use Spring , Grails etc and build monoliths. You will be much happier, trust me.  As a opposite I am a masochist and I have fancy modular Java with modern technologies in a form of Javarel, but the integration cost was quite big.

PS. Now I am planning to create even more lightweight framework for web development based on OSGi, but based on Vert.x and definitely more encapsulated with less bundle count to limit OSGi difficulties. Keep in touch!

Debugging OSGi / Apache Felix / Sling much easier

Dear developers,

Basing on my experience, debugging is much easier when we know exact source code which we are using.  Sometimes decompilation is a only way to deal with showstoppers. To speed up that process, I invented and implemented a tool that performs it directly on OSGi instance on runtime.

Sooner or later… you will need it! Brand new plugin for Apache Felix Web Console named just ‘Search’.  Just have a look at: .

I hope that I helped you 🙂

PS.  Appreciate for any pull requests and issues reported  :>

Fancy dependency for Laravel

Today, I’d like to share with you my favorite  PHP libraries that I am using in my projects. I am quite cautious about quality of vendors that I am using so stability of proposed below are confirmed by myself.

Of cource, I am using a Composer…  here is a part of composer.json from some package (all of that deps in correct version you can find on Packalyst or Packagist):

Continue reading Fancy dependency for Laravel

Warning: A non-numeric value encountered in /usr/home/neva/domains/ on line 63