Obviously it can depend to some degree how coupled they need to be to those targets, as I’m sure you’ve realized. If I ITD on an interface and then use a declare parents with a wild carded pointcut or an annotation based pointcut to introduce that interface to some java classes, I can build all that without needing the exact target.
If I do need to target a specific class though, you can’t do it. We rely on a coherent type system during compilation once all the aspects have been resolved and done their thing (added methods/fields, changed hierarchies, etc). You could compile against mocks that represent the eventual real targets because the aspects that are built are reusable. So create a jar with your aspects in, ditch the mocks and then you have a reusable library. @DeclareMixin enables some of this too, as when it is used you can just utilize javac to build it, but it is quite similar to the ITD/interfac/decp route really. It sounds messy to get it working in the general case (I guess I - in the compiler - would be simulating the existence of those mocks). cheers, Andy > On Oct 23, 2014, at 4:37 AM, Alexander Kriegisch <alexan...@kriegisch.name> > wrote: > > Sorry, this might be a stupid question with regard to an obvious "hen vs. > egg" problem, but I am asking anyway: > > The beauty of aspect libraries is that they can be compiled separately and > woven later, either by compiling it into Java (source or binary) code via ajc > or by applying them via LTW. This works for most "normal" aspects. So far, so > good. > > Aspects using ITD, e.g. adding methods or members to existing Java classes, > are different though. It seems they cannot be compiled with ajc into separate > libraries without them accessing the target Java classes. While this makes > sense logically, it causes a modularity problem as follows: Say we have a > Maven project containing a Java library and and AspectJ library. The Java > library without aspects is a valid artifact and can be used normally. Another > aspect-enhanced JAR should be an additional artifact created by combining the > AspectJ library and the Java library. But this would require the AspectJ > library to be compileable without a dependency on the Java library. This > would also allow me to have separate aspect libraries doing ITD on the same > target classes. > > My explanation looks awkward to myself, but I hope you understand anyway. My > question is: Is there a way to compile ITD aspects independently from the > target classes and later weave them into those very target classes, similar > to LTW where aspects are compiled but unfinished until woven into the > classes? Or would it be at least thinkable to have such a feature in the > future? > -- > Alexander Kriegisch > http://scrum-master.de > _______________________________________________ > 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
