[GRADLE-2601] Provide proper out of the box support for AspectJ Created: 17/Dec/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Marcel Overdijk Assignee: Unassigned
Resolution: Won't Fix Votes: 10


I'm aware GRADLE-684 was similar request and closed with Won't Fix but I think it needs to be reconsidered.
Many people are using AspectJ so proper out of the box support for AspectJ will have a lot of added value. I mean most Spring projects I have worked on it all use it. This could also pave the way easier to support Gradle in Spring Roo projects as being suggested by Hans himself: https://jira.springsource.org/browse/ROO-1097

Comment by MikeN [ 30/Dec/12 ]

Certainly agree on this. The current AspectJ 'plugin' is quite a hack that simply replaces the compile task (no offence to the original author intended).

Using the AspectJ compiler API it would be possible to take advantage of for instance the Gradle daemon. (The currently plugin simply forks a new Ant task)

I've been looking into this, and it shouldn't be too much work. The main problem is that I cannot easily implement it as an external plugin, since most of the Java plugin tooling is in internal packages (and is thus not ment for reuse by other devs).

Some notes:

  • The AspectJ API could be called like the Sun compiler is called in package org.gradle.api.internal.tasks.compile.SunJavaCompiler, see here for more on the API (scroll down).
  • The JavaCompileSpec would have to be extended to include AspectJ options (most notably the aspectpath)
  • A new Compile task should be introduced that extends org.gradle.api.tasks.compile.JavaCompile but uses a different JavaCompilerFactory.
  • A couple of above classes rely on internal classes or on <JavaCompileSpec> instead of <T extends JavaCompileSpec>, so they may need some refactoring

Would love to help out, but could use some guidance from a core developer here (don't want to develop some plugin that uses internal stuff which then breaks on the next release).

Comment by Adam Murdoch [ 14/Jan/13 ]

@MikeN, could you raise this on the dev mailing list? We can discuss how to implement this there.

Comment by MikeN [ 14/Jan/13 ]

Will do, may take a while though, since my schedule is a bit full atm.

Comment by Adam Murdoch [ 16/Jan/13 ]

No rush - whenever you're ready.

Comment by Joe Fitzgerald [ 20/Jan/13 ]

Is there any reason you wouldn't use this?: https://github.com/SpringSource/spring-security/blob/master/buildSrc/src/main/groovy/aspectj/AspectJPlugin.groovy

Comment by MikeN [ 21/Jan/13 ]

That plugin looks better than the one mentioned on the plugin page (at least it's a plugin, and it uses the correct sourcepaths, and sets a input fileset). The only catch may be that it seems to only put other projects on the aspectpath when using the eclipse plugin, so you could be missing a couple of libs on your aspectpath.

The 'better integration with Gradle' point of this issue is still valid though (this simply forks an Ant task, instead of using the whole Gradle compiler infrastructure which would allow for the Gradle daemon to be used).

Comment by David Stemmer [ 18/Jul/13 ]

Has there been any progress on this front? For our purposes, even an Ant fork would be fine.

Comment by Adam Murdoch [ 18/Jul/13 ]

Not yet. We'd welcome a contribution to add this, if you (or anyone else) is interested in helping out. If so, let us know on the dev mailing list and we can help you get started.

Comment by MikeN [ 29/Sep/13 ]

Since I'm still lacking the time to really dive into the AspectJ integration, I simply copied the Spring Security plugin into a separate plugin JAR, instructions here: https://github.com/eveoh/gradle-aspectj

A better integration (incremental build, Gradle daemon support, etc.) would still be nice though...

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:26:21 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.