Community
Participate
Working Groups
features: 1) with "Build Automatically" selected, select any project and go to Project menu. The "Build Project" action is disabled. It should be enabled as "re- build project". Right now, you have two extra steps: you have to select "clean..." and the "clean projects selected below" and then ok. 2) with "Build Automatically" selected, select any working set and go to Project menu. The "Build working set" action has disabled children. Rebuild wroking set would be great. Or as a quicker solution, select "clean..." and then "clean projects selected below". If you do that then by default all projects belonging to the working set should be preselected.
I believe these changes were intentional... MvM?
For #1, it seems like you just have to select clean... and hit enter as the selected project is already selected in the list (so long as you do not use working sets in the Package explorer. I suppose we could have a Clean Project option that was enabled based on selection which would kick off a clean and then a build. #2 Agree when you are running a working set perhaps it should be selected in the clean dialog however, this makes the Working set options kind of useless.
re: "I suppose we could have a Clean Project option that was enabled based on selection which would kick off a clean and then a build." yes, that will just add happiness to my life. :) re: "Agree when you are running a working set perhaps it should be selected in the clean dialog" so if a working set is selected and then I select "clean... " all the projects that belong to the working set should be selected. re: "however, this makes the Working set options kind of useless. " here is a shot at what a Project menu could look like: Re-build All (short cut to cleaning all projects) Re-build project (short cut to cleaning selected project. Disabled if working set is the current selection) Re-build working set (short cut to cleaning selected working set. If project is the current selection, clean the working set the holds this project.) Re-build working set -> (same as 3.1) Clean... (same as 3.1) Build Automatically (when selected, causes all menu options above to have the wording re-build, instead of build. Rebuild means a clean and then a build)
I strongly disagree with introducing the term "rebuild" again. This was removed because it was very confusing. What is the difference between the terms "build" and "rebuild"? To most users, "rebuild" just implies that the thing being built has been built before. The term does not imply throwing away all existing state, which is what it actually did. Also note that the decision to make the "clean" commands less accessible was also deliberate (by moving to a dialog instead of top-level commands). In an environment with properly behaving incremental builders, clean should never be necessary. Essentially, its main purpose is for when builders screw up and get into a bad state. Here is the document from 3.0 that describes some of the motivation for these changes: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/scoped_builds.html I agree that we need to think about the impact of the "build working set" command in the context of workbench page working sets. Maybe there should be an extra command in the "Build Working Set" sub-menu called "Current Working Set" that would use the workbench page working set.
re: "What is the difference between the terms "build" and "rebuild"? To most users, "rebuild" just implies that the thing being built has been built before.... " and so great, they know that it is a rebuild of a thing that has been built before, which us exactly what is happening and what is requested. Having said that, I wont open up a can of worms if this is the community has decided that rebuild does not make sense. My concern was that reality is that if you modify target workspaces a lot and change configurations a lot, you will end up with a false negative compile error where you do need a clean action. Making that scenario simple and clear to use is goodness. All the build actions that I have in the previous comment can be called "build" instead of "rebuild" and they will still make sense. "Build" can still be enabled when auto build is on, and it will still make sense. Think of it this way: refresh action is always enabled. Why does it make sense to refresh a project that I have just refreshed two seconds ago (menu is always enabled), but it does not make sense to build a project just because auto build is on? I feel like building my project? thank you for auto-building it, but I want to build it now. no? For working sets, an extra menu option "build working set" or pre-selecting all the projects belonging to the working set will make the menu actiosn more usable.
If changing your target workspace or configuration is not causing autobuild to work correctly, then I suggest logging a bug against PDE. If the user has to do a manual build while autobuild is on, it's almost always a bug. We shouldn't change the UI to support a workflow introduced by an incorrectly behaving builder. When autobuild is turned on, then the workspace should always be in a fully built state. Thus, no explicit "build" command is needed, and would be confusing. The user would click it and nothing would ever happen. I think the refresh case is slightly different. In the case of builds, we are able to compute whether a build is required. With refresh, we can never know if the file system has been modified by some external tool. If you click refresh two seconds ago, but one second ago some other application touched the file, then another refresh may be needed.
I should further clarify the PDE builder comment, since it may not be a bug in the builder itself. There are some times when a build is needed, but the workspace has not changed - for example a builder preference has changed, or a dynamic classpath variable has changed. In these cases, the recommended approach is to call IProject.touch() on the affected project, which will cause the autobuild kick in. I haven't seen this problem myself, but it sounds like a touch of affected projects is needed when the configuration or target platform has changed.
agreed %100 that the UI should not be changed just to hide potential bugs. (side comment: Im not saying I actually have a valid bug against build or pde component. Im guilty of seeing a red X and not thinking twice about why it is there. I do a quick build and Im done. Its gone. Typically the workbench gets into a bad state if you kill eclipse, or you hybernate your machine for too long and windows reboots on startup killing eclpise without a proper shut down. ) With that said, if you compile java code from a command line, you can call javac as many times as you want on the same untouched java file. Bytecode is thrown away and regenerated each time. It's the developers call. Why is the ui not providing this support easily? Disabling the build menu when autobuild is on takes away from the ease of that scenario. Yes, the solution is clean and then auto build will kick in, but the "clean" is a concept introduced by IDEs, not java. People understand it easily, and Im sure they will understand that a user initiated build will do the same as a javac. no? To not loose track of the initial features in this defect, I guess no one objects that: 1) if you select a working set, having all projects of the working set be pre- selected in the clean... dialog is a valid feature request. correct? whether or not it makes sense to enable a "user initiated builds" is what is being debated. I would recommend that the UI team, if they see fit, poll the community for feedback on percentage of people that like to do manual builds every once in a while. But I leave that up to you guys.
Updating the title because it was vague: Here is the summary of what this bug is about: If you select a working set, having all projects of the working set be pre- selected in the clean dialog...
(In reply to comment #8) > 1) if you select a working set, having all projects of the working set be pre- > selected in the clean... dialog is a valid feature request. correct? Is this still an issue? I can confirm that the clean dialog is preselecting projects properly in 3.3.0.
"As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009"
>Is this still an issue? I can confirm that the clean dialog is preselecting >projects properly in 3.3.0. Yes, this seems to work for me. For example if the Package Explorer has working sets as roots, if you select a working set the clean dialog is correctly populated with the contents of that working set. In other views, if you select a bunch of projects, then the clean dialog is initialized with that selection. This does mean there are two clicks Project > Clean, Ok, but I think this is better than adding clutter to the top level menu. Please reopen if you still see a problem.
