Community
Participate
Working Groups
Our incremental compilation support ignores changes to resources, and worse keeps binary copies of every resource it has ever seen in memory in bcelWeaver. resources.
New implementation handles resources in AjBuildManager, keeping list of resource file names only (not content) in AjState. Correctly handles resources additions, deletions and updates from inpath directories. If resources in an injar are changed, the change of the jar itself will trigger a full build so incremental treatment of resources in jars is not required. I'm leaving this bug open for now, despite checking in the working code, because I've been unable to write any satisfactory tests that exercise this function (I tested it with an incremental loop started in eclipse, and then manipulated resources by hand, pressing enter for a new incremental compile after each change). I'm checking in an extension to the test harness that supports staged copying of .class, .jar, .properties, and .xml files in addition to .java files (with tags etc.), but there are timing issues to do with the incremental compiler thread that escaped my limited knowledge of the harness. Perhaps Wes & I can work through this at AOSD next week. Here's an example of the kind of test-spec I was trying to write: <ajc-test dir="incremental/resources/add" title="expect resource added in initial incremental tests" keywords="incremental-test" > <compile staging="true" files="." options="-incremental" sourceroots="."/> <run class="SomeClass"/> <inc-compile tag="20" > <!-- do I need a dir-changes entry here for a resource file?? --> </inc-compile> <run class="SomeClass" skipTester="true"/> </ajc-test> Note that I need to put a directory into the files specification to pass in an inpath dir (containing the resources to be copied). I then have some properties files (foo.properties, which should be copied on the first iteration, and bar. 20.properties, which should be copied on the second iteration). I step through in the debugger and see that foo.properties at least is output into the sandbox. classesDir, but the run command seems to get there ahead of the copy (race condition?) and so the execution of SomeClass fails with a missing resource bundle. It's not quite right though since the inpath dir itself also needs to be staged somehow (bar.20.properties is visible on the first run, with the 20 in the filename still). Needs more design thought on my part, and a greater understanding of the existing test harness implementation...
We can talk next week. It's good you got this far. I seem to recall adding a delay after the last .java file copied last-mod-time because it's possible to compile and copy resources within the minimal time (1 ms?) recognized by the filesystem, which would cause the updated resources to not be recognized as such.
included in 1.2 release
Tests now committed to source tree and passing... Found and fixed one bug in the process - when removing either a class file or a resource from an in-jar, the corresponding element was not deleted from the output directory.
Fix released as part of AspectJ 1.2.1
