Re: [aspectj-users] Fwd: AspectJ with Lombok?

[Eric B <ebenzacar@xxxxxxxxx>]

No only a couple of places that use it.  I think the biggest problem is in a single class which is related to the agent for Eclipse - I think.  I temporarily commented it out.

But even with the problem class removed, it isn't generating the correct sources.  And I am having a lot of difficulty figuring out how to debug this when I run it command line, so it's not a very effective debugging process adding in printlns as I go along but without being able to inspect any vars, or even know which implementations are being called for what.

I like your suggesting of trying to jarjar aspectj, but not sure which pkgs need to be modified: aspectjrt, aspectjtools, or aspectjweaver?  I actually tried to jarjar all 3, just to be safe, but when I run ajc with lombok, I get the following error:

[WARNING] You aren't using a compiler supported by lombok, so lombok will not work and has been disabled.

Your processor is: org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.BatchProcessingEnvImpl

Lombok supports: sun/apple javac 1.6, ECJ

Which to me looks like I missed something when I jarjar'ed the pkgs.

But my rule was pretty basic:

rule org.aspectj.org.eclipse.jdt.* org.eclipse.jdt.@1

java -jar ~/Documents/Dev/libs/jarjar/jarjar-1.4.jar process lombok.jarjar.txt ../1.8.2/aspectjtools-1.8.2.jar aspectjtools-1.8.2_lombok.jar

And then pointed to the newly created 1.8.2_lombok version in my maven pom.

So I'm a little lost/confused at this point.  Not sure what/where to try to tackle next.  Was hoping to get some more direction from Reinier Zwitserloot or Roel Spilker (the lead devs) but haven't heard anything back from them yet.

Am open to any suggestions.  I was really hoping to use Lombok instead of Roo (had an unpleasant Roo experience) and not using any spring-data stuff, so figured lombok would be easier.  But I don't know if I'll ever get there.

Thanks,

Eric

On Fri, Sep 19, 2014 at 12:19 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:

For AspectJ we only repackage the minimum we have to do get the compiler going. That is JDT Core plus the annotations support (for annotation processing) and the dependencies of that. We don't touch JDT UI.  This does mean that AJDT does some mapping between the two - fixing exactly the problem you described of having a org.eclipse.jdt.XXX and needing a org.aspectj.org.eclipse.jdt.XXX.  I can see that those UI ones do relate to source manipulation/refactoring (which arguably is not actually a UI concern - but that's another story).

Is it a lot of places where you get that problem in lombok?

On the command line I could maybe imagine a 'hack' to test whether this thing will work at all by jarjar'ing aspectj and converting it back to just org.eclipse.jdt - but that solution wouldn't fly in Eclipse where we rely on the different package names to avoid tripping over real jdt.

cheers,

Andy

On 18 September 2014 18:57, Eric B <ebenzacar@xxxxxxxxx> wrote:

I've been working on it, but it isn't as obvious as I hoped/thought.  I quickly tried to JarJar the compiled package but it didn't work.  So I started manually renaming everything in the packages by hand in the lombok sources.  However, I ran into a problem that I am not sure how to resolve.  Some of Lombok relies on some non-aspectj rebranded packages, specifically: 
   org.eclipse.jdt.internal.corext

   org.eclipse.jdt.internal.ui

The biggest problem I have is that Lombok uses classes from these packages and tries to pass org.aspectj.xxx classes as arguments to their methods.  Since the classes are original org.eclipse.jdt packages, obviously the arguments do not match the expected type.  ie: passed an org.aspectj.org.eclipse.jdt argument but expecting a org.eclispe.jdt argument.

I tried searching the org.aspectj github site, but can't find either of those two packages having been re-branded.  More importantly, I don't know if/how Lombok hooks into Eclipse; where it relies on original source pkg naming.

Do either of the packages mean anything to you?

Thanks,

Eric

On Thu, Sep 18, 2014 at 2:16 PM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:

The ECJ packages are renamed but there are also numerous extensions here and there to support the likes of ITDs which affect type/method resolution. If you clone the AspectJ repo: https://github.com/eclipse/org.aspectj you will see the compiler in the org.eclipse.jdt.core module - the binary and src are in there. That module is actually built from the repo org.aspectj.shadows - browsing that is more complicated so I'd say glance into the src/zip. I can't say whether lombok would be compatible apart from the package prefix but my gut feeling would be that it would just work.  I wonder if running a jarjar on the lombok code to replace occurrences org org.eclipse.jdt. with org.aspectj.org.eclipse.jdt. might get it into a working state.

cheers,

Andy

On 18 September 2014 09:41, Eric B <ebenzacar@xxxxxxxxx> wrote:

Hi Andy,

Your reply just came in as I was writing my addendum.  I ran across the following post on SO that could hopefully help (http://stackoverflow.com/questions/6107197/how-does-lombok-work).

Lombok codes against a) internal javac apis and b) internal eclipse apis (in a separate processor). JSR 269 does not let you modify existing source code, but when you cast an Element to the underlying AST node, you can actually modify the AST (which is what project Lombok does).

I'm not entirely sure how much ajc deviates from ejc.  Have you just renamed all the packages to be org.aspectj?  Where would I find the sources for EJC to see how much/where AJC deviates?

Thanks,

Eric

On Thu, Sep 18, 2014 at 11:25 AM, Andy Clement <andrew.clement@xxxxxxxxx> wrote:

I had a brief look at this when we added annotation processing support to AspectJ as that is what I thought Lombok was doing. But then I discovered that I think it wanted to be run as an agent when using the Eclipse Java Compiler (on which AspectJ is based). If I recall correctly lombok had hardcoded classnames for ECJ classes in it and in AspectJ we prefix those with "org.aspectj." - that is as far as I got looking though, I'm afraid.  It would be great if someone had a bit more time than me to dig into it.  Possibly you just need a lombok that recognizes this variant of ECJ.

I think within eclipse some people have been turning on both java and aspectj builders to get it to work a little better. the java builder allowing lombok to run then AspectJ running afterwards but that sounds pretty ugly so I've never tried it.

cheers,

Andy

On 17 September 2014 20:27, Eric B <ebenzacar@xxxxxxxxx> wrote:

I'm trying to use Lombok (http://projectlombok.org/) in an AspectJ project, but when I enable AspectJ, none of my generated lombok code is added to my byte code.

I'm not entirely sure how lombok interacts with Javac, but my guess is that the ajc compiler does not recognize lombok the way javac does.

Is there anyway to make these two play nicely?  Can I configure ajc to use/recognize lombok properly?  Or am I forced to pick only one of the two technologies?

Thanks,

Eric

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users