I think you've found all there is. No-one is banging on the door for it to improve - I don't actually see much use of the module system out there in the wild so nothing has moved forward.
cheers, Andy On Thu, 17 Dec 2020 at 22:42, Alexander Kriegisch <[email protected]> wrote: > Okay I found these tests: > https://github.com/eclipse/org.aspectj/tree/master/tests/bugs190/modules > > They are executed according to this configuration: > > https://github.com/eclipse/org.aspectj/blob/master/tests/src/test/resources/org/aspectj/systemtest/ajc190/ajc190.xml > > But I found no cases there in which both application and aspect module > have module info files. The aspect always seems to be compiled without > module info. In a way I understand that, because aspects are kind of > orthogonal (as in cross-cutting) to aspects. Usually we do not want an > application to be dependent on aspects and some more generic aspects > should run with many different types of applications. So here we are > hitting JMS limits. As a result, I cannot e.g. put an aspect module on > an application module's module path in order to access e.g. an > annotation contained in the aspect library along with the aspect. Ajc > throws compile errors in this case. I would have to factor out the > annotation into a separate module, so the application can use the > annotation without the aspect. But then again the application must not > contain a module info file, otherwise I get compile errors again because > it cannot find the aspect (JMS) module. For now, whatever I am trying to > do, the artifact containing aspect-woven code must refrain from defining > a module info, AFAIU effectively breaking the encapsulation intended by > previous JMS usage and putting everything into the default module, > basically reverting it back to Java 8 standard. > > As for myself, I never used JMS before because for me it seems to bring > more problems than benefits. For pure OOP-style applications JMS might > work nicely and promote encapsulation and clean service interfaces, > which is definitely something we would want. In order to marry the JMS > concept with AOP though, I think the way it is implemented now makes the > two of them more or less incompatible. > > -- > Alexander Kriegisch > https://scrum-master.de > > > Alexander Kriegisch schrieb am 18.12.2020 09:59 (GMT +07:00): > > > All documentation I can find concerning JMS support in AspectJ 1.9.x > > is this: https://www.eclipse.org/aspectj/doc/released/README-190.html > > > > I also see a few unimplemented features: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=526242 > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=526243 > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=526244 > > > > After adding support for 'ajc --module-path' to AspectJ Maven plugin I > > experimented a bit with multi-module projects and found that it seems > > to be impossible to do binary weaving by putting any AspectJ module (I > > mean both Maven and JMS module with module-info.java) on the > > aspect-path. In the read-me mentioned above there is just an example > > of weaving the other way around, i.e. putting the target application > > on the aspect module's in-path. Is that due to the missing > > implementation of #526243? It does not help much if Ajc can compile > > projects with module-info files but does not respect JMS semantics in > > multi-module projects. > > > > Maybe I am doing something wrong. Are there any instructive tests in > > the AspectJ source code you could point me to? The AspectJ module > > structure is complicated, it is kind of difficult to find anything > > there. > _______________________________________________ > aspectj-users mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/aspectj-users >
_______________________________________________ aspectj-users mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/aspectj-users
