On one hand it is resources, but I also think if you asked me to implement ITDs today from scratch I wouldn’t do it in the same way anymore. Adding new features that also extend use of that model I don’t like don’t get me excited (especially when they result in me hacking JDT with more dirty changes). Does type pattern matching for ITDs fall into that category? Maybe, not sure. But rewriting it all, that would be a bunch of work.
On contributions: People do contribute now and again - and in fact I’d say I’ve seen more contributions in the last year than in the preceeding 5 years. We only have APT support because somebody put in a lot of time a couple of years ago to add it. But yes, it is mostly me - there are a couple in the Spring Tools team who help me with AJDT because I don’t speak Eclipse Plugin very well. They could work on AspectJ bugs in a pinch but I can’t recall the last time there was an urgent bug, it is more like folks demanding urgent support for the next Java level. I’m always happy to help anyone get to grips with things and contribute but, yes, the build/test infrastructure no doubt turns quite a few off because it is certainly not as easy as it could be. And we don’t have so many of those ‘getting started’ bugs for folks to grab. I'm going to do the maven build thing and try and break down that barrier. I know DeclareMixin isn't perfect and far from a total clean replacement for what you can do with ITDs. I'm not sure I'd say it is totally 'non static' though because once you've done the build those new methods are in that target and can be called directly from any downstream code consuming what you built as a dependency. But I know if trying to access those members whilst in the same project it requires nasty casts. Working as a pure weaver would also mean AJDT doesn't need to weave JDT, in fact AJDT becomes much simpler, we can just use standard JDT tooling with an extra builder that just does weaving. I guess I'm just at the point that for any new feature that introduces native syntax I'd be at least evaluating what the non native syntax would be like and the pros/cons. cheers, Andy On Jan 21, 2019, at 7:57 PM, Alexander Kriegisch <alexan...@kriegisch.name> wrote: As for @DeclareMixin, I can se nothing new there in comparison to my native syntax approach. You might remember that I very much favour native syntax, even though it means more work for you with regard to (A)JDT. ;-) I would be sad to see it go away. I can add all kinds of stuff via "declare parents" or "@DeclareMixin", but all non-static. Even if my interface contains Java 8 static methods, they will not be declared in (as in compiled into) the mixin target class but remain on the interface. I.e., I cannot use it like "MyTargetClass.logger" but only by ways of "MyAspectMixinInterface.getLogger()", which would also mean that it is the very same logger instance for every mixin target class. Usually you want a different logger for each class in order to see its name logged during usage. Regards -- Alexander Kriegisch https://scrum-master.de Andrew Clement schrieb am 22.01.2019 03:58: I think there may be issues open for ITD on type patterns, I had a very quick look but couldn’t find them but it has been talked about before certainly. I am wary of anything that makes ITDs more complicated as there are a few ‘hacks’ in JDT already to support them and I don’t really want to add any more. I even had a vague thought (don’t panic) about removing code style syntax and just using annotation style syntax (provided we had some form of feature parity - annotation style syntax isn’t complete enough yet for this). I’ve been thinking about it for a while but the new speed with which Java is moving is making the patching job something that has to be done more frequently, and it isn’t fun. This would leave all development time simply to improve the weaving and fix bugs there. But at least the type pattern syntax per se and the corresponding matching rules already exist for normal (non-ITD) pointcuts, so maybe just the parser needs to be extended and of course ITD generation itself (the process of actually adding the same members, methods or constructors to a set of target classes instead of a to single one) as well. I’m really not sure what needs doing without digging into it, and I can’t honestly say when I’ll find time for that. But I recognize the power of the feature. How far can you get with a pattern on DeclareMixin? Cheers, Andy On Jan 19, 2019, at 7:42 PM, Alexander Kriegisch <alexan...@kriegisch.name> wrote: Hi Andy. Do you think there is a chance to implement a feature request about enabling ITD for groups of classes instead of having to know exact class names beforehand? A typical example is that people on StackOverflow often ask about declaring static loggers via ITD. If this could be done in a more generic way by utilising type name patterns instead of fixed type names, I think it would be a huge and useful improvement. The only workaround thus far is to use annotation processing, but then you also need to know beforehand which classes to target because you need to annotate them. I personally try to avoid marker annotations because I usually want to keep my core code as clean as possible from AOP-related stuff, keeping the aspects really separate as cross-cutting concerns. I would be interested in your feedback before I just create a Bugzilla ticket out of the blue, maybe without any chance for it to ever get implemented because it would be too much effort to implement it in the first place. I am aware of the fact the the AspectT syntax would need to be somewhat expanded for this. But at least the type pattern syntax per se and the corresponding matching rules already exist for normal (non-ITD) pointcuts, so maybe just the parser needs to be extended and of course ITD generation itself (the process of actually adding the same members, methods or constructors to a set of target classes instead of a to single one) as well. Kind regards -- Alexander Kriegisch https://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://www.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://www.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://www.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://www.eclipse.org/mailman/listinfo/aspectj-users
