Summary: | [build] Remove project refresh after build | ||
---|---|---|---|
Product: | [Tools] AJDT | Reporter: | Andrew Eisenberg <andrew.eisenberg> |
Component: | Core | Assignee: | AJDT-inbox <AJDT-inbox> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | aclement, email |
Version: | unspecified | ||
Target Milestone: | 2.0.0 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 268827 |
Description
Andrew Eisenberg
2009-03-21 23:39:28 EDT
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. *** |