Re: [aspectj-users] Compile ITD aspect separately from class to be enhan

["Alexander Kriegisch" <alexander@xxxxxxxxxxxxxx>]

I revisited this problem and had the idea of abusing 'aspectpath' in order to specify not the aspect, but the core library and thus keep the woven core code from being written to disk. This works nicely, and now I can have multiple ITD aspect libraries, combining them at will in order to create woven core code with ITD stuff from all desired aspect libs. I mavenised this approach, publishing it on GitHub [1]. An extensive description is in the "update" section of my StackOverflow answer [2]. I think this is might be an FAQ or at least a "cooking recipe" for anyone who wants to freely combine aspect libraries (with or without ITD) targetting the same core code. I like the result and even think it is kinda elegant. Once the solution was there it was suddenly so clear and seemed so (relatively) simple.

[1] http://stackoverflow.com/a/26523832/1082681
[2] https://github.com/kriegaex/SO_AJ_MavenMultiModule

Andy, I would appreciate your feedback. Maybe you have ideas about how to make it even simpler or more elegant.

Cheers
-- 
Alexander Kriegisch
http://scrum-master.de


Alexander Kriegisch schrieb am 27.10.2014 09:14:

> I finally got around to trying the ITD/interfac/decp route, but the introduced
> methods access class member, so it will not work that way unless the class gets
> refactored to actually also get its members via ITD, which is not an option.
> The mock approach might be the only one remaining here, but the mocks would
> also need to have the members in them. That is almost as bad as having a direct
> dependency on the java lib. Actually I think the whole setup is not so well
> designed, I was just trying to help someone on StackOverflow because the
> problem as such intrigued me. Simulating the mocks' existence within the
> compiler would be the magic solution for me - you would have all the work, I
> would have none ;-) - but I guess that this is too esoteric for me to ever
> expect you to take time to implement it. 
> 
> Thanks for your thoughts and great ideas.
> 
> 
> Andy Clement schrieb am 23.10.2014 17:53:
> 
>> 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).
>> 
>> 
>>> On Oct 23, 2014, at 4:37 AM, Alexander Kriegisch <Alexander@xxxxxxxxxxxxxx>
>>> 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?