Thanks for your answer. Just for curiosity, why is the aspectjrt.jar needed in runtime when performing compile-time weaving? Shouldn't it be possible to perform some post-compilation step in Eclipse where the aspectj compiler statically modifies the byte-code produced by Eclipse when exporting the plugin? This way you would have no dependency to aspectj what so ever. I'm sure that there's a very good reason though :).
When you say that I should turn off Build Automatically for my project, do you mean that I have to turn off the Eclipse compilation as well? There's no way to just turn off automatic aspectj weaving for a certain project? I think I've run into the problem that you're describing and it's quite time consuming have to wait for the weaving process so often. On Nov 28, 2007 9:47 AM, Andy Clement <[EMAIL PROTECTED]> wrote: > hi John, > > I can comment on a couple of things - I don't do much plugin > development myself at the moment so will leave others to comment on > the first problem. > > On 28/11/2007, Johan Haleby <[EMAIL PROTECTED]> wrote: > > I have a feature which includes a lot of Eclipse plugins that I want to > > export, some of which are aspectj projects. I have declared the aspects > in > > two separate Eclipse plugins/bundles. In one particular case I have an > > AspectJ project that contains a single abstract aspect and I'm creating > the > > concrete implementation in subclass in another AspectJ project. It is > this > > aspect that I want to be woven into two of my other Eclipse projects. > I've > > aspectj enabled these two projects as well and the bin folders of both > the > > abstract and concrete aspect are added to the inpath of these projects. > This > > works fine in my Eclipse development environment, but when I'm exporting > the > > project and want to run it in a clean Eclipse installation the two > aspectj > > plugin projects does not show up under "About Eclipse SDK Plugins" and > my > > project doesn't seem to work. I've tried creating and exporting a > feature > > and I've tried the "Export deployable plug-ins and fragments with > AspectJ > > support" option but it doesn't seem to work. Does anyone have any ideas? > I'm > > using Eclipse 3.2 and AJDT 1.4.2. > > > Another (possibly stupid) question that I have is regarding the > > org.aspectj.runtime dependency that are added to the AspectJified > projects. > > Does this mean that my target Eclipse version need to install AJDT as > well?! > > Why should this be needed if I use compile-time weaving? As I understand > it > > my Eclipse plugin should not have to be dependent on AspectJ when > deployed > > if using compile-time weaving since this only changes the byte-code. Or > am I > > missing something trivial? > > If doing compile time weaving, the woven code produced will have a > dependency on the small runtime library aspectjrt.jar - this is > packaged inside the org.aspectj.runtime plugin. The choices would be > to put the runtime jar directly in the plugins that have been woven, > or ensure the target environment has the org.aspectj.runtime plugin - > this wouldn't need a full AJDT install as the runtime plugin is a > small fraction of AJDT. I'm not sure how the export-plugin-with-aj > support does it - whether its the first option or the second. > > > A third question that I have is if you can disable to automatic weaving > > performed by AspectJ in my development Eclipse platform? Right now every > > time I hit ctrl+s aspectj weaves basically all my plugins which takes a > lot > > of time if you're just making really small changes. > > You can turn off Build Automatically for your project. The problems > with incremental compilation exist when you have a mixture of projects > in the workspace - some AJ and some Java, and there are dependencies > amongst them. If they are all aspectj or all java then it will behave > much better. If they are all AJ then a tiny change in a file will be > compiled/woven quickly (sub-second). The project state for a Java > project is a bit of a black box to us in AJ land so we haven't yet > done the necessary to open it up and examine it - which will enable > AspectJ to be more intelligent in terms of incremental compiles. > > Andy > _______________________________________________ > 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
