DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

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

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
  1. DZone
  2. Coding
  3. Frameworks
  4. Multi-Project AspectJ Builds With Gradle and Eclipse

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.

Jaime Metcher user avatar by
Jaime Metcher
·
Feb. 17, 16 · Tutorial
Like (3)
Save
Tweet
Share
9.63K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Eclipse Gradle AspectJ Build (game engine)

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

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: