This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
During NetBeans 6.5, the concept of the Main project was made optional, as it is not appropriate in many use cases, especially when the user's code consists of just one project. This was a big usability improvement, as the concept of the mandatory main project was often very confusing to the users. However, usability can be further improved by not using the main project concept by default, i.e. when creating or opening a project, it would never be set as main by default. Several cases would have to be handled specially, e.g. a Java library used in a (Swing or Web) application, or a Java web application included in an EAR file, so the Run action behaves intuitively in these cases.
Ondro, please evaluate. Thanks.
Similar to report 51686.
Agreed with Petr's suggestion.
Although it seems to make sense, I'm not sure if this really is a problem, do we have any user feedback? I haven't come across any. Right now users who do not work with Java projects hardly ever find out we have such concept as for other projects it is not used, AFAIK. And if they work Java, this IMHO would hardly cause them issues. On the other hand, I've seen a user to run a different project than they wanted to in a usability study (in rather specific artificial situation though). Generally, I do not have any issues with it, provided we handle the special cases. I'm not sure we can cover them all right away, so I'd suggest to do this early in a release .. any ideas, objections? (When I was playing with this, I've discovered a related issue: while we have a way of setting a main project, we do not have an easy way of setting a project non-main. I filed this as #191404)
I am in favor of removing the main project concept entirely, and handling the relatively infrequent use cases by delegating actions from one project to another when the IDE can know for sure that this is appropriate: 1. If a WAR is in an EAR, "Run Project" on the WAR should automatically load the EAR into the app server, though this need not rebuild other subprojects of the EAR. 2. A Maven NBM app consists of a pom project, an nbm-application project, and some nbm projects. "Run" should always take effect on the nbm-application project. (In an Ant NBM app, "Run" is available on the module projects and does essentially the same thing as "Run" on the suite, so there was no need for a main project to begin with.) 3. If a JAR project with a main class depends on another JAR project with no main class, "Run" on the second ought to start the first when it is open. For cases where it is not very clear, just run the selected project. Of course handling these special behaviors will take some work, so it needs to be planned to fit in one release.
(In reply to comment #5) > I am in favor of removing the main project concept entirely, and handling the > relatively infrequent use cases by delegating actions from one project to > another when the IDE can know for sure that this is appropriate: Ok, let's go for not setting the main project by default, thus only limiting its use to users who explicitly choose so. This needs to be done together with making both setting and unsetting main project easy and intuitive (see issue #191404). Let's plan this for the beginning of the next release. > 1. If a WAR is in an EAR, "Run Project" on the WAR should automatically load > the EAR into the app server, though this need not rebuild other subprojects of > the EAR. > > 2. A Maven NBM app consists of a pom project, an nbm-application project, and > some nbm projects. "Run" should always take effect on the nbm-application > project. (In an Ant NBM app, "Run" is available on the module projects and does > essentially the same thing as "Run" on the suite, so there was no need for a > main project to begin with.) > > 3. If a JAR project with a main class depends on another JAR project with no > main class, "Run" on the second ought to start the first when it is open. 4. User is working on a java class library project used within other (open) project. No project is set as main - in this case the logic probably needs to be extended for run to execute on the open project using that library or query the user if there are more such projects.
https://blogs.oracle.com/geertjan/entry/tip_unset_as_main_project suggests this should be considered again.
*** Bug 51686 has been marked as a duplicate of this bug. ***
*** Bug 189270 has been marked as a duplicate of this bug. ***
Started work on this in a patch, to the extent of not setting m.p. when a new project is created, and removing some associated UI (incl. Set as Main context menu item on projects), leaving in place just the Run > Set Main Project submenu. As to what should replace this UI, there are a number of choices, including: 1. Nothing in particular - let users set a main project if they find it convenient, but by default always operate on the current selection. 2. Try to run the "right" project automatically when the IDE can tell that the selected project is just a component. I listed some options already in comment #5. (#4 from comment #6 is a duplicate of my own #3.) Convenient for many common cases, but might seem too magical. Has the potential advantage of being able to build just the selected component and then run the container project. 3. Provide a UI for delegating actions (probably just Run/Debug/Profile Project) to another project, probably as a special kind of "run configuration", without actually configuring that by default. Compared to #2, is more explicit but might not be discovered and requires brief setup. Compared to #1 (current main projects), is more robust - survives closing and reopening projects, and works properly when there is >1 app/container project open. 4. Offer an action for rerunning the last project. The existing Run > Repeat Build/Run sort of does this, but operates on any build process, including compilation and running unit tests; whereas this would be limited to build tool invocations triggered by the Run/Debug/Profile Project commands. #2-#4 could involve removing even Run > Set Main Project and all other UI for main projects, or could keep this UI as a backup system for those comfortable with it; TBD.
Cannot plan this for 7.2 without some sort of UI guidance.
Adding Rich to CC and I am asking for his comments. IMHO not setting a main project by default is OK if one of the solutions in Comment 10 is implemented, but I do not like the idea of removing the option entirely. This would be inconvenient for people who are used to it - and the advantage by such a change might be difficult to defend from their point of view. For a similar reason I would be cautious about option 3 in Comment 10; increasing UI complexity of an established usage area requires a serious reason and clearly notable gain, especially if it may affect many users who would prefer things to stay as they are if they work sufficiently well for them. And I am not yet convinced that users would be happy enough about radical changes in this case.
All, This is an area of IDE UI design that I've seen MANY bad designs for. Let me make sure first that I understand the problem at hand, and the set of requirements around this. Check me on these assumptions: - In NB, you have a Projects browser that allows you to add and remove projects at will. This is different from other IDEs who have a top-level file type, called a workspace, application, or solution, all of which are just a container for 1-to-n projects. - Presumably, if a developer is adding multiple projects to their Projects browser, it is because there is some inter-relation or dependency between the outputs of those projects. - The goal of features like defining a main project, or having a build configuration, is to allow the user control over which projects are compiled, how they are compiled, where their output is placed or deployed, and in which order they are compiled. - Setting and maintaining a "main" project is really only the tip of the iceberg. What we need to give the user control over is how NB handles building and/or running all of the projects in their Projects browser. We can go two ways with this. We can come up with an intuitive UI for managing builds and runs, or we can follow the KISS principle and just Run the selected project, which relies on the user to self-manage dependencies and the proper order of operations. Thoughts? Rich
(In reply to comment #13) > you have a Projects browser that allows you to add and remove projects > at will. Yes, you may open whatever set of projects you like. You may even open files from nonopen projects - for example, Ctrl-B on a reference to a class defined in some dependency you did not bother to open yet. > if a developer is adding multiple projects to their Projects > browser, it is because there is some inter-relation or dependency between the > outputs of those projects. Often. Not necessarily. > The goal of features like defining a main project, or having a build > configuration, is to allow the user control over which projects are compiled And run. > how they are compiled, where their output is placed or deployed, and in which > order they are compiled. No, no, and probably no. The choice of main project is nothing more than a convenience so that global shortcuts like F6 or toolbar buttons like Run Project will operate on a project which has some kind of entry point (in the case of Run/Debug/Profile) or whose build process recursively invokes other projects on which it depends (in the case of Build/Clean & Build) even if the UI happens to have the focus on a different project. If you do not set a main project, and you are e.g. working on a file from a separate related project but want to build or run this other one, you need to use the context menu or switch focus e.g. in the Projects tab. (Of course if you _do_ set a main project then you can have the opposite problem - it is awkward to perform these actions on the selected project.) Note that when exactly one project is open, it is treated as implicitly "main" for purpose of the main-project-sensitive actions: F6 will run it even if no file from it has focus. When there is no main project and either multiple projects open or none, then the selection determines which project is used. (E.g. the project root node in Projects, an editor window for a file in it, a folder in it in the Files window, etc.) Rich's KISS preference coupled with Petr's comment suggests option #1 - stop advocating the main project mechanism but retain its basic elements for users habituated to it. This is what the patch I was working on, mentioned at the start of comment #10, essentially does: GUI elements to set the main project when creating a project (many of them currently checked by default) are removed; checkbox to set as main when opening a project is removed; context menu item to set/unset a project as main is removed; just Run > Set Main Project main menu item retained in the GUI; those actions currently sensitive to main project (Build, Clean & Build, Run, Debug, Profile) continue to be; project groups continue to remember main project setting, if any. There was a request a few months ago - from one of the CND team, but not sure how to find it now - for miniature run buttons to be embedded into the Projects window at the end of the row for a project root node, which for a mouse user would make it quicker to run a particular project. Of course does not help for Build, Debug, etc., and would consume limited screen space. BTW in reference to option #4, in 7.2 there is keyboard shortcut Ctrl-F11 but the behavior of the existing action is the same - it will repeat whatever build, test, or run was last launched.
Jesse, Leave it to me to overcomplicate something....typical user experience person that I am. :-) Now that I've got a better idea of what the "main" project is and means, I think I've got a different recommendation. I, for one, have always liked how Visual Studio handles this: the shortcuts and affordances for build and run pertain to the currently selected project in the navigator. If there is a file selected, they pertain to its parent project. I don't like using the word "Main" for this, because that term is a little bit overused. How many versions has this been used for, i.e. do we have to leave it the same because of legacy support? To wit, IntelliJ doesn't have this concept, because they only open one project in a tab, so whatever the active tab is gets treated as "Main". JDeveloper and Eclipse both work like Visual Studio. I don't think that main really gives us any efficiencies, instead its just one more thing that the user needs to understand and manage. Just my .02!
(In reply to comment #15) > how Visual Studio handles this: the shortcuts and > affordances for build and run pertain to the currently selected project in the > navigator. If there is a file selected, they pertain to its parent project. That is exactly how NetBeans works if you do not set a main project, so if this is the desired state, then the question is just to what extent the existing main project UI should be suppressed or deprecated; comment #12 suggests that it should not be entirely removed.
Jesse, It's a judgment call. We're making an argument between consistency with three other IDEs and legacy support. Do we have any data to suggest this is a feature that users want, understand, and use? Do we have any traceability back to the ER in which main projects were initially incorporated? Looks like the answer is "before NB 6.5", but how long has this been a part of the product? Rich
The main project setting was included in the initial release of the current project system, NB 4.0. I do not have any data on its usage. We may well have statistics on how many people run with a main project set, but this figure may not be very meaningful since the IDE currently sets it by default in a number of circumstances. There might be statistics on how often a project is manually set as main.
I'd like to clarify just one thing. Regarding: > I don't think that main really gives us any efficiencies, instead its just one > more thing that the user needs to understand and manage. No, actually assuming option #1, users do not need to understand and manage the main project, they can just ignore it. Most users will not notice that they can set a main project, and setting the main project is completely optional. Only power users may want to use a main project - everyone else can safely ignore it and just go with the default behavior, which is the approach used by Visual Studio. So, option #1 gives flexibility and compatibility with previous versions to power users, but does not make things more complicated for everyone else.
Let me make sure I understand. If the user doesn't ever set a main project, NB will act like the other IDEs. If they do, it will alway apply the shortcuts and menu options to the main project, unless they "unset" it or set a different one? If that's the deal, and there isn't a requirement or a strong push towards setting one in the first place, I'm on board with that approach.
Created attachment 116408 [details] UI for setting/unsetting main project in main menu That's correct, I am attaching a screenshot of the main menu action for setting and unsetting main project. Under option #1, this is the only piece of UI that would be retained that refers to the main project. By default, main project would be set to "None".
Awesome. I like it.
OK, assuming psomol does not object, I will plan to implement option #1.
Just confirming this is OK with me.
Created attachment 116528 [details] Proposed patch 1. Set as Main checkbox removed from Open Project 2. " " " " " " New Project wizards 3. " " " context menu item removed from project logical views 4. minor apichanges in projectuiapi 5. tasklist scope changed to simply "Selected Project" 6. "subprojects"-type group does not set main project by default 7. some misc. bits of code no longer set a main project, e.g. Eclipse import, or Hg clone ant.freeform/src/org/netbeans/modules/ant/freeform/resources/layer.xml | 4 - ant.freeform/src/org/netbeans/modules/ant/freeform/ui/BasicProjectInfoPanel.form | 22 +------- ant.freeform/src/org/netbeans/modules/ant/freeform/ui/BasicProjectInfoPanel.java | 21 ------- ant.freeform/src/org/netbeans/modules/ant/freeform/ui/BasicProjectInfoWizardPanel.java | 2 - ant.freeform/src/org/netbeans/modules/ant/freeform/ui/Bundle.properties | 2 - apisupport.ant/src/org/netbeans/modules/apisupport/project/resources/layer.xml | 8 -- apisupport.ant/src/org/netbeans/modules/apisupport/project/ui/ApisupportAntUIUtils.java | 3 - apisupport.ant/src/org/netbeans/modules/apisupport/project/ui/ModuleUISettings.java | 9 --- apisupport.ant/src/org/netbeans/modules/apisupport/project/ui/wizard/BasicInfoVisualPanel.form | 25 +-------- apisupport.ant/src/org/netbeans/modules/apisupport/project/ui/wizard/BasicInfoVisualPanel.java | 46 +--------------- apisupport.ant/src/org/netbeans/modules/apisupport/project/ui/wizard/Bundle.properties | 2 - apisupport.ant/src/org/netbeans/modules/apisupport/project/ui/wizard/NewModuleProjectData.java | 9 --- apisupport.ant/src/org/netbeans/modules/apisupport/project/ui/wizard/NewNbModuleWizardIterator.java | 3 - cnd.discovery/src/org/netbeans/modules/cnd/discovery/projectimport/ImportExecutable.java | 1 - cnd.discovery/src/org/netbeans/modules/cnd/discovery/projectimport/ImportProject.java | 9 --- cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/MakeProjectGeneratorImpl.java | 1 - cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/api/RunDialogPanel.java | 2 - cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/api/wizards/WizardConstants.java | 1 - cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/ui/MakeLogicalViewRootNode.java | 2 - cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/ui/wizards/Bundle.properties | 4 - cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/ui/wizards/PanelProjectLocationVisual.form | 18 +------ cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/ui/wizards/PanelProjectLocationVisual.java | 18 ------ cnd.makeproject/src/org/netbeans/modules/cnd/makeproject/ui/wizards/SelectModePanel.java | 1 - groovy.grailsproject/src/org/netbeans/modules/groovy/grailsproject/ui/GrailsLogicalViewProvider.java | 1 - groovy.grailsproject/src/org/netbeans/modules/groovy/grailsproject/ui/wizards/Bundle.properties | 2 - groovy.grailsproject/src/org/netbeans/modules/groovy/grailsproject/ui/wizards/PanelOptionsVisual.form | 22 +------ groovy.grailsproject/src/org/netbeans/modules/groovy/grailsproject/ui/wizards/PanelOptionsVisual.java | 15 +---- groovy.grailsproject/src/org/netbeans/modules/groovy/grailsproject/ui/wizards/PanelProjectLocationVisual.java | 1 - j2ee.archive/src/org/netbeans/modules/j2ee/archive/ui/RootNode.java | 1 - j2ee.clientproject/src/org/netbeans/modules/j2ee/clientproject/ui/resources/layer.xml | 4 - j2ee.common/src/org/netbeans/modules/j2ee/common/project/ui/Bundle.properties | 2 - j2ee.common/src/org/netbeans/modules/j2ee/common/project/ui/ProjectImportLocationPanel.form | 40 +++---------- j2ee.common/src/org/netbeans/modules/j2ee/common/project/ui/ProjectImportLocationPanel.java | 26 +------- j2ee.common/src/org/netbeans/modules/j2ee/common/project/ui/ProjectLocationPanel.form | 23 +------- j2ee.common/src/org/netbeans/modules/j2ee/common/project/ui/ProjectLocationPanel.java | 17 +----- j2ee.common/src/org/netbeans/modules/j2ee/common/project/ui/ProjectLocationWizardPanel.java | 1 - j2ee.common/src/org/netbeans/modules/j2ee/common/project/ui/UserProjectSettings.java | 12 ---- j2ee.earproject/src/org/netbeans/modules/j2ee/earproject/ui/resources/layer.xml | 4 - j2ee.ejbjarproject/src/org/netbeans/modules/j2ee/ejbjarproject/ui/resources/layer.xml | 4 - j2ee.jboss4/test/qa-functional/src/org/netbeans/test/j2ee/lib/Util.java | 2 - j2ee.kit/test/qa-functional/src/org/netbeans/test/j2ee/lib/J2eeProjectSupport.java | 2 - j2me.cdc.project/src/org/netbeans/modules/j2me/cdc/project/ui/wizards/Bundle.properties | 7 -- j2me.cdc.project/src/org/netbeans/modules/j2me/cdc/project/ui/wizards/PanelOptionsVisual.form | 29 +--------- j2me.cdc.project/src/org/netbeans/modules/j2me/cdc/project/ui/wizards/PanelOptionsVisual.java | 20 +------ java.examples/src/org/netbeans/modules/java/examples/Bundle.properties | 3 - java.examples/src/org/netbeans/modules/java/examples/PanelConfigureProjectVisual.form | 20 +------ java.examples/src/org/netbeans/modules/java/examples/PanelConfigureProjectVisual.java | 40 ++------------ java.examples/src/org/netbeans/modules/java/examples/PanelOptionsVisual.form | 50 ----------------- java.examples/src/org/netbeans/modules/java/examples/PanelOptionsVisual.java | 115 ---------------------------------------- java.examples/src/org/netbeans/modules/java/examples/WizardProperties.java | 1 - java.j2seproject/src/org/netbeans/modules/java/j2seproject/ui/resources/layer.xml | 4 - java.j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/Bundle.properties | 7 -- java.j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelOptionsVisual.form | 26 +-------- java.j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/PanelOptionsVisual.java | 16 ----- java.j2seproject/src/org/netbeans/modules/java/j2seproject/ui/wizards/WizardSettings.java | 11 --- java.project/test/qa-functional/src/projects/apitest/Utilities.java | 2 - javacard.project/src/org/netbeans/modules/javacard/project/JCLogicalViewProvider.java | 1 - javacard.project/src/org/netbeans/modules/javacard/wizard/Bundle.properties | 1 - javacard.project/src/org/netbeans/modules/javacard/wizard/ProjectDefinitionPanel.form | 12 ---- javacard.project/src/org/netbeans/modules/javacard/wizard/ProjectDefinitionPanel.java | 11 --- javafx2.project/src/org/netbeans/modules/javafx2/project/Bundle.properties | 7 -- javafx2.project/src/org/netbeans/modules/javafx2/project/JavaFXProjectWizardIterator.java | 5 +- javafx2.project/src/org/netbeans/modules/javafx2/project/PanelOptionsVisual.form | 36 +----------- javafx2.project/src/org/netbeans/modules/javafx2/project/PanelOptionsVisual.java | 24 +------- javafx2.project/src/org/netbeans/modules/javafx2/project/WizardSettings.java | 9 --- javafx2.samples/src/org/netbeans/modules/javafx2/samples/Bundle.properties | 3 - javafx2.samples/src/org/netbeans/modules/javafx2/samples/PanelOptionsVisual.form | 33 +--------- javafx2.samples/src/org/netbeans/modules/javafx2/samples/PanelOptionsVisual.java | 23 +------ javafx2.samples/src/org/netbeans/modules/javafx2/samples/WizardProperties.java | 1 - maven.apisupport/src/org/netbeans/modules/maven/apisupport/NbmWizardIterator.java | 2 - maven/src/org/netbeans/modules/maven/layer.xml | 4 - maven/src/org/netbeans/modules/maven/newproject/ArchetypeWizardUtils.java | 2 - mercurial/src/org/netbeans/modules/mercurial/HgModuleConfig.java | 11 --- mercurial/src/org/netbeans/modules/mercurial/ui/clone/Bundle.properties | 2 - mercurial/src/org/netbeans/modules/mercurial/ui/clone/CloneAction.java | 5 +- mercurial/src/org/netbeans/modules/mercurial/ui/clone/ClonePanel.form | 30 ++-------- mercurial/src/org/netbeans/modules/mercurial/ui/clone/ClonePanel.java | 27 +-------- mercurial/src/org/netbeans/modules/mercurial/util/HgProjectUtils.java | 7 +-- mobility.project/src/org/netbeans/modules/mobility/project/ui/wizard/Bundle.properties | 1 - mobility.project/src/org/netbeans/modules/mobility/project/ui/wizard/NewProjectIterator.java | 2 +- mobility.project/src/org/netbeans/modules/mobility/project/ui/wizard/ProjectPanel.form | 14 +---- mobility.project/src/org/netbeans/modules/mobility/project/ui/wizard/ProjectPanel.java | 33 +--------- mobility.project/src/org/netbeans/modules/mobility/project/ui/wizard/SampleProjectIterator.java | 2 +- mobility.project/src/org/netbeans/modules/mobility/project/ui/wizard/imports/SourcesIterator.java | 2 +- mobility.project/src/org/netbeans/modules/mobility/project/ui/wizard/imports/WtkIterator.java | 2 +- php.project/src/org/netbeans/modules/php/project/ui/logicalview/PhpLogicalViewProvider.java | 1 - php.project/src/org/netbeans/modules/php/project/ui/wizards/ConfigureProjectPanel.java | 4 - php.samples/src/org/netbeans/modules/php/samples/PHPSamplesWizardPanel.java | 4 - projectimport.eclipse.core/src/org/netbeans/modules/projectimport/eclipse/core/ImportProjectAction.java | 11 +--- projectimport.eclipse.core/src/org/netbeans/modules/projectimport/eclipse/core/UpdateAllProjects.java | 2 +- projectui/src/org/netbeans/modules/project/ui/Bundle.properties | 14 ---- projectui/src/org/netbeans/modules/project/ui/NoMainProjectWarning.form | 77 --------------------------- projectui/src/org/netbeans/modules/project/ui/NoMainProjectWarning.java | 221 ------------------------------------------------------------------------------ projectui/src/org/netbeans/modules/project/ui/OpenProjectListSettings.java | 9 --- projectui/src/org/netbeans/modules/project/ui/ProjectChooserAccessory.form | 23 -------- projectui/src/org/netbeans/modules/project/ui/ProjectChooserAccessory.java | 59 ++++---------------- projectui/src/org/netbeans/modules/project/ui/actions/MainProjectAction.java | 73 ++----------------------- projectui/src/org/netbeans/modules/project/ui/actions/OpenProject.java | 8 +-- projectui/src/org/netbeans/modules/project/ui/groups/SubprojectsGroup.java | 5 +- projectui/test/unit/src/org/netbeans/modules/project/ui/ProjectChooserAccessoryTest.java | 2 +- projectui/test/unit/src/org/netbeans/modules/project/ui/test/ProjectSupport.java | 2 - projectuiapi/apichanges.xml | 18 ++++++ projectuiapi/src/org/netbeans/api/project/ui/OpenProjects.java | 2 +- projectuiapi/src/org/netbeans/spi/project/ui/support/CommonProjectActions.java | 2 + projectuiapi/src/org/netbeans/spi/project/ui/templates/support/Templates.java | 6 +- projectuiapi/src/org/netbeans/spi/project/ui/templates/support/package.html | 2 +- tasklist.projectint/src/org/netbeans/modules/tasklist/projectint/Bundle.properties | 7 +- tasklist.projectint/src/org/netbeans/modules/tasklist/projectint/MainProjectIterator.java | 27 +--------- tasklist.projectint/src/org/netbeans/modules/tasklist/projectint/MainProjectScanningScope.java | 47 +--------------- vmd.componentssupport/src/org/netbeans/modules/vmd/componentssupport/ui/wizard/Bundle.properties | 3 - vmd.componentssupport/src/org/netbeans/modules/vmd/componentssupport/ui/wizard/CustomComponentVisualPanel.form | 23 +------- vmd.componentssupport/src/org/netbeans/modules/vmd/componentssupport/ui/wizard/CustomComponentVisualPanel.java | 38 ------------- vmd.componentssupport/src/org/netbeans/modules/vmd/componentssupport/ui/wizard/CustomComponentWizardIterator.java | 1 - web.debug/src/org/netbeans/modules/web/debug/actions/JspRunToCursorActionProvider.java | 1 + web.examples/src/org/netbeans/modules/web/examples/Bundle.properties | 3 - web.examples/src/org/netbeans/modules/web/examples/PanelConfigureProjectVisual.form | 16 ----- web.examples/src/org/netbeans/modules/web/examples/PanelConfigureProjectVisual.java | 35 +----------- web.examples/src/org/netbeans/modules/web/examples/PanelOptionsVisual.form | 57 -------------------- web.examples/src/org/netbeans/modules/web/examples/PanelOptionsVisual.java | 115 ---------------------------------------- web.examples/src/org/netbeans/modules/web/examples/WizardProperties.java | 1 - web.project/src/org/netbeans/modules/web/project/ui/resources/layer.xml | 4 - 121 files changed, 140 insertions(+), 1838 deletions(-)
Please review.
I do not see any problem with the proposed patch.
core-main #1f58a82b5ece
Jesse, do you have some plan/issue to provide features like "running this J2SE Class Library project looks up whether it is references from some J2SE Application project and runs application instead"?
(In reply to comment #29) > do you have some plan/issue to provide features like "running this J2SE > Class Library project looks up whether it is references from some J2SE > Application project and runs application instead"? Not for 7.2 at least; comment #12 is skeptical about this kind of thing, but if it turns out to be desirable and there is a clear UI spec for it then it could be implemented as a separate effort.
Integrated into 'main-golden', will be available in build *201203200400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/1f58a82b5ece User: Jesse Glick <jglick@netbeans.org> Log: #166780: do not set main project by default.
With respect to comment #12, which says: > increasing UI complexity of an established usage area requires a serious reason > and clearly notable gain, especially if it may affect many users who would > prefer things to stay as they are The fact is that in this case, things have changed already, so the comment about "things staying as they are" does not apply. Consider the following scenario: 1. Project A is a Java application with a main class 2. Project B is a Java library used by Project A 3. User is editing a file in project B and hits run Before the change that Jesse just implemented, project A would be a main project, so the IDE would launch the main class of project A. After Jesse's change, there is no main project, so the IDE displays a dialog saying <No main classes found>. So the behavior has changed already. Now the question is whether we want to finetune the behavior in this case. It would be useful to know Petr Somol' opinion on this. Issue 189270 already discusses this specific scenario and one particular possible way (though surely not the only one) to solve it.
(In reply to comment #32) > Before the change that Jesse just implemented, project A would be a main > project might still be a main project, if you set it that way manually. Well... it *might* have been, if you did not uncheck the Set as Main checkbox, did not close and reopen A (other than as part of a project group) without resetting it as main, did not create a second application project, etc. And it > Issue 189270 already discusses this specific scenario I have reopened that accordingly. BTW its summary is a bit misleading; you can already select a main class from a different project, if that project is in the classpath of the selected project, and $selected/build.xml#run works in that case. What you are talking about is selecting a main class from a _downstream_ project, i.e. where the class is not visible in the sourcepath + classpath of the selected project, and thus where the IDE really needs to start a different build script.
Integrated into 'main-golden', will be available in build *201203210400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/90cdb5ae8c40 User: Jesse Glick <jglick@netbeans.org> Log: Drop-down menu removed in #105664 makes less sense after #166780 since there will usually not be a main project. (It could display configurations for the selected project, but probably this is too surprising.) A plugin could experiment with UIs for quick mouse-based invocation of (e.g.) Run on various open projects and their configs.
*** Bug 209965 has been marked as a duplicate of this bug. ***
My 2 cents... While I don't disagree with the change in model, the result in the gui does not make sense. Specifically, the visual appearance of the gui includes a bold highlight when a project is selected as the "main project", but when right-clicking on that project you cannot see how that boldness was acquired, nor how to change it. I can understand that some vast quantity of naive users don't want or need to set a main project. And they can safely ignore the Run->Set Main Project->blah blah, whose location is obscure enough that they won't run into it. But for someone that needs to identify the "main project", making it obscure seems counter productive. So two of the stated goals are (a) don't force the naive user to choose a main project, and (b) allow a main project to be set when one is needed. Having a menu item to set main project in the file menu and below the right-click-on-a-project seems quite consistent with the bold font emphasis. Its a property of the project, and it follows that I ought to be able to right click on that project and change that property. I see no argument above (let along a compelling one) that suggests having an intuitive location for such a menu item violates (a) or (b). For context, I use NB to work on a large C++ project, ~3M lines, which targets Linux, MacOS, Windows and MQX (a real-time OS). Identifying the "main project" is key for using NB. Product Version: NetBeans IDE Dev (Build 201203210400) Java: 1.6.0_23; Java HotSpot(TM) Client VM 19.0-b09 System: Linux version 2.6.35.14-106.fc14.x86_64 running on i386; UTF-8; en_US (nb) User directory: /home/toddb/.netbeans/dev Cache directory: /home/toddb/.cache/netbeans/dev
Using some of the quite limited space available in every project's context menu to manage a feature many users will never need is not a good idea. The Set Main Project menu item has always been there and continues to work; it is no more "obscure" than any other main menu item needed only for certain workflows, e.g. Tools > DTDs and XML Schemas. In fact it is right below those menu items it primarily affects the behavior of, such as Run Main Project. One compromise option (also I think permitting #209973 to be downgraded to P3) would be to display the old Set/Unset as Main Project context menu item only if there is already a main project set, or has been during the current IDE session, in which case this feature is presumably relevant to the user. Of course in this scenario if you chose Unset (or closed the project group etc.) and then restarted the IDE then the context menu item would not initially be visible so you would need to use the main menu item. Up to Petr and Rich to decide what they want.
In view of #209973 and the fact that many users actively do use the Main Project feature (I got similar reports like Comment 36 by e-mail) I like the idea proposed in Comment 37 - no Set/Unset option in context menu by default, until the user sets a main project through Run menu. From that moment on the project context menus would show the Set/Unset items. My only reservation is about disabling this on IDE restart with no main project set. Generally it is inconvenient for users if menu contents (or UI in general) change without direct user's action, and when effort is needed to find out what is the logic behind that. I would prefer this change to be more persistent - once the user starts using the main project feature, the context menu would better remain extended from that moment on across IDE restarts. I admit this is not a perfect solution - unless there would be a simple way of removing the items again. But why not to connect the removal of menu items to choosing None in menu Run->Set Main Project? Then the menu Run->Set Main Project would become the central place from where to enable or disable the feature globally. Maybe to emphasize this the item None in menu Run->Set Main Project could be renamed to Disable or something like that to suggest that it differs from simple Unset.
That might work; filed as bug #210148.
*** Bug 210046 has been marked as a duplicate of this bug. ***
*** Bug 139873 has been marked as a duplicate of this bug. ***
*** Bug 215259 has been marked as a duplicate of this bug. ***
*** Bug 231477 has been marked as a duplicate of this bug. ***