As far as I'm aware nothing has changed in terms of jars referenced in manifest.mf - AspectJ has never chased down jar references made via manifest entries. There are two possible things that might be happening:
- AspectJ 1.7 is being a bit more keen in analysis and is chasing down more type references than 1.6 did. So now it is looking for these types where it did not previously (so it didn't matter previously that they were not on the classpath).
- The Eclipse JDT compiler upon which AspectJ is based made some changes in this area and AspectJ picked them up.
I'm probably leaning towards the first possibility. You could verify it by getting rid of the manifest in question and building with 1.6 - if it still builds ok then it wasn't the manifest references that were making a difference. (Let me know if you try this...)
Having said that - I'm not against adding support for following manifest references to augment the classpath, but that would be a new feature request. We can either implement this feature or work out why AspectJ is now requiring more types to be loaded in order to do its work. It can be as simple as when running on JDK7 some 'Collection' that AspectJ is creating is returning its contents in a different order than it does on 1.6.
