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: [email protected] [mailto:[email protected]] On Behalf Of Thomas Hofmann Sent: Mittwoch, 7. Juli 2010 10:07 To: [email protected] 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: [email protected] 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 ----- Reply message ----- Von: "Kashtan, Daniel" <[email protected]> Datum: Di., Jul. 6, 2010 14:45 Betreff: [aspectj-users] Question about Compile Time Weaving, OSGI, Java Web Start, and code duplication An: "[email protected]" <[email protected]> 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: [email protected] [[email protected]] On Behalf Of Martin Lippert [[email protected]] Sent: Saturday, July 03, 2010 2:59 AM To: [email protected] 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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
