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.
Join the DZone community and get the full member experience.
Join For Freeusing 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:
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:
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:
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.
Published at DZone with permission of Jaime Metcher, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
How To Integrate Microsoft Team With Cypress Cloud
-
MLOps: Definition, Importance, and Implementation
-
Scaling Site Reliability Engineering (SRE) Teams the Right Way
-
Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
Comments