> Is it possible that ajc launches the APT process from a different point than javac?
I don't know how javac invokes APT. I suspect they probably are different because the spec will only say what APT has to do, not when to do it. cheers, Andy On 24 September 2014 08:03, Eric B <ebenza...@gmail.com> wrote: > 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 >
_______________________________________________ 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
