Community
Participate
Working Groups
Currently AjState objects that capture the incremental build status of a project are not persisted to disk in between workbench restarts - forcing a full build of all AJ projects on restart. We should persist them, in a similar way to how State objects are persisted for Java projects.
This is proving extremely complex to implement. The post build state is absolutely *not* suited for persistence. And besides the AjState object (which manages dependencies), there is the structure model and the world to consider. The final of these not only encapsulates resolved type information but also crosscutting information gathered from compiled aspects.
*** Bug 287338 has been marked as a duplicate of this bug. ***
Going to attack the problem in a better way. We will need to plugin to eclipse shutting down and have a save participant calling out to AJ to persist state for each project. Reloading the state would be done in IncrementalStateManager.retrieveStateFor() which is called from AjdeCoreBuildManager.performBuild(boolean fullBuild). The first build after a startup does pass in false for 'fullBuild' but right now as no state is found, the flag is flipped to true and a full build commences. For initial testing I just constantly persist (no need to plug into the lifecycle). it will be best to avoid making everything persistable and instead make the larger data structures recoverable. For example all the complex state in a CrosscuttingMembersSet object can be rebuilt from the aspects, and the aspects should be recoverable from the bytes created last time they were built.
Progressing slowly. In order to recover the weaver we are creating a new weaver object and bringing the aspects back into it by loading the bytecode for them from the bin folder (we persisted the names of the aspects). Unfortunately there are codepaths triggered that we'd rather avoid when bringing aspects back in like this: a) some error checking is done during loading of the aspects. These errors look out of place. They are basically duplicate errors for entries we already have in the problems view. b) Some xlint processing doesnt work. The xlint 'adviceDidNotMatch' is implemented by the advice structure setting a flag when it has been woven somewhere. This flag shouldn't really persist in the aspect as it only reflects the status on one particular invocation of the weaver. The trouble is that because it isn't persisted, when we bring the weaver back into the system on restart and do a simple incremental build of the aspect (for example), the xlint fires because the advice looks like it didn't match anything.
Hi Andy, I just wanted to add that I'm glad you are working on this now.
unsetting the target field which is currently set for something already released
