Since I typed the original mail on my phone here is the
corrected / spelled checked version sorry for the noise but I don’t want
to confuse anyone…
Hi,
We develop an RCP app with a whole bunch of plug-ins and we use compile time
weaving for everything. We have different plug-ins that belong to our
"framework" that provide functionality for the others to use. Some of
these bundles provide aspects (in .aj files) that must apply to bundles that
make use of the framework.
For this to work both the framework and the other bundles have the aspect
nature applied. Then the "client" bundle (the one using the framework
bundle) is setup to have the framework bundle that includes the aspect that
needs to apply on its aspect path (this is a project level setting).
Depending on the definition of the pointcuts the code in the client bundle will
be adviced.
It's really simple but be aware that initial compile time for the workspace
might increase.
We also deploy using Webstart. Once the weaving has been done during compile
time you just need to make sure the aspect runtime is available as a bundle to
all bundles containing adviced code.
The client bundle must also depend on the framework bundle so that the aspect
itself can be found at runtime.
Thomas
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Thomas Hofmann
Sent: Mittwoch, 7. Juli 2010 10:07
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Question about Compile Time Weaving, OSGI, Java
Web Start, and code duplication
Reposting this to the mailing list…
From: Thomas Hofmann
Sent: Dienstag, 6. Juli 2010 15:10
To: daniel.kashtan@xxxxxxx
Subject: Antw.: [aspectj-users] Question about Compile Time Weaving,
OSGI, Java Web Start, and code duplication
Hi,
We develop an rcp app with a wohle bunch ig plug-ins and we use compile time
weaving for everything. We have different plug-insurance that belong to our
"framework" that provide functionality for the others to use. Some of
these bundles provide aspects (in .sh files) that must apply to bundles that
make use of the framework.
For this to work both the framework and the other bundles have the aspect
nature applied. Then the "client" bundle (the one using the framework
bundle) is setup to have the framework bundle that includes the aspect that
needs to apply on its aspect path (this is a project level setting).
Depending on the definition of the printouts the code in the client bundle will
be advice.
It's really simple but be aware that initial compile time for the workdpace
might increase.
We also deploy using Webster. Once the weaving has been done during compile
time you just need to make sure the aspect runtime is available as a bundle to
all bundles containing adviced code.
The client bundle must also depend on the framework bundle so that the aspect
itself can be found at runtime.
Thomas
Compile-time-weaving should
be good enough. What I am working on is mostly a self-contained RCP. You
stated that, "I think you need to create the dependencies between your
bundles in the right way and tell the AspectJ compiler to use the aspects from
another project to weave them into some other projects."
Is there any documentation out there on this? Has anybody done it before? Let
me know if so, I am clueless on how to do this and I cannot find any
documentation on it :(
________________________________________
From: aspectj-users-bounces@xxxxxxxxxxx [aspectj-users-bounces@xxxxxxxxxxx] On
Behalf Of Martin Lippert [lippert@xxxxxxx]
Sent: Saturday, July 03, 2010 2:59 AM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Question about Compile Time Weaving, OSGI,
Java Web Start, and code duplication
Hi Daniel,
I haven't tried this myself, but you should be able to use compile time
weaving for aspects within an OSGi world. I think you need to create the
dependencies between your bundles in the right way and tell the AspectJ
compiler to use the aspects from another project to weave them into some
other projects.
The difference to load time weaving is: using compile time weaving you
need to hard-weave your aspects into your OSGi bundles. This means your
aspects can only affect classes from other bundles that you are aware of
at compile time. This might not always be the case for OSGi since new
bundles from other parties are coming and going.
For example: if your aspect should weave into some existing Eclipse SDK
bundles that people have installed on their machines, compile time
weaving might be somewhat complicated (you would to recompile those
bundles and put them into a fragment for the SDK bundles). If your
aspects should also weave against new bundles that people might install
in the future, compile time weaving is also not really usable.
If you implement a self-contained rich client platform and you (or your
team) are the only people defining what gets installed in that OSGi
runtime, compile time weaving is an option, I think.
Just a few thoughts,
-Martin
On 02.07.10 15:17, Kashtan, Daniel wrote:
> Hey all,
>
> I am currently developing an OSGI project that makes use of AspectJ. I am
using Java Web Start too which means that I cannot use Load Time Weaving. With
Compile Time Weaving, it appears that I will need *.aj files for every bundle,
and that I have to duplicate code if I want the same aspect to affect java
classes in different bundles. Am I wrong about this? I am not sure if I am
misinterpreting what Equinox Aspects is saying about Compile Time Weaving, or
if I am not taking advantage of OSGI enough to be able to use aspects in multiple
bundles. Let me know if I made my problem clear and if I have any way around
duplicating aspect code.
>
> This e-mail and any files transmitted with it may be proprietary and are
intended solely for the use of the individual or entity to whom they are addressed.
If you have received this e-mail in error please notify the sender.
> Please note that any views or opinions presented in this e-mail are solely
those of the author and do not necessarily represent those of ITT Corporation.
The recipient should check this e-mail and any attachments for the presence of
viruses. ITT accepts no liability for any damage caused by any virus
transmitted by this e-mail.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
