Hi Andy, Just to keep you updated, I managed to get a debug session working with a remote debugger. Indeed, I had incorrectly jarjar'ed the aj lib, and once I re jarjar'ed it, I got lombok to recognize it. Unfortunately though, it still is not lombok'ing.
That being said, I'm having a lot of difficulty in debugging the lombok code. It uses a bunch of jdt libs to compile, but they aren't the actual ones being used during the debug process (I presume it is using different versions), so stepping through code is a nightmare as the source lines don't actually match up with the remote process being debugged. I have to dig around a little more there and see if I can find out why. In the meantime, I've posted some questions to the lombok list hoping others can point me in a helpful debug process, but so far am awaiting a response. The only thing I noticed from a quick look is the entry point into the lombok lib from ajc and from javac seem to be from two different places. Is that possible? Lombok process gets bootstrapped via APT (from what I can tell). Is it possible that ajc launches the APT process from a different point than javac? Thanks, Eric On Fri, Sep 19, 2014 at 10:00 PM, Eric Benzacar <e...@benzacar.ca> wrote: > Thanks - that'll give me something to play with over the weekend if I get > some time. It never occurred to me to try remote debugging on a local > process. Will give that a shot as well. > > I'll keep you posted on my results. > > Thanks, > > Eric > > On Fri, Sep 19, 2014 at 4:19 PM, Andy Clement <andrew.clem...@gmail.com> > wrote: > >> The three jars are supersets of one another. If you jarjar aspectjtools >> and just use that, it has everything in (including weaver/runtime). In fact >> the compiler classes are only in aspectjtools. >> >> For debugging, can you just use JVM remote debugging? Set that -Xdebug >> etc when launching (or in JVM_OPTS if using a script) and then attach the >> eclipse debugger to it? >> >> > [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 >> >> That does sound like jarjar didn't behave. Did you 'jar -tvf' your jar >> and check everything had been changed back to org.eclipse.jdt? >> >> In theory it would also be possible to build an AspectJ package that >> included those additional bundles lombok wants from eclipse, and jarjar >> those too so the prefixes are all in agreement >> (org.aspectj.org.eclipse.jdt). Then once that package name was supported >> throughout lombok it ought to all work - that is probably what would need >> doing to get it behaving in the Eclipse IDE too. Create an extra bundle >> with the prefixed forms of the JDT UI packages for use just in this context. >> >> cheers, >> Andy >> >> On 19 September 2014 11:10, Eric B <ebenza...@gmail.com> wrote: >> >>> 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.clem...@gmail.com >>> > 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 <ebenza...@gmail.com> 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.clem...@gmail.com> 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 <ebenza...@gmail.com> 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 >>>>>>> <http://download.oracle.com/javase/6/docs/api/javax/lang/model/element/Element.html> >>>>>>> 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.clem...@gmail.com> 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 <ebenza...@gmail.com> 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@eclipse.org >>>>>>>>> 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@eclipse.org >>>>>>>> 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@eclipse.org >>>>>>> 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@eclipse.org >>>>>> 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@eclipse.org >>>>> 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@eclipse.org >>>> 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@eclipse.org >>> 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@eclipse.org >> 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@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
