Hi all, Andy
We finally got the time to fix aspectj so it can be relocated by gradle
shadow plugin.
Manfred.d has fixed it in a fork in github and will open a pull request:
https://github.com/mduchrow/org.aspectj/tree/V1_9_1_relocatable
mainly the fixes are code lines that test for the first char of the
org.aspectj.. packages.
for example:
if (annotationSig.charAt(1) == 'o')
or
if (name.charAt(0) != 'a' && type.charAt(0) != 'o')
or
typename.charAt(0) == 'o'
and code like this,the (I), prevents the gradle shadow plugin from changing
the package name
"(I)Lorg/aspectj/lang/ProceedingJoinPoint;"
the fork fixes all these issues , we hope that we've pinned down all
necessary code lines.
we've tested that in our project and it works fine.
What do you guys think?
Thank you
Shalom
On Wed, Jan 3, 2018 at 10:06 PM Andy Clement <andrew.clem...@gmail.com>
wrote:
> That’s an interesting requirement. I don’t know of others doing that but
> it isn’t totally unreasonable. I’ve normally used jarjar to move packages,
> I wonder if there is a variant of that tool which also allows string
> replacement. It seems reasonably robust to modify Lorg/aspectj/lang
> prefixed strings to Lshadow/org/aspectj/lang in addition to moving the
> packages. That would probably get you a long way, and if there were any
> remaining issues we could modify aspectj to make it behave.
>
> In the back of my mind I am concerned about code that is affected by
> differently packaged weavers and them maybe tripping each other up, but
> right now I can’t think of concrete situations that will fail.
>
> Andy
>
> On Dec 26, 2017, at 5:23 AM, Shalom Ben-Zvii Kazaz <shalom...@gmail.com>
> wrote:
>
> Hi All
> We are developing a kind of jvm profiler and we want to use aspectj load
> time weaving.
> we're going to use this tool for various application which we know nothing
> about in advance. and we suspect that some of them are already using
> aspectj in some way.
> We use gradle to package our tool and wanted to relocate the aspectj
> classes but it looks impossible.
> I think its because aspectjweaver uses string constants to test if a class
> is an aspect, something like that:
>
> public final static UnresolvedType ASPECT_ANNOTATION =
> UnresolvedType.forSignature("Lorg/aspectj/lang/annotation/Aspect;"
>
>
> and when relocating the project dependencies our aspects doesn't import
> or.aspectj.. anymore but shadow.org.aspectj.. and so the weaver complains
> that the class is not an aspect and does not register our aspects.
> i tried various ways to solve it like excluding some classes or all the
> org.aspectj.lang package but nothing worked.
> I did try stackoverflow but didn't get any good help there.
> would appreciate if someone can help suggesting what we could do. of
> course i could use pure asm to do that or bytebuddy but i find aspectj the
> best for our needs.
>
> Thank you
>
> Shalom
>
> _______________________________________________
> 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
_______________________________________________
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
