Hi Andy, When I don’t supply the android.jar file; there is no error, it just does not weave those aspects. I tried changing the signature to Bundl*, but the same issue occurs. If I create a dummy jar file with an empty android.os.Bundle class in it, and include that on the classpath; then the aspects *are* woven. Mike. From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Andy Clement Sent: Thursday, 2 October 2014 4:15 a.m. To: aspectj-users@xxxxxxxxxxx Subject: Re: [aspectj-users] Why are base types required in classpath for ajc? You are correct in that AspectJ, for some pointcuts, has to do a deeper analysis of type information including digging out the super types etc, more so than is required for straightforward compilation. However, your pointcuts don't immediately suggest a huge amount of digging is required - for example you have no declaring type specified in your 'onCreate' reference so that can simply be matched by name. If you don't supply the android.jar which types does it complain that it cannot find? Or does it not complain and just fails to weave? (the latter would be strange) Does it complain about Activity? Given that you didn't say execution(* Activity.onCreate(Bundle)) I don't immediately see why it needs more than just the method name, especially as you are not binding any context. Does Bundle come from the same android jar? You could (as a quick experiment) change it to Bun* instead of Bundle (partial type names with wildcards are treated in a slightly more relaxed way than fully specified types). I did do some work a while ago to do less type chasing but it is certainly possible this could be taken further. On 30 September 2014 16:01, Michael Keeley <mike@xxxxxxxxxxxxxxxx> wrote: Hi,
I have an aspect for the "onCreate" method of an Android Activity class. aspect OnCreate { pointcut captureOnCreate() : (execution(* onCreate(Bundle))); //... }
I also have an android app with a subclass of android.app.Activity (the MainActivity class). public class MainActivity extends Activity { public void onCreate(Bundle savedInstanceState) { //... } }
I build the aspects and my app separately, and then use ajc to build the final product and weave the aspects.
java -classpath "aspectjtools.jar;aspectjrt.jar;%JAVA_HOME%\lib\tools.jar;C:\ADT\sdk\platfor ms\android-17\android.jar" -Xmx64M org.aspectj.tools.ajc.Main -nowarn -Xlint:ignore -inpath "myapp.jar;myaspects.jar;aspectjrt.jar" -outjar "myinstrumentedapp.jar"
(some paths omitted for brevity)
This works fine, the aspects are woven, and my app is now "instrumented" with my aspect.
My question is around the inclusion of android.jar on the ajc classpath. This library is NOT required here to successfully build (assemble) the final jar file; I can omit it and the app is built correctly and runs OK, but the aspects are not woven.
What is it from the android.jar library that ajc requires? I am guessing the base-most declaration of the onCreate method? Is there a way around this?
Would it be possible to make a "fake" android.jar with the correct declarations; such that I could distribute the fake android.jar and myaspects.jar to a 3rd party, and have them (with no jdk or android sdk, only a jre & ajc) re-assemble one of their own apps to include the aspects?
Thanks, Mike.
_______________________________________________ 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 |