+2  A: 

When you add Math project to the in path of science project, all of math project's code is sent through the aspectj weaver and properly woven. The results of that weave are written to science project's output folder (not Math project's). So, if you were to look in science project's bin folder, you should see the woven classes there.

If you wanted to keep the in path files separate from the regular files, you can specify an inpath out folder. This folder should also be added to the class path as a binary folder. Also, this folder should be placed above the project dependency to Math project in the "Export and Order" tab of the Java build page for Science project.

Finally, if you run the main class from Science project, rather than from Math project, you will be executing the woven code.

Andrew Eisenberg
Thanks for the response. Basically, you have confirmed for me that I should be able to get this to work and that the inpath was the right way to go. Since writing the question, I've now noticed an error that I'm currently Googling. Maybe that's the only problem... I'll update the question with the error.
gmale
+1  A: 

Your second problem is unrelated to the first. It is saying that com.our.project.adapter.GenericMessagingAdapter was originally compiled and woven against a new version of AspectJ but is being used to binary weave against an older version of AspectJ.

This is essentially the same problem as when you try to run Java classes compiled under 1.6 on a 1.5 VM.

The version number was revved up for the release of AspectJ 1.6.8 (I think, or maybe it was 1.6.7).

The solution is to make sure you are using the latest version of AspectJ for all of your projects (eg- 1.6.9, or dev builds of 1.6.10).

Andrew Eisenberg
Thanks, you are exactly right. I just resolved the exception and updated my question above, accordingly. Unfortunately, for the sake of time, I've essentially been instructed to pull the "math project" directly into the "science project." Clearly, this avoids the problem but I'm unable to determine the impact of fixing the second bug because the code base is completely different now and backtracking in subversion would take too much time. Thanks for your help. Since you're the only response, I'll up vote all your messages and reward you the answer. Thanks!
gmale