Community
Participate
Working Groups
The autobuild feature is critical for people accustomed to using the JDT. Supporting <ctrl>b build invocation is another compatiblity requirement.
Here are my comments from the AspectJ mailing list: -------------------------------------------------- Wes Isberg wrote: > Right now, if an aspect changes, then the entire project is > recompiled. Would you want build-on-save in that situation? > > Wes In my project, I only have a couple of aspects and they hardly ever change, so that would be fine with me. Even if it did a full build on EVERY save (even plain Java classes), that would be better than nothing, especially on a small project or fast machine. Incremental compile seems to be working OK now (in Eclipse). Are incremental compile and autobuild for some reason incompatible? ------------------------------------------- Thanks, Chad Woolley
I wanted to paste in some definitions from Eclipse help, so that if nothing else, I know what behaviour I'm trying to implement/fix with this bug: Auto-build vs. Manual Build --------------------------- There are two distinct user work modes with respect to building: relying on Auto-build, or user initiated manual building. Users who do not need fine-grained control over when builds occur may simply choose to turn on auto-building. With auto-building on, builds occur after every set of resource changes (e.g., saving a file, importing a zip, ...). Auto-building is efficient because the amount of work done is proportional to the amount of change done. The benefit of auto-building is that your derived resources (e.g., Java .class files) are always up to date. Auto-building is turned on/off via the Perform build automatically on resource modification option on the Window > Preferences > Workbench page. Users needing more control over when builds occur can turn off auto-building and manually invoke builds. This is sometimes desirable in cases where for example you know building is of no value until you finish a large set of changes. In this case there is no benefit to paying the cost of auto-building. Builds can be invoked manually in numerous ways, for example by selecting Rebuild All from a project's context menu. The disadvantage of manual building is that the tasks which where generated to indicate build errors quickly become out of date until you build. In addition, it is very important that you remember to manually build before relying on build output (e.g. before running your Java program). Full vs. Incremental Builds --------------------------- There are two kinds of builds: full and incremental. An incremental build works with a previous built state and applies the transforms of the configured builders only on the resources which have changed since that previous state was computed (i.e., since the last build). Auto-building uses incremental building for efficiency. A full build (a.k.a. rebuild) discards any existing built state and transforms all requested resources according the domain rules of the configured builders. The first incremental build is equivalent to a full build as there is no previous state to work from. Depending on the user's needs, full and incremental builds can be done over a specific set of projects or the workspace as a whole. Specific files and folders cannot be built. --------------------------------------------------------------- Ctrl+B is the shortcut for build all and we have fixed a bug to do with build all very recently. I'll first check if its affected what happens with CtrlB...
There are 3 mechanisms affecting whats happening here: 1) Under the workbench preferences for AspectJ, we have the option 'Suppress automatic builds for AspectJ projects' 2) Under the Workbench tab in workbench preferences, we have: 'Perform build automatically on resource modification' 3) Under project properties, AspectJ tab, we have: 'Use incremental compilation' I think options (1) and (2) are interfering. Right now, I'm thinking we should remove option (1) and defer to option (2) if users wanted to turn off auto building. So, from some rudimentary testing, there is a workaround to get CtrlB to work. Firstly, uncheck option (1), then uncheck option (2). This means you can make modifications and do a save through CtrlS - then tap CtrlB to drive a build. However, there is a bug in the codebase, related to auto-build. It isnt currently possible to have AUTOBUILD on *without* INCREMENTAL on. I've now fixed this. So you can have autobuild on, and if you arent building incrementally then it will do a full build. (Although I found I had to Ctrl+S twice to drive a build that updated the structure model and outline view/editor?)
Fix is in the codebase. I have removed the 'suppress' option from the AspectJ preferences page. *This changes the default behaviour when you install AJDT* - since by default we *will* be doing autobuilds (full autobuilds since incremental still defaults to off) on resource modifications. If you want to turn off autobuilds then you need to change the global workbench preference for building on resource saving. I have to do it this way so that Ctrl+B does a full build. The Autobuild behaviour appears to be: After making an edit and saving, the eclipse workbench calls the builders to build, after they are finished it marks the projects as all being up to date, regardless of how those builders returned. If someone subsequently presses CtrlB without making a further edit, then dont build anything. The reason this fails for us at the moment is that although the eclipse workbench calls us to build, we check the 'suppress autobuild' AJDT flag *in the builder code* and if it is on we return immediately (without building anything) - eclipse doesnt know that we didnt do our 'build' in this case and so assumes the workspace is all up to date. So, then pressing CtrlB does nothing... Hope I am making any sense here? I know what I mean :) Anyway, it should be working properly now. I wonder if turning off 'build on resource modification' should be one of the options that appears on the wizard page that sets AJDT preferences like 'make aspectj editor the default' ...
fixed.
