Community
Participate
Working Groups
I have a number of Ant builders configured to be invoked on "After a Clean" builds, on manual builds, and on auto builds. They used to work fine with previous versions of Eclipse (not sure though what was the latest version that I tried), but with Eclipse 3.1M5a "After a Clean" option does not work. Example 1: I have a builder that deletes all files/folders from some area. It does not have any resources associated with it because the sole purpose of that builder is to perform some clean-up. It is configured to be invoked after clean (Project -> Properties -> <my builder> -> Edit… -> Targets -> After a “Clean”), but in such configuration it is never invoked. If I change configuration to invoke it during a clean, then it is invoked just fine. Example 2: I have a builder that creates a JAR file from the associated resource set and copies it to some folder. It is works just fine on manual and auto builds, but is not invoked on “After a Clean” build. The only way I managed it to be invoked on “After a Clean” build was: - Uncheck auto build option for a project. - Modify a file from associated resource set. - Clean up the project. In this case my builder is invoked, but in all others it is not (and fact that resource set is not dirty should not prevent it from being invoked on “After a Clean” build).
This is what I see: If "build automatically" is turned on and a clean is performed, the build that occurs after the clean is not indicated as an "after a clean" build but rather as an "autobuild" build. If "build automatically" is turned off and a clean is performed with "Start a build immediately" from the Clean dialog, then the build that occurs after the clean is indicated to be an "after a clean" build. CC John for comment. It appears to me that the external tool builders are correctly responding to the triggers but the triggers may not be what the users expect.
Remind me why we allow configuration of the targets for "after a clean" in addition to "during a clean"? I recall we did this because we took away the UI for invoking a full build in 3.0, and "after a clean" was the new name for "full build" on this page. However, now that we allow configuration of the target for clean, the option for "after a clean" seems redundant. Perhaps this should just be removed, leaving only "clean", "manual build", and "auto build"?
I will investigate why the behaviour is different when autobuild is on.
This is caused by a problem in the platform builder infrastructure. To support the "after a clean" case, we currently munge the build trigger as follows: int trigger = .... original build trigger if (trigger != CLEAN_BUILD && builder.lastBuildTree() == null) trigger = FULL_BUILD; I.e., after a clean, the builder's "tree state" will be null because it is discarded by the clean build. When this happens we slam the build trigger to be a full build. The problem is that we currently do this munging *after* checking if the build command responds to the given trigger. Thus the ant builder is never run, because it only responds to FULL_BUILD, but at the time we do the check, we haven't yet changed the trigger. I could move the trigger munging to be done before checking if the command responds to the trigger, but that requires instantiating the builder. That would result in builders being instantiated for no reason if the trigger filtering decided that no build was necessary. In short, supporting the "after a build" trigger (aka full build) was a bit of a hack to begin with, and is now causing more problems (see also bug 71408). Darin, can you give some more thought to whether "after a clean" and "during a clean" are both still needed? Vlad, feel free to comment if you have cases where this is important - i.e., does everything work if you just move your "after a clean" targets to the "during a clean" section? It seems like it would simply the user experience to just have "clean", "manual build", and "auto build" trigger options.
Created attachment 18708 [details] Patch to BuildManager.java If we decide it is necessary, this patch fixes the reported bug, but has the sideeffect that builders will be instantiated even if they do not respond to the specified build trigger.
Thanks John. I will post a comment in bug 63685 and the platform ant mailing list to get more community feedback. If we reduce the set to Clean, Manual, Auto: The user turns off auto build The user initiates a clean which is set to cause a build immediately Then the builders that are set to manual must also be set to respond to full to get the build for this case. Likely what the user expects and I agree it is less confusing and more consistent with commandline building
I do not think that "after a clean" option is redundant (though I do not know implementation details). Here are my observations: My builder from example 1 works just fine if I invoke it on a clean instead of after a clean. But it is very special type of builder, it only performs some clean-up and has no recourse set associated with it, therefore during a clean is actually even more logical choice for that builder than after a clean. Builder from example 2 (the one that builds JAR file from some resource set), if invoked during a clean builds an empty JAR file (because classes that are supposed to be there are not compiled yet by default Java builder). Note that eventually result is the desired one, because that builder is also invoked after Java builder compiles all classes (not sure what triggers that, probably the fact that it is also set to be built on auto and on manual builds). So, the summary is that builder is invoked twice, once with not desired result (empty JAR file), and finally with desired one (correct JAR file). Though it can work as a workaround, not sure that it is a real solution to that issue.
Thanks Vlad. For you builder 2 case. If we changed the implementation so that a builder set to occur on a manual build was executed after a clean occurred (when auto build was off) it appears to me this is the behavior you desire?
Sorry you kind of lost me here - I'm not sure whether to answer yes or no on your question... The desire is that builder should be invoked in 3 cases: 1) On auto build (only if associated resource set is dirty) 2) On manual build (only if associated resource set is dirty) Those 2 works fine now. 3) On full build (when whole project is rebuilt). Logically full build sounds to be "after a clean", but name is not important, what important is that the builder should be invoked after the default Java Builder done with rebuilding a project. Techincally it might be invoked that way now when using "during a clean" option, but, apparently, default Java Builder is configured to run in the background (which as I understand corresponds to be launched in a separate thread), and I did not find a way neither to change it, or to configure my builder to depend on completion of default Java Builder, that's why I'm getting that empty JAR file built first time when my builder is invoked. So what I really need is a way to invoke my builder after default Java Builder is done with its job.
Darin, did you get any other feedback on the proposed change described in bug 63685 comment 20? Building after a clean is currently still broken so we'll need to resolve this either way soon. Either we remove the "after a clean" target, or I will need to release my patch from comment #5. I'm marking this for M7 so I remember that this needs to be resolved.
Unfortunately the community was silent...
Silence means approval, right? <g>
As long as we do not loose previously existed functionality (ability to invoke custom builder on a full build without dependencies on resource set changes). Please keep in mind that with current implementation of “During a clean” I do not see a clear way to make builder invoked on a full build (which actually occurs after a clean) – see my comment #9. Please correct me if I am wrong.
Fix released. I now eagerly instantiate the builder and then check if it matches the active triggers after doing the munging to handle "after a build". This means some builders will be instantiated when they didn't need to, but it does mean that builders will now run when they are supposed to.
Good news for me...means I don't have to make any changes :-) Thanks.
Well, as Vlad points out in comment #9, "during a clean" and "after a clean" are not equivalent. If you want an external builder to run after the Java builder has done a full build, you can't hook "during a clean".
In Ant land doing a clean simply means removing the build artifacts. "during a clean" and "after a clean" in my opinion should be two separate stages that are not equivalent. So expecting "during a clean" to be triggered for "after a clean" (full build of builders) does not add up for me. To get an external tool builder to run after a clean and after the Java builder one would configure your external tool builder target(s) for "after a clean" and set the builder to be ordered after the Java builder.
