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.
May be desirable to introduce configurations (or "profiles") for j2seproject's, permitting the user to set up several configs that could affect build options (e.g. javac.debug) and/or run options (e.g. assertions on) and quickly switch between them. Internal design pretty clear from J2ME: have private.properties have e.g. configuration=production and in either project.properties or private.properties have e.g. production.javac.debug=false development.javac.debug=true javac.debug=${${configuration}.javac.debug} (need to do some tricks because Ant does not allow recursive property substitution). Could also have separate production.properties and development.properties files, but the above style seems to work for J2ME and is straightforward enough. GUI style not so clear.
*** Issue 51036 has been marked as a duplicate of this issue. ***
*** Issue 34513 has been marked as a duplicate of this issue. ***
*** Issue 48709 has been marked as a duplicate of this issue. ***
*** Issue 51825 has been marked as a duplicate of this issue. ***
*** Issue 8845 has been marked as a duplicate of this issue. ***
*** Issue 52199 has been marked as a duplicate of this issue. ***
*** Issue 56402 has been marked as a duplicate of this issue. ***
*** Issue 54474 has been marked as a duplicate of this issue. ***
I'd like to ensure that the bug that was marked as a duplicate of this (#48709) gets covered. Again I find myself frustrated by having to re-learn ant just to execute a main() class with parameters. During a recent upgrade I lost my modified build.xml.. Please re-add the abilityt either to: - Create simple ANT build tasks (Wizard, perhaps?) -or- - Specify parameters for any main() class The frustrating thing is that feature did exist in NB3.X. Now it's gone!
[clever - you must add yourself to CC if you wish to see any replies.] This RFE does cover creating a config for a particular main class with particular parameters. Re. losing a modified build.xml - this should never happen; the IDE should only regenerate build.xml if you have made no edits. If you can reproduce the problem, please file a separate bug report with complete details.
Created attachment 22172 [details] multiple run profiles in Eclipse 3.x (2 profiles in pic: 1. CountCorpus, 2. ErgoSum)
Attach id 22172 is a screenshot from Eclipse 3.x. Eclipse allow us to have many Run profiles, for any number of projects. This is very handy when you have to work on more than one project at a time, or for a project that has many runnable classes. NetBeans 4.1 has only one "Run Main Project" (F6) option.
Verson -> 4.1 (current one) CC reporters of duplicated issues.
This is very similar to the IDEA's Run/Debug profiles. The NetBeans should also introduce the run profiles in the future. From the technical point it is not very hard, the run profile is an Ant property file loaded from the build-impl.xml. The biggest problem is the UI change.
Please leave the Version field alone. It was reported for 4.0 and applies to any 4.0+ version. Re. "when you have to work on more than one project at a time" - note that NetBeans includes two actions for run: Run Main Project, and Run [Selected] Project. The former is included in the Run menu by default and is bound to F6 by default. You switch that to the latter action using the Options and Keyboard Shortcuts dialog if you prefer. Then you can freely run which project you have selected (e.g. the project containing a file open in the editor) using F6 or the menu item. The flip side is that you *have* to switch to the desired project to run it, which could be annoying if you have one app with a lot of libraries and you always want to run the app.
*** Issue 59913 has been marked as a duplicate of this issue. ***
*** Issue 60786 has been marked as a duplicate of this issue. ***
You can also look at how JBuilder as this implemented. Regarding also Java EE projects, it should be very usefull that we can target some apllication to diferent Application Server's
*** Issue 61252 has been marked as a duplicate of this issue. ***
Once again, I have come upon a circumstance where I need to run a main class with parameters that isn't the main class that corresponds to the entire project. (In this case, it's a utility that is part of a webapp) I know this may not be the best pattern, but the fact that the feature of running a main class with parameters did exist in pre 4.0, makes it a regression in my book. I'd like to include this (adding params, or mutliple profiles) for NB 5.0 consideration.
It is not possible to put it into the NB 5.0. The NB 5.0 is already two months after the code freeze, only bug fixes can be integrated. The run profiles are big candidate for the next version of NB.
*** Issue 65076 has been marked as a duplicate of this issue. ***
As many of the remarks below indicate - there is a big need for having the option for multiple runconfigurations for the same Projects. Not just since the project may have different main classes but also to have differnt arguments or JVM settings for the same class to run. Having this as in JBuilder/Eclipse/IntelliJ would be a tremendous help (Currently I have to hack around in the xml files making individual new targets etc, - messy.) B-)
I've agree that this task has a higher priority. I've increased the priority to P1 since it has more than 20 votes.
*** Issue 52747 has been marked as a duplicate of this issue. ***
*** Issue 66748 has been marked as a duplicate of this issue. ***
With all the recent emphasis on supporting multiple run profiles, I just want to make sure the original focus of this issue isn't lost, which is to support multiple build profiles. As described in Issue 56402, this is much more complex than just supplying alternate runtime arguments or JVM flags. Compiling (and running!) with different builds of libraries/sub-projects (which may themselves have multiple build configurations) is also required.
target 5.5 ?
*** Issue 72994 has been marked as a duplicate of this issue. ***
I think with all of the features making their ways into Netbeans being able to have design profiles would be a big help as well. Some how being able to include modules in profiles and obviously having a generic category where those modules would always be turned on. It would help manage the memory foot print a bit better in my opinion. Then be able to tie profiles to project types so that when a given project is opened its required modules could be sure to be available. I would imagine the profile would not open and close between file switching, but only when a project is opened or closed or manually changed(work around conflicts with open projects there...just not allow profiles to be shutdown without the project I would assume). It would even be nice if one were able to associate optional modules with design time profiles. Making it dynamic for the user so they could tweak their development environment a bit better. This way any extra modules they install which may or may not work with any given file types or design pattern could be tied to the project types they would like. Then maybe add new interfaces which modules may or may not use which allow the IDE to pass messages about switching profiles and then the module owner could choose to keep certain parts in memory and not completely close out the module to allow speeding up slow startup features of some modules which might make profile switching a pain. Should this be an entirely differnt issue?
Wade: what you are talking about has nothing to do with this RFE at all.
I think I'll search for that and see if someone has something similar already filed. If not I think I'll file it. I've seen different concerns along those lines. For some reason, I misread a comment and didn't read everything here and obviously confused myself. I like the idea of having multiple run profiles. I think in one of the other issues I added a comment about being able to have the options also be available from the class level like they were in pre 4.0 where the runtime arguments were able to be set on a class by class basis. If it were that simple to setup it would be awesome. Maybe make it available from that level as well as to not have to enter properties then go to runtime profiles/configurations, but make having to go into properties optional for that, and also allow a right click on a class with a main method and "Set Runtime Configuration" and it automatically fill in the class and be ready for the user to enter the runtime arguments and setup the libraries,platform, runtime, and what not. I used the feature in 3.6 often to run many classes. Obviously this will be more complex than the workings of pre 4.0.
Playing with API (based on that in Mobility Pack and C/C++ Pack); and run profile impl for j2seproject. cvs rtag prj_configs_49636_base projects java/j2seproject cvs rtag -d prj_configs_49636_base projects/www cvs rtag -b -r prj_configs_49636_base prj_configs_49636 projects java/j2seproject
Also need to branch ant/project, it turns out.
Jano et al.: please see the linked-to proposal for a description of the proposed changes.
Created attachment 31098 [details] Proposed patch
I'd like to also ask API reviewers to approve the enhancement to ant/project. Fairly simple and basically just makes some utilities public which were already in use for a long time.
I would need to see a full UI proposal (e.g. with ascii-arts) to comment more. So far I think it's moving the right direction. The configuration concept needs to be presented to the user the same way in all project types in 6.0 timeframe, which means the configuration combo is put on the same position in project properties dialog in all project types. So, if one project type (in standard NB distribution?) puts it at the top of the dialog above the categories, all project types should do the same. If all project types keep it inside the Run panel, then it can stay there. The run-panel option is more like "Run Profiles" vs. mobility solutions which is more like "Project Configurations". This also affects where we put the configuration selection into the main menu. If it is "run profiles", it should be in the Run menu. If it is "project configurations" it should be in the Build menu. Note I'm talking about the overall UI solution for 6.0, not Java SE project specfic.
i'm not quite sure how this is going to be implemented, but are you going to make it possible to do a mapping between a "run-as"-menu-element and an arbitrary ant-target (like you can i eclipse)? This way you could use the "run- as" menu to do basically anything you want (run-as/build-as etc. If you create a custom ant-task, you can use any class and method available in the Java API. The possibilities are endless :) And while we're talking about ANT, it would be nice to have a wizard/GUI for creating new ant targets in a project. I know ANT now, and can program targets in xml manually, but there is a lot of people out there who doesn't know ant, or doesn't have the time (or the desire) to learn it. This wizard could be used in a general way for projects (add target to build.xml), or for creating custom "run-as"-configurations. I think the same argument should apply to ANT as it does for descriptor-files: you can edit the xml-directly, but it's usually more convenient to do it through a wizard/GUI-editor. </digression>
Created attachment 31162 [details] A picture is worth cca. 1kLOC
jrojcek: See attached collage of screenshots for current UI appearance (general & j2seproject). Again, demo build available on request. Re. appearance in Properties dialog: currently at top of Run panel for j2seproject. Might be the same for Java EE projects but that is up to the developers of those modules to decide; may not be appropriate for those project types. It looks rather different for Java ME projects because they have different needs. Re. location & naming of general GUI: we can't fix one location and naming convention that will be perfect for all project types. Certainly Java ME and SE projects are not using configs in the same way. However it is trivial to move the controls around or rename them, so this is something we might defer to later in the 6.0 dev cycle when Java EE project types have started to use the SPI and we know for sure what the modules in the standard distro (and standard distro plus officially supported add-on packs) will be using. For now the global UI is very similar to what Java ME and CND project types were already using. Note that "Profile" label in Run panel should be renamed "Configuration" for consistency with global UI; I will make that change in the branch. tlund: impl does not involve custom Ant targets. See URL for details. The things you are talking about are not directly related to this proposal, though freeform projects could in the future use issue #49652 if there is felt to be a need for it.
I am thrilled to see all the activity on this issue and am excited about the possibilities. I see the target milestone is still "dev", does this mean it will not be in 5.5 or is this still not known?
I do not expect this RFE will be put into 5.5. It is under discussion for 6.0.
Cool collage. The UI looks good to me. I expect we would move the controls depending on other project types in 6.0. Some notes: - If for 6.0 we end up with Java SE project supporting configurations and other projects don't, I would not make the configurations combo box visible in the main toolbar by default. - I like the idea with bold font for modified value, but I'm curious how it would work for other controls like check boxes, radio buttons, lists, etc.
Re. Run panel UI design: I'm no expert in GUI layout so it could probably use some visual tweaks. In particular I was unable to use GroupLayout (could not get component sizes to be sane no matter how hard I tried, and got tired of fighting Matisse) so I adapted the GridBagLayout that was there before. I believe other project types will use configs in 6.0. If not, we will figure out what to do then - just hide toolbar button, show it only when relevant projects are open, etc. Note: currently the Set Main Project Configuration menu item is simply disabled when there is no main project or the main project does not support configurations; it would be easy to hide it in this case, if desired, but I think UI convention is to leave it there disabled for discoverability. Re. bold font for modified values: true, this works only for text fields. A better solution applicable to other project types would be nice. Perhaps a standard "pencil writing something" icon badge could appear next to the label of a modified field. I don't know what UI precedent to use. Probably we can defer this decision until we see what Java EE projects want to do in this area. If there are no major objections to the current approach (SPI or basic GUI design) I would suggest merging to trunk on Friday and leaving the following week for bugfixes.
Jesse, if you could wait a few more days, I would discuss this proposal with HIEs working on Packs. This is a rather big UI change, so I want to be sure that it doesn't break anything. I hope during next week we should know their opinion. Thanks.
Sure, it can wait.
*** Issue 79053 has been marked as a duplicate of this issue. ***
I have two questions/suggestions. 1) What about adding a JVM selection to the Run pane? Having support for run profiles/configurations without a chance to change the JVM seems to me a bit incomplete:( Currently the project runs in the same Java platform the project was build against, but I can imagine a use case that you want to compile your app against one JVM and run it in another. You are for example building your app against 1.5 but wants to run/test it against both 1.5 and 1.6, or against the Sun or IBM implementations. 2) Please consider replacing "Set Configuration" menu item with "Run As...". I think it is the most convenient option for most users. One of the reasons I want to provide here is a bit j2ee centric and I don't know whether there is any similar use case in the j2se world. If I understand it correctly, the "Set Configuration" menu item is some kind of a shortcut to opening the project properties dialog and selecting the desired configuration in the Run pane. The Run action will then use the preselected configuration. It seems to me that this approach is well suited for cases when you are not switching the configuration very often, since otherwise you would always have to * pop up the context menu and select the desired configuration * pop up the context menu and run the project or use a hot key instead of simple * pop up the context menu and select 'Run as... desired configuration'. I think that if you had to do this often, it might become a bit frustrating. On the other hand, if you are switching the configuration only rarely, you won't save that much by switching it in the context menu instead of in the project properties. In the issue 82585 the user is developing a j2ee app and he is deploying it to a development server, but from time to time he wants to deploy it to a production server. Having to switch the configuration back and forth is, however, prone to accidental deploys to the production server instead of the development server. The 'Run As...' action would be more convenient for this use case.
sherold #1: a reasonable possibility but not covered by this issue. Currently building and running always use the same VM. If that were changed, independently, then of course the run configuration could specify a VM. sherold #2: also a possibility. See question #4 in the URL. Probably Run Main Project (or whatever) would need to pass a ProjectConfiguration in the context to ActionProvider.invokeAction. The UI would work fine for Java SE projects, and you say for EE projects as well; it might not work so well for ME and CND projects, where the configuration affects the build step, not just the run step. Perhaps this is not a real issue, or perhaps an analogous change could be made to the build actions. In any case I think Set Configuration needs to remain. I will investigate.
Rebasing branch to BLD200608201800.
To sherold #2: I have implemented such a feature in the branch, using a new API method in PCP: boolean configurationsAffectAction(String command); Unfortunately I have been unable to make the toolbar button look right, since it needs to really be a panel with two buttons in it, and Swing insists on drawing it with the wrong background. I tried everything I could think of: making the panel be an AbstractButton rather than JPanel (this works for a plain JToolBar but not for our o.o.awt.Toolbar), calling setBorderPainted(false) (which works but then makes it impossible to see a rollover effect), calling setOpaque(false) on both the panel and the buttons (no apparent effect). Probably someone with some Swing expertise could solve this and make it look right on all platforms, but I probably cannot do it so I would need some help. Anyway, if you want to try it, it is enabled if you pass -J-Dorg.netbeans.modules.project.ui.actions.MainProjectAction.SHOW_CONFIG_DROPDOWN=true It would be trivial to add similar functionality to either the main menus and/or the project context menu, since that involves no Swing hackery, but I don't think the functionality is wanted in those places (maybe I am wrong).
Demo builds available here: http://deadlock.nbextras.org/job/prj_configs_49636/
Checking in ant/project/apichanges.xml; /shared/data/ccvs/repository/ant/project/apichanges.xml,v <-- apichanges.xml new revision: 1.13; previous revision: 1.12 done Checking in ant/project/manifest.mf; /shared/data/ccvs/repository/ant/project/manifest.mf,v <-- manifest.mf new revision: 1.18; previous revision: 1.17 done Checking in ant/project/src/org/netbeans/spi/project/support/ant/ProjectProperties.java; /shared/data/ccvs/repository/ant/project/src/org/netbeans/spi/project/support/ant/ProjectProperties.java,v <-- ProjectProperties.java new revision: 1.17; previous revision: 1.16 done Checking in ant/project/src/org/netbeans/spi/project/support/ant/PropertyUtils.java; /shared/data/ccvs/repository/ant/project/src/org/netbeans/spi/project/support/ant/PropertyUtils.java,v <-- PropertyUtils.java new revision: 1.36; previous revision: 1.35 done Checking in ant/project/test/unit/src/org/netbeans/spi/project/support/ant/PropertyUtilsTest.java; /shared/data/ccvs/repository/ant/project/test/unit/src/org/netbeans/spi/project/support/ant/PropertyUtilsTest.java,v <-- PropertyUtilsTest.java new revision: 1.22; previous revision: 1.21 done Checking in java/j2seproject/nbproject/project.properties; /shared/data/ccvs/repository/java/j2seproject/nbproject/project.properties,v <-- project.properties new revision: 1.30; previous revision: 1.29 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/Bundle.properties; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/Bundle.properties,v <-- Bundle.properties new revision: 1.30; previous revision: 1.29 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEActionProvider.java; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEActionProvider.java,v <-- J2SEActionProvider.java new revision: 1.51; previous revision: 1.50 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEConfigurationProvider.java; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEConfigurationProvider.java,v <-- J2SEConfigurationProvider.java new revision: 1.2; previous revision: 1.1 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEProject.java; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/J2SEProject.java,v <-- J2SEProject.java new revision: 1.63; previous revision: 1.62 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl,v <-- build-impl.xsl new revision: 1.76; previous revision: 1.75 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/ActionFilterNode.java; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/ActionFilterNode.java,v <-- ActionFilterNode.java new revision: 1.11; previous revision: 1.10 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/J2SELogicalViewProvider.java; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/J2SELogicalViewProvider.java,v <-- J2SELogicalViewProvider.java new revision: 1.20; previous revision: 1.19 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/Bundle.properties; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/Bundle.properties,v <-- Bundle.properties new revision: 1.82; previous revision: 1.81 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerRun.form; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerRun.form,v <-- CustomizerRun.form new revision: 1.13; previous revision: 1.12 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerRun.java; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerRun.java,v <-- CustomizerRun.java new revision: 1.22; previous revision: 1.21 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/J2SECompositePanelProvider.java; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/J2SECompositePanelProvider.java,v <-- J2SECompositePanelProvider.java new revision: 1.3; previous revision: 1.2 done Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/J2SEProjectProperties.java; /shared/data/ccvs/repository/java/j2seproject/src/org/netbeans/modules/java/j2seproject/ui/customizer/J2SEProjectProperties.java,v <-- J2SEProjectProperties.java new revision: 1.59; previous revision: 1.58 done Checking in java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/J2SEConfigurationProviderTest.java; /shared/data/ccvs/repository/java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/J2SEConfigurationProviderTest.java,v <-- J2SEConfigurationProviderTest.java new revision: 1.2; previous revision: 1.1 done Checking in java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/ui/customizer/J2SEProjectPropertiesTest.java; /shared/data/ccvs/repository/java/j2seproject/test/unit/src/org/netbeans/modules/java/j2seproject/ui/customizer/J2SEProjectPropertiesTest.java,v <-- J2SEProjectPropertiesTest.java new revision: 1.2; previous revision: 1.1 done Checking in projects/projectapi/apichanges.xml; /shared/data/ccvs/repository/projects/projectapi/apichanges.xml,v <-- apichanges.xml new revision: 1.9; previous revision: 1.8 done Checking in projects/projectapi/manifest.mf; /shared/data/ccvs/repository/projects/projectapi/manifest.mf,v <-- manifest.mf new revision: 1.14; previous revision: 1.13 done Checking in projects/projectapi/src/org/netbeans/api/project/Project.java; /shared/data/ccvs/repository/projects/projectapi/src/org/netbeans/api/project/Project.java,v <-- Project.java new revision: 1.15; previous revision: 1.14 done Checking in projects/projectapi/src/org/netbeans/spi/project/ProjectConfiguration.java; /shared/data/ccvs/repository/projects/projectapi/src/org/netbeans/spi/project/ProjectConfiguration.java,v <-- ProjectConfiguration.java new revision: 1.2; previous revision: 1.1 done Checking in projects/projectapi/src/org/netbeans/spi/project/ProjectConfigurationProvider.java; /shared/data/ccvs/repository/projects/projectapi/src/org/netbeans/spi/project/ProjectConfigurationProvider.java,v <-- ProjectConfigurationProvider.java new revision: 1.2; previous revision: 1.1 done Checking in projects/projectui/arch.xml; /shared/data/ccvs/repository/projects/projectui/arch.xml,v <-- arch.xml new revision: 1.17; previous revision: 1.16 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/actions/Actions.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/actions/Actions.java,v <-- Actions.java new revision: 1.31; previous revision: 1.30 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/actions/ActiveConfigAction.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/actions/ActiveConfigAction.java,v <-- ActiveConfigAction.java new revision: 1.2; previous revision: 1.1 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/actions/Bundle.properties; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/actions/Bundle.properties,v <-- Bundle.properties new revision: 1.32; previous revision: 1.31 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/actions/MainProjectAction.java; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/actions/MainProjectAction.java,v <-- MainProjectAction.java new revision: 1.16; previous revision: 1.15 done Checking in projects/projectui/src/org/netbeans/modules/project/ui/resources/layer.xml; /shared/data/ccvs/repository/projects/projectui/src/org/netbeans/modules/project/ui/resources/layer.xml,v <-- layer.xml new revision: 1.70; previous revision: 1.69 done Checking in projects/projectuiapi/apichanges.xml; /shared/data/ccvs/repository/projects/projectuiapi/apichanges.xml,v <-- apichanges.xml new revision: 1.23; previous revision: 1.22 done Checking in projects/projectuiapi/nbproject/project.properties; /shared/data/ccvs/repository/projects/projectuiapi/nbproject/project.properties,v <-- project.properties new revision: 1.24; previous revision: 1.23 done Checking in projects/projectuiapi/src/org/netbeans/modules/project/uiapi/ActionsFactory.java; /shared/data/ccvs/repository/projects/projectuiapi/src/org/netbeans/modules/project/uiapi/ActionsFactory.java,v <-- ActionsFactory.java new revision: 1.11; previous revision: 1.10 done Checking in projects/projectuiapi/src/org/netbeans/spi/project/ui/support/CommonProjectActions.java; /shared/data/ccvs/repository/projects/projectuiapi/src/org/netbeans/spi/project/ui/support/CommonProjectActions.java,v <-- CommonProjectActions.java new revision: 1.15; previous revision: 1.14 done
I do not like the big disabled combobox in Build toolbar for Free form or j2ee projects. Is there any plan to hide or use it? Or is it another 'boring' ui element such as always displayed 'Web Services' node in j2se project?
Re. disabled combo (feel free to file fresh lower-priority issues): 1. It is possible to hide it when inactive but I did not manage to reclaim the space it took up in the toolbar, so that looked even weirder. Maybe someone else would know how to make the toolbar button really disappear. 2. There are no plans to use it for Java EE projects in 6.0 that I know of, but they could use it in the future. 3. It could in principle be used for freeform projects but I am not sure exactly what it should do. Set an Ant property, I guess, but where would the list of valid property values come from? There are a few different possibilities.
Created attachment 34320 [details] a possible solution to show/hide the active configuration combo in the main toolbar
saubrecht: if you want to test and commit a patch to hide the toolbar when disabled, go ahead (just check with Jano first).
I checked the patch and I think the hiding behavior is acceptable from UI point of view. The patch contains a bug, which makes the disabled combo visible after the first start with empty user dir.
i've integrated fixed patch into trunk Checking in ActiveConfigAction.java; /cvs/projects/projectui/src/org/netbeans/modules/project/ui/actions/ActiveConfigAction.java,v <-- ActiveConfigAction.java new revision: 1.5; previous revision: 1.4 done
*** Issue 87882 has been marked as a duplicate of this issue. ***
*** Issue 90063 has been marked as a duplicate of this issue. ***
*** Issue 90797 has been marked as a duplicate of this issue. ***
I really like the configuration stuff! Thanks! In our configurations, however, we often use a lot of options. It would be nice if, in the editor dialog, there would be a way to show more information. I think the older versions on NB had a way (like shift-F2 maybe) to popup a window with a text area in it for typing multi-line content. I think it would be helpful to have way to see more characters at a time. That being said, once the configuration is made, it is really only a matter of editing the properties file that is created. Doing this, the whole netbeans properties editor is at my disposal.
mclaassen: I guess you are asking that the Run panel of the j2seproject properties dialog permit multiline display for e.g. Command-Line Arguments or VM Options? This would I think be easy enough, although people might then be confused as to whether they should use newlines or spaces to separate arguments. Anyway, this would be a separate RFE, as it is not really related to the existence of run configurations.
Done. http://www.netbeans.org/issues/show_bug.cgi?id=94019
*** Issue 105195 has been marked as a duplicate of this issue. ***
I'm not sure how this issue can be considered RESOLVED/FIXED, since at best only half of the enhancements (run configurations) described in the initial description of this issue have been addressed as of NB 6.1. There is still nothing in the way of support for multiple build configurations, nor have I been able to find anything in the available FAQs, tutorials or other documentation that provides any help for moving a J2SE project from development to production.
krahe: please do not reopen. It is possible to use the same mechanism for build configurations, though the GUI customizer currently does not support it (and there are not plans to add such support to the GUI for now); in particular, any GUI which permitted you to switch intrinsic properties such as compile classpath or source level would be undesirable. Please use nbusers@netbeans.org for help with specific issues. ("Moving from development to production" is pretty vague.)
I have had a good experience with the build/run configurations. The items in the nbproject/configs directory can be created and edited manually. They are just properties files and anything can be put in there. It is also loaded very early in the build process so it is a good place to override any properties you want to.
I was able to use the run configurations to set build options, though I had to jump through some hoops to prevent values set in private.properties from overriding configuration-specific values (e.g. javac.debug). I have yet to test setting configuration-specific values for classpath file references, but I suspect these will be easier to deal with than javac.debug since they usually don't find their way into private.properties. I'm still amazed at how difficult NetBeans makes it to define predictable, repeatable build configurations, but at least I know it can finally be done.
*** Issue 72446 has been marked as a duplicate of this issue. ***