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).

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

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

No rush - whenever you're ready.

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

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).

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

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.

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...

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!

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.