I believe Tahir had already tried iajc. An alternative approach would be to surround your ajc invocation with two jar operations - one to pull the classes of interest out of the jar, then target them with ajc, then the second jar command to put it back together.
I don't mind accepting a patch for changing the operation of AspectJ to allow for the kind of processing you want to do - but if you raise it as an enhancement I'm not sure it'll get done for 1.6.6. I suppose there could be some smarts in comparing the date stamps of jar entries from in-to-out and know whether types need weaving. I wouldn't make it the default mode but for certain situations I can see it making sense. cheers, Andy. 2009/7/1 Andrew Eisenberg <[email protected]> > OK. So, the problem has to do with incremental compilation (or incremental > re-weaving). I'm fairly certain that when using ant, all classes are > rebuilt all the time. > > However, there is an interactive mode for using the iajc ant task ('i' > stands for interactive). Look at the docs for the ant task: > > http://www.eclipse.org/aspectj/doc/released/devguide/antTasks-iajc.html#antTasks-iajc-options > > This might help you. > > > > > On Wed, Jul 1, 2009 at 1:29 AM, Tahir Akhtar <[email protected]>wrote: > >> Thanks Andrew. >> >> Here is some more details about what I am trying to do and may be you can >> suggest a better alternative. >> >> I have some aspects with very simple pointcut that pick exception handler >> execution. >> This aspect will only be used in development, and will not be deployed in >> production. >> >> We have a large team of developers working on a code base having around >> 3500 class files. >> Weaving all these classes, when a single file changes on the developer >> machines will add too much delay to the build cycle. >> So I was looking for a way to weave only those class files that were >> re-compiled by ant-javac. >> This will greatly increase the build speed for average case where >> developer only changes few files, compiles, test and repeats the cycle. >> >> Regards >> Tahir Akhtar >> Andrew Eisenberg wrote: >> >> Yes, this is because the inpath argument will take all files located at a >> particular source root, run them through the weaver, and spit the results >> out at a different location. It doesn't make sense to do this to only a >> subset of files at a location. >> >> Rather than trying to fiddle with the inpath argument, a better approach >> would be to tailor your aspects so that they only touch the subset of files >> that you are interested in (eg- using the within(<type_pattern>) pointcut. >> >> On Tue, Jun 30, 2009 at 5:06 AM, Tahir Akhtar >> <[email protected]>wrote: >> >>> Hi, >>> I am integrating aspectj compile-time-weaving in an existing ant-based >>> build. >>> >>> I tried limiting <inpath> with ant's fileset combined with a <modified> >>> selector. But its not working. It appears inpath only supports simple >>> <path>s. >>> >>> Is there a way to achieve this? >>> >>> Regards >>> Tahir Akhtar >>> >>> >>> _______________________________________________ >>> aspectj-users mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>> >>> >> ------------------------------ >> >> _______________________________________________ >> aspectj-users mailing >> [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
