Community
Participate
Working Groups
This is the AJDT side of bug 268827. In the past, there has been a refresh of the project after a build. This refresh could take significant amount of time. Andy and I have worked things so that this refresh is no longer necessary. Here is what is happening: CoreOutputLocationManager now has two call back methods: reportClassFileWrite and reportClassFileDelete. When called, these classes refresh the file that was created or deleted. Also, AJBuilder is much more careful now to ensure that any resource it copies to or deletes from the output folders are refreshed as well. Because of this, all refreshing is happening on exactly the files that get altered because of the build (nothing more, nothing less). And therefore, no refresh after build is necessary. This is likely to provide significant build time improvements for AJ projects that have Java projects depending on them. I am committing two sets of tests for this: RefreshTests and RefreshTestsImprecise. The first set of tests tests to ensure that only the files that are changed/added/removed before the build have their corresponding build artifacts refreshed. The second set of tests test that *at least* these build artifcts are refreshed (but there might be more. Due to bug 269576 and bug 269562 RefreshTests are failing. When these bugs are resolved and fixed, I will re-enable RefreshTests (and possibly remove RefreshTestsImprecise).
Committed.
Not exactly done yet. I also have to refresh the outjar and the inpath out jar if they exist.
Hmmm...I wonder if notification for outjar and inpath outjar is better as a callback from the compiler. The compiler will choose whether or not to delete or update these jars. Also, it will have easy knowledge of whether or not the jar has changed and the original needs to be deleted. Furthermore, the aj compiler may create some extra files (such as resources if there is a drop to a full build). This leads me in the direction of suggesting that the compiler should call back on every file write and delete. Perhaps, it is reasonable to simply change the names of "reportClassFileWrite" and reportClassFileDelete in OutputLocationManager to reportFileWrite and reportFileDelete. The logic would be the same for AJDT's point of view (they should be refreshed and marked as derived). The nice thing about this is that if in the future, AspectJ creates some new kinds of files, they will automatically be refreshed and marked as derived for AJDT (as long as the callback is used). The only difficulty that I can foresee is that AspectJ may not have access to the OutputLocationManager at all points in the compilation process.
Yes, I can see the value in a mechanism to tell AJDT about different kinds of things beyond class files. But we dont support incremental builds when using outjar so doing an unnecessary refresh of that jar won't really affect performance today. AspectJ always rebuilds everything and reconstructs the jar from scratch on every build. But I could add the bit about calling back for resources in the case of a full build. I'd rather continue to distinguish class files from other things, but the kind can be an extra param on the callback perhaps.
...is this the same as bug 269017
although we definetly shouldn't be doing incremental builds for straight outjar (by design), I honestly don't know what happens for inpath outjar and if that is undefined we ought to fix it to be the same as outjar whilst outjar is not incremental.
(In reply to comment #6) Are there any refresh improvements available in the current dev build? I would like to try them out. Thanks, Thomas
(In reply to comment #7) > Are there any refresh improvements available in the current dev build? I would > like to try them out. No. The changes I put in broke some other tests. I will let you know when the build becomes available.
The work for this has been completed and is available from the dev update site. Please let me know if this helps your build times.
*** Bug 269017 has been marked as a duplicate of this bug. ***
