Community
Participate
Working Groups
Build ID: Eclipse 4.2.1 Juno When "Build Automatically" is turned OFF in a workspace, the "Clean..." dialog allows to choose whether the cleaned projects should be re-built automatically after cleaning or not. The dialog should also offer the "re-build or not" option when autobuild is ON. This feature is sometimes important, eg with very large projects which I want to build on demand only or when re-configuring multiple aspects of a project. So wWhen I have both C/C++ and Java projects in a workspace, I want to turn autobuild ON but still have the option to keep projects cleaned on clean. It's especially important when the workspace includes projects that have a builder which doesn't participate in AUTOBUILD requests as per the builders extension point and the ICommand#setBuild() API.
Makes sense. The dialog was designed at a time when we never presented the option to build when autobuild was enabled. The only potential confusion is that when autobuild is on, and they uncheck the box to kick off a build, they may be surprised that it does in fact build anyway due to autobuild. The wording might need to be updated to indicate that it is refer to manual build and does not effect whether or not autobuild will run.
(In reply to comment #1) > that when autobuild is on, and they uncheck the box to kick off a build, > they may be surprised that it does in fact build anyway due to autobuild. Yes, I had thought about this, and I see 2 options to address this: Option A: ========= When rebuild checkbox is OFF, do not fire any autobuild events as part of the clean operation. As a result, respective projects are not going to be built at all. I don't know whether suppressing those autobuild events is easily possible. Option B: ========= Add a bit of intelligence to the dialog which makes the rebuild checkbox "on but disabled" in case the list of projects requested to clean are all known to listen to autobuild events. Enable the checkbox only when there is at least one project requested to clean, which is known to have a builder that is configured to not listen to autobuild events as per the org.eclipse.ui.builders extension point and the ICommand#setBuilding() API, see http://help.eclipse.org/juno/topic/org.eclipse.platform.doc.isv/guide/resAdv_builders.htm Option A gives more control to the user, so it would be my favorite. One usage scenario where this is interesting even with JDT is when I want to "export" a project source for archiving, CM checkin or team-sharing. I'd clean all build artifacts (and NOT rebuild) before exporting it.
I want to avoid the state where I can clean and not build a project that is auto-built. The mentioned JDT case sounds wrong and should not be handled by the user but by the exporter itself who can disables auto-build, clean, export and then re-enable auto-build again. I'd vote for option B but even going further and not display the controls when all projects support auto-build. That way, the UI wouldn't change for users that only work with auto-built projects.
(In reply to comment #3) > auto-built. The mentioned JDT case sounds wrong and should not be handled by > the user but by the exporter itself who can disables auto-build, clean, > export and then re-enable auto-build again. That sounds wrong to me since some people will want to export the generated artifacts, whereas others do not. Today, the workaround is unchecking the folders that contain build artifacts in the export dialog. But this is a bit cumbersome, and sometimes I won't know where build artifacts reside (especially when multiple builders are involved; consider Modeling, Xtext etc). To me, invoking the "Clean" action means I want to clean it, and giving me the option of re-building it immediately or not is the most obvious and intuitive solution. I have to admit, that with Autobuild on it's a bit odd that the next "file save" operation that triggers an autobuild will really trigger a full build after that; on the other hand that's what I had requested in the UI.
(In reply to comment #4) > (In reply to comment #3) > > auto-built. The mentioned JDT case sounds wrong and should not be handled by > > the user but by the exporter itself who can disables auto-build, clean, > > export and then re-enable auto-build again. > > That sounds wrong to me since some people will want to export the generated > artifacts, whereas others do not. Sounds like a checkbox in the dialog ;-). > To me, invoking the "Clean" action means I want to clean it, and giving me > the option of re-building it immediately or not is the most obvious and > intuitive solution. Yes, but not if the project is auto-built. It would be just plain wrong to have such a project not being built while auto-build is enabled. How would I know in two days which of those aren't built yet?
(In reply to comment #5) > Yes, but not if the project is auto-built. It would be just plain wrong to > have such a project not being built while auto-build is enabled. I think there is a slight misconception here between "build automatically (on change)" and "always keep built". I guess you've been longer around at Eclipse so you might know better than I what the original intent of the option was. You seem to be requesting "always keep built". But the way the option is named right now, and the way I understand it, it's about building automatically on change or when needed. This is IMO not at odds with cleaning a workspace on demand (and keeping it cleaned until the next change, launch or build request due to dependencies). > How would I know in two days which of those aren't built yet? Why would you care ? The workspace will build automatically on any change (like a save operation) or any action that requires a built workspace (like launch). After all you requested a manual clean without rebuild for a reason. Note that not rebuilding is not the default behavior; I'm just requesting the option to do so for situations where I want exactly that. I do think I'll remember what I have done in this case.
(In reply to comment #6) > (In reply to comment #5) > > Yes, but not if the project is auto-built. It would be just plain wrong to > > have such a project not being built while auto-build is enabled. > > I think there is a slight misconception here between "build automatically > (on change)" and "always keep built". > I guess you've been longer around at Eclipse so you might know better than I > what the original intent of the option was. You seem to be requesting > "always keep built". Correct. When this option is on and no job is running, then I expect that my workspace is built. The Problems view shows all problems and I can launch without triggering the builder/compiler. > > But the way the option is named right now, and the way I understand it, it's > about building automatically on change or when needed. This is IMO not at > odds with cleaning a workspace on demand (and keeping it cleaned until the > next change, launch or build request due to dependencies). > > > How would I know in two days which of those aren't built yet? > > Why would you care ? The workspace will build automatically on any change > (like a save operation) or any action that requires a built workspace (like > launch). You might e.g. commit code to the shared repo that has compile errors. Currently there is no build or check that would prevent this. > After all you requested a manual clean without rebuild for a reason. Well, *I* would not do that ;-). > Note > that not rebuilding is not the default behavior; I'm just requesting the > option to do so for situations where I want exactly that. I do think I'll > remember what I have done in this case. I claim that 90% of the people do not need/want this option. So, maybe we can add a command (Clean Only) that just does what you request and not surface it so prominently in the UI.
Ok. It's good to have this kind of conversation between users from very different background ! In some sense I guess that's part of why Open Source is successful, we're getting more people from different background to collaborate. I see your point regarding "always keep built" and it makes sense. > I claim that 90% of the people do not need/want this option. So, maybe we > can add a command (Clean Only) that just does what you request and not > surface it so prominently in the UI. A separate "Clean Only" would be very confusing when "Clean" is already there, so I'll have to veto that approach. Let's find a different way of reducing UI exposure. What about getting back to your original proposal - keep the additional UI completely hidden when none of the projects in the workspace has a builder that uses the ICommand#setBuilding() API to opt-out from autobuild ?
(In reply to comment #8) > Ok. > > It's good to have this kind of conversation between users from very > different background ! In some sense I guess that's part of why Open Source > is successful, we're getting more people from different background to > collaborate. I see your point regarding "always keep built" and it makes > sense. Agreed! > What about getting back to your original proposal - keep the additional UI > completely hidden when none of the projects in the workspace has a builder > that uses the ICommand#setBuilding() API to opt-out from autobuild ? That could work. As a bonus, the dialog could indicate (e.g. with a decorator) which projects don't support auto-build.
