Over a million developers have joined DZone.

Multi-Project AspectJ Builds With Gradle and Eclipse

The Gradle-Eclipse combination ecosystem is great for integration. Added multi-project builds however complicate projects, alongside AspectJ's presence. Here's a look at multi-project Eclipse and Gradle builds with AspectJ, including the environment, modelp, AspectJ setup, and Gradle configuration.

· Java Zone

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

Using Gradle for build/CI, and Eclipse for development, is a nice ecosystem with reasonable integration, but things get a bit trickier when we add multi-project builds and AspectJ into the mix. This post goes through some of the manual steps required to get it all working together.

Environment

Note: I am using the built-in Gradle Eclipse plugin, but not the Eclipse Gradle plugin

The Multi-Project Build

For reasons beyond the scope of this post, I’m using three projects, in order of dependency:

model – A rich domain model
persistence – A project which uses AspectJ to layer a set of generic persistence-aware superclasses on top of model
modelp – A project which takes the emitted classes from persistence and adds all the necessary persistence plumbing, such as hibernate mappings, optimized DAOs, etc.

Gradle Configuration

Details irrelevant to the multi-project configuration are omitted.

Persistence Project:

dependencies {
ajInpath project(path: ':model', transitive: false)
}

The persistence project will then emit all of the classes from the model project woven with the aspects from persistence. Note that the upstream dependencies of the model are not woven, nor are they automatically available to the persistence project. We need to use the normal Gradle dependency mechanisms if we want to do that.

Modelp Project

Similarly:

dependencies {
ajInpath project(path: ':persistence', transitive: false)
}

Eclipse Configuration

So far so good. Gradle is pretty clever about wiring up multi-project builds. Eclipse is a little less clever, or maybe just different. So after

gradle eclipse

we still have some manual steps to do to recreate this setup in Eclipse.

AspectJ Setup

Gradle’s eclipse plugin does not integrate with the Gradle Aspectj plugin and hence doesn’t apply the AspectJ nature to the eclipse project. So we have to do that manually:

right-click on project -> Configure -> Convert to AspectJ project

We then need to set the inpaths, via Build Path -> Configure Build Path... -> AspectJ Build.

Here we come to the first difference between Eclipse and Gradle. If we add the upstream project to the inpath, AspectJ will try to weave all of that project’s referenced libraries as well. In effect, Eclipse is missing the “transitive: false” argument we used in Gradle. This is (mostly) harmless (probably), but it’s slow and can throw spurious errors. So instead of adding the whole upstream project to the inpath, we add the project’s emitted class folder. For modelp, it’ll look like this:

Image title

Dependent Project Setup

We still need the upstream project and its libraries to be available to the Eclipse compiler. The Gradle Eclipse plugin will take care of this if we have a normal compile project dependency in our Gradle build (e.g. compile project(":model")), but we don’t necessarily need that for our Gradle build. If we only have the inpath dependency the Gradle Eclipse plugin will miss it, so in Eclipse we also need to add the upstream project as a required project in the Java Build Path, like so:

Image title

Export Exclusions

By default, adding the AspectJ nature to an Eclipse project causes it to export the AspectJ runtime (aspectjrt-x.x.x.jar). As all three of these projects are AspectJ projects, we end up with multiple defined runtimes, so we need to remove the runtime from the export list of the upstream projects.

Gradle is much better than Eclipse at dealing with complex dependency graphs. In particular, if an upstream project depends on an older version of a jar and a downstream project depends on a newer version of the same jar, the newer version will win. In Eclipse, both jars will be included in the classpath, with all the corresponding odd behaviour. So you might also need to tweak the export exclusions to avoid these situations.

Run Configuration

Once you’ve cleaned up the exports from upstream projects, Eclipse will cheerfully ignore your exclusions when creating run or debug configurations, for example when running a JUnit test. This seems to be a legacy behaviour that has been kept for backward compatibility, but fortunately, you can change it at a global level in the Eclipse preferences:

Image title

Make sure the last item, “only include exported classpath entries when launching”, is checked. Note that this applies to Run configurations as well, not just Debug configurations.

Conclusion

The Eclipse configuration needs to be redone whenever you do a gradle cleanEclipse eclipse, but usually not after just a plain gradle eclipse. It only takes a few minutes to redo from scratch, but it can be a hassle if you forget a step. Hence this blog post.

Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.

Topics:
gradle ,eclipse ,aspectj

Published at DZone with permission of Jaime Metcher, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}