Community
Participate
Working Groups
May 23rd 2006 Barry Kaplan started a thread "syncing AJDT with AspectJ build?" in the news group "eclipse.technology.ajdt". However, I am not sure that it led to an enhancement request - I can't find one at least. I was told that bug #113948 "Repackage AspectJ" might be a possible solution to this, but since I am not sure that my needs are furfilled with it I now submit one myself. My enhancement is simple to understand (most likely not to implement :)). I basically want to be able to specify what version of AspectJ I want to use with AJDT. I develop in Eclipse and use Maven for continous integration and builds. I want to use the exact some version of the libraries in Eclipse as with Maven. I've understood that there are some dependencies on AspectJ from AJDT, but being able to choose e.g. 1.5.0, 1.5.1 or 1.5.2 with the LATEST version of AJDT for Eclipse 3.1.x would probably be sufficient enough. JDT has Java Build Path -> Add Library -> JRE System Library to select the JRE,. Having an equivalent for AJDT (ASPECTJRT_LIB) would make it intuitive.
Created attachment 46335 [details] Picture illustrating problem
The combination of JDT + JRE is not the same as AJDT + AspectJ. AJDT + AspectJ is more like the combination of JDT.UI + JDT.CORE, in that the one in general only works with the matching version of the other, as they are closely related. So in order to be able to use different versions of AspectJ, you need to install different versions of AJDT. I can understand the requirement for your development-time version of AspectJ to match your build-time version. I'm not very familiar with Maven, but at least for plain Ant builds, it's possible (desirable even) to use the classes from AJDT in the Ant build files, instead of using the separate command line install. We're seeing less and less take-up of the command line install compared with the AJDT install, so it's interesting to look at remaining uses of the command line install. In a world where the AJDT package gives you everything you need in one, this version mismatch problem disappears. I'm not saying we're in such a world, but I wonder how far away we are from it...
Unfortunately, the general form of your request is not possible using AspectJ. AJC adds an attribute to each class file it generates that tells the byte code version of the weaver that generated it. Between AspectJ 1.6.8 and 1.6.9, this has been revved up from 6.0 to 7.0. It is generally the case that any class file created by a weaver with a given byte code version is capable of being rewoven with a weaver using the same or greater byte code version. However, it is explicitly disallowed to reweave code that has a higher byte code version than the weaver being used. This is because higher byte code versions may have introduced new kinds of byte code constructs (this is the case in 1.6.9, which introduces new syntax). Now, if you are not doing LTW and not having to reweave any classes, then any byte code created by any recent ajc (ie- 1.5+) should be compatible with a recent aspectjrt (ie- 1.5+). I am closing this as won't fix, but if you can supply a failing example then I would be willing to look into this.
