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.

Bug 49636 - [50cat] Build/run configurations for j2seproject's
Summary: [50cat] Build/run configurations for j2seproject's
Alias: None
Product: java
Classification: Unclassified
Component: Project (show other bugs)
Version: 4.x
Hardware: All All
: P1 blocker with 17 votes (vote)
Assignee: apireviews
: 8845 34513 48709 51036 51825 52199 52747 54474 56402 59913 60786 61252 65076 66748 72446 72994 79053 87882 90063 90797 (view as bug list)
Depends on: 49652 90801
Blocks: 41537 81790
  Show dependency tree
Reported: 2004-09-28 16:32 UTC by Jesse Glick
Modified: 2008-08-22 18:17 UTC (History)
25 users (show)

See Also:
Exception Reporter:

multiple run profiles in Eclipse 3.x (2 profiles in pic: 1. CountCorpus, 2. ErgoSum) (20.34 KB, image/jpeg)
2005-05-18 01:55 UTC, arthit
Proposed patch (115.24 KB, patch)
2006-06-15 21:43 UTC, Jesse Glick
Details | Diff
A picture is worth cca. 1kLOC (70.67 KB, image/png)
2006-06-19 17:03 UTC, Jesse Glick
a possible solution to show/hide the active configuration combo in the main toolbar (3.70 KB, patch)
2006-09-21 17:23 UTC, Stanislav Aubrecht
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-09-28 16:32:22 UTC
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 have e.g.


and in either or have e.g.


(need to do some tricks because Ant does not allow
recursive property substitution). Could also have
separate and files, but the above style
seems to work for J2ME and is straightforward enough.

GUI style not so clear.
Comment 1 Jesse Glick 2004-11-01 21:08:13 UTC
*** Issue 51036 has been marked as a duplicate of this issue. ***
Comment 2 Jesse Glick 2004-11-12 23:39:53 UTC
*** Issue 34513 has been marked as a duplicate of this issue. ***
Comment 3 Jesse Glick 2004-11-22 18:35:23 UTC
*** Issue 48709 has been marked as a duplicate of this issue. ***
Comment 4 Jesse Glick 2004-11-29 21:39:25 UTC
*** Issue 51825 has been marked as a duplicate of this issue. ***
Comment 5 Jesse Glick 2004-12-01 19:36:51 UTC
*** Issue 8845 has been marked as a duplicate of this issue. ***
Comment 6 Jesse Glick 2004-12-15 19:25:36 UTC
*** Issue 52199 has been marked as a duplicate of this issue. ***
Comment 7 Jesse Glick 2005-03-15 15:14:25 UTC
*** Issue 56402 has been marked as a duplicate of this issue. ***
Comment 8 Jesse Glick 2005-04-06 20:02:17 UTC
*** Issue 54474 has been marked as a duplicate of this issue. ***
Comment 9 clever 2005-05-02 18:30:34 UTC
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?)
- Specify parameters for any main() class

The frustrating thing is that feature did exist in NB3.X. Now it's gone!
Comment 10 Jesse Glick 2005-05-02 19:56:18 UTC
[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.
Comment 11 arthit 2005-05-18 01:55:31 UTC
Created attachment 22172 [details]
multiple run profiles in Eclipse 3.x (2 profiles in pic: 1. CountCorpus, 2. ErgoSum)
Comment 12 arthit 2005-05-18 02:04:42 UTC
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.
Comment 13 arthit 2005-05-18 02:13:44 UTC
Verson -> 4.1 (current one)
CC reporters of duplicated issues.
Comment 14 Tomas Zezula 2005-05-18 07:49:56 UTC
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.
Comment 15 Jesse Glick 2005-05-18 17:59:52 UTC
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.
Comment 16 Jesse Glick 2005-06-14 12:51:51 UTC
*** Issue 59913 has been marked as a duplicate of this issue. ***
Comment 17 Jesse Glick 2005-07-13 22:33:10 UTC
*** Issue 60786 has been marked as a duplicate of this issue. ***
Comment 18 bantunes 2005-07-14 10:25:08 UTC
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
Comment 19 Jesse Glick 2005-10-10 19:29:27 UTC
*** Issue 61252 has been marked as a duplicate of this issue. ***
Comment 20 clever 2005-11-21 16:09:53 UTC
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.
Comment 21 Tomas Zezula 2005-11-21 16:41:25 UTC
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.
Comment 22 Jan Lahoda 2006-01-22 15:20:01 UTC
*** Issue 65076 has been marked as a duplicate of this issue. ***
Comment 23 bruehlicke 2006-01-25 16:44:15 UTC
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.)

Comment 24 Tomas Zezula 2006-01-26 09:33:06 UTC
I've agree that this task has a higher priority. I've increased the priority to
P1 since it has more than 20 votes.
Comment 25 Jesse Glick 2006-02-01 16:18:45 UTC
*** Issue 52747 has been marked as a duplicate of this issue. ***
Comment 26 Jesse Glick 2006-02-03 16:51:16 UTC
*** Issue 66748 has been marked as a duplicate of this issue. ***
Comment 27 krahe 2006-02-03 17:07:14 UTC
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.
Comment 28 arthit 2006-02-05 21:17:13 UTC
target 5.5 ?
Comment 29 smil 2006-03-09 22:15:49 UTC
*** Issue 72994 has been marked as a duplicate of this issue. ***
Comment 30 _ wadechandler 2006-03-09 23:49:38 UTC
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?
Comment 31 Jesse Glick 2006-03-10 01:23:15 UTC
Wade: what you are talking about has nothing to do with this RFE at all.
Comment 32 _ wadechandler 2006-03-10 02:34:14 UTC
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.
Comment 33 Jesse Glick 2006-06-14 16:16:12 UTC
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
Comment 34 Jesse Glick 2006-06-14 23:43:43 UTC
Also need to branch ant/project, it turns out.
Comment 35 Jesse Glick 2006-06-15 20:58:49 UTC
Jano et al.: please see the linked-to proposal for a description of the proposed
Comment 36 Jesse Glick 2006-06-15 21:43:37 UTC
Created attachment 31098 [details]
Proposed patch
Comment 37 Jesse Glick 2006-06-15 21:45:20 UTC
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.
Comment 38 jrojcek 2006-06-19 09:10:22 UTC
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.
Comment 39 tlund 2006-06-19 11:52:29 UTC
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.
Comment 40 Jesse Glick 2006-06-19 17:03:24 UTC
Created attachment 31162 [details]
A picture is worth cca. 1kLOC
Comment 41 Jesse Glick 2006-06-19 17:16:59 UTC
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.
Comment 42 mclaassen 2006-06-19 19:26:26 UTC
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?
Comment 43 Jesse Glick 2006-06-19 19:47:02 UTC
I do not expect this RFE will be put into 5.5. It is under discussion for 6.0.
Comment 44 jrojcek 2006-06-22 16:04:22 UTC
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. 
Comment 45 Jesse Glick 2006-06-22 22:02:20 UTC
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

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.
Comment 46 jrojcek 2006-06-23 09:07:37 UTC
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.
Comment 47 Jesse Glick 2006-06-23 15:51:29 UTC
Sure, it can wait.
Comment 48 Jesse Glick 2006-06-28 17:20:21 UTC
*** Issue 79053 has been marked as a duplicate of this issue. ***
Comment 49 Sherold Dev 2006-08-17 18:27:04 UTC
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

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

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.
Comment 50 Jesse Glick 2006-08-17 19:51:14 UTC
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.
Comment 51 Jesse Glick 2006-08-21 21:36:32 UTC
Rebasing branch to BLD200608201800.
Comment 52 Jesse Glick 2006-08-29 00:42:07 UTC
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


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).
Comment 53 Jesse Glick 2006-08-29 16:30:33 UTC
Demo builds available here:
Comment 54 Jesse Glick 2006-09-08 19:34:03 UTC
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
Checking in ant/project/;
/shared/data/ccvs/repository/ant/project/,v  <--
new revision: 1.18; previous revision: 1.17
Checking in
new revision: 1.17; previous revision: 1.16
Checking in ant/project/src/org/netbeans/spi/project/support/ant/;
new revision: 1.36; previous revision: 1.35
Checking in
new revision: 1.22; previous revision: 1.21
Checking in java/j2seproject/nbproject/;
new revision: 1.30; previous revision: 1.29
Checking in
new revision: 1.30; previous revision: 1.29
Checking in
new revision: 1.51; previous revision: 1.50
Checking in
new revision: 1.2; previous revision: 1.1
Checking in
new revision: 1.63; previous revision: 1.62
Checking in
 <--  build-impl.xsl
new revision: 1.76; previous revision: 1.75
Checking in
new revision: 1.11; previous revision: 1.10
Checking in
new revision: 1.20; previous revision: 1.19
Checking in
new revision: 1.82; previous revision: 1.81
Checking in
 <--  CustomizerRun.form
new revision: 1.13; previous revision: 1.12
Checking in
new revision: 1.22; previous revision: 1.21
Checking in
new revision: 1.3; previous revision: 1.2
Checking in
new revision: 1.59; previous revision: 1.58
Checking in
new revision: 1.2; previous revision: 1.1
Checking in
new revision: 1.2; previous revision: 1.1
Checking in projects/projectapi/apichanges.xml;
/shared/data/ccvs/repository/projects/projectapi/apichanges.xml,v  <-- 
new revision: 1.9; previous revision: 1.8
Checking in projects/projectapi/;
/shared/data/ccvs/repository/projects/projectapi/,v  <--
new revision: 1.14; previous revision: 1.13
Checking in projects/projectapi/src/org/netbeans/api/project/;
new revision: 1.15; previous revision: 1.14
Checking in
new revision: 1.2; previous revision: 1.1
Checking in
new revision: 1.2; previous revision: 1.1
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
Checking in
new revision: 1.31; previous revision: 1.30
Checking in
new revision: 1.2; previous revision: 1.1
Checking in
new revision: 1.32; previous revision: 1.31
Checking in
new revision: 1.16; previous revision: 1.15
Checking in
 <--  layer.xml
new revision: 1.70; previous revision: 1.69
Checking in projects/projectuiapi/apichanges.xml;
/shared/data/ccvs/repository/projects/projectuiapi/apichanges.xml,v  <-- 
new revision: 1.23; previous revision: 1.22
Checking in projects/projectuiapi/nbproject/;
new revision: 1.24; previous revision: 1.23
Checking in
new revision: 1.11; previous revision: 1.10
Checking in
new revision: 1.15; previous revision: 1.14
Comment 55 ehucka 2006-09-20 10:11:01 UTC
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?
Comment 56 Jesse Glick 2006-09-21 00:05:25 UTC
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.
Comment 57 Stanislav Aubrecht 2006-09-21 17:23:54 UTC
Created attachment 34320 [details]
a possible solution to show/hide the active configuration combo in the main toolbar
Comment 58 Jesse Glick 2006-09-21 17:57:29 UTC
saubrecht: if you want to test and commit a patch to hide the toolbar when
disabled, go ahead (just check with Jano first).
Comment 59 jrojcek 2006-09-26 16:22:58 UTC
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.
Comment 60 Stanislav Aubrecht 2006-10-11 15:15:47 UTC
i've integrated fixed patch into trunk

Checking in;
new revision: 1.5; previous revision: 1.4
Comment 61 Jesse Glick 2006-10-24 17:26:53 UTC
*** Issue 87882 has been marked as a duplicate of this issue. ***
Comment 62 Jesse Glick 2006-11-27 20:16:57 UTC
*** Issue 90063 has been marked as a duplicate of this issue. ***
Comment 63 Jesse Glick 2006-12-08 15:47:05 UTC
*** Issue 90797 has been marked as a duplicate of this issue. ***
Comment 64 mclaassen 2007-02-02 16:49:06 UTC
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.

Comment 65 Jesse Glick 2007-02-02 18:32:39 UTC
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.
Comment 66 mclaassen 2007-02-02 18:47:27 UTC
Comment 67 Jesse Glick 2007-05-31 17:28:14 UTC
*** Issue 105195 has been marked as a duplicate of this issue. ***
Comment 68 krahe 2008-06-09 23:19:42 UTC
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.
Comment 69 Jesse Glick 2008-06-09 23:39:37 UTC
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 for help with specific issues. ("Moving from development to production"
is pretty vague.)
Comment 70 mclaassen 2008-06-10 13:39:01 UTC
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.
Comment 71 krahe 2008-06-11 03:33:59 UTC
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 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

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.
Comment 72 Jesse Glick 2008-08-22 18:17:32 UTC
*** Issue 72446 has been marked as a duplicate of this issue. ***