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 64618 - [50cat] Module Suite Project: VM Options and Arguments in Project Properties Dialog
Summary: [50cat] Module Suite Project: VM Options and Arguments in Project Properties ...
Status: NEW
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker with 11 votes (vote)
Assignee: Martin Kozeny
URL:
Keywords: UI
: 96522 110036 182247 (view as bug list)
Depends on: 64590
Blocks:
  Show dependency tree
 
Reported: 2005-09-18 22:12 UTC by lordy
Modified: 2013-02-14 13:17 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description lordy 2005-09-18 22:12:26 UTC 
[ BUILD # : 200509151800 ]
[ JDK VERSION : 1.5.0_02 ]

In Module Suite Project you can't the VM Options and Arguments in 
the Project Properties Dialog. So things like "-J-Xms24m -J-
Xmx64m" must be edit in etc/feedreader.conf as example. And 
evertime you generate the project you must edit it again. 

Here i think is caution needed. Form a Module Suite Project are not 
only ZIP Application generated. Also JNLP can be generated. And by 
JNLP not all VM Options can use: http://java.sun.com/j2se/1.5.0/
docs/guide/javaws/developersguide/syntax.html#resources
Comment 1 Jesse Glick 2005-09-19 22:49:33 UTC 
Not in 5.0.
Comment 2 Jesse Glick 2006-02-06 20:33:52 UTC 
Not implemented in time for 5.0u1, sorry.
Comment 3 Jesse Glick 2006-02-16 22:42:23 UTC 
Should work set to set in suite project.properties e.g.

run.args.extra=-J-Dfoo=bar -J-Xmx256m
Comment 4 Rich Unger 2006-02-21 19:55:29 UTC 
Is this issue for etc/myapp.conf file in the build-zip, or for the 'run' ant
target, or both?
Comment 5 Jesse Glick 2006-02-21 22:29:50 UTC 
Probably just for the 'run' Ant target. Of course the build harness could append
those args to the app.conf file when building a ZIP, but I wouldn't want to
hazard a guess as to what fraction of the time this would be correct! If you
have special needs for your app's launcher you are as always advised to write
your own target to build it, using the harness' default target as a starting point.
Comment 6 Jesse Glick 2007-02-26 18:46:55 UTC 
*** Issue 96522 has been marked as a duplicate of this issue. ***
Comment 7 Jesse Glick 2007-07-17 16:43:44 UTC 
*** Issue 110036 has been marked as a duplicate of this issue. ***
Comment 8 Jesse Glick 2007-07-17 16:44:33 UTC 
After feature freeze.
Comment 9 tomwheeler 2008-09-09 00:09:28 UTC 
This has come up on the mailing list a few times recently.  

Although one could manually add a target to replace or update the .conf file to use a similar setting in the ZIP
distribution, each developer must reinvent the target to do the same thing.  I agree it would be a very nice feature to
have in the IDE.

If implemented and the tools support does not also update the run.args.extra property in the suite, then at least the
help page should mention that this setting is for ZIP distributions only and does not affect when run from the IDE.
Comment 10 _ wadechandler 2008-12-20 16:32:17 UTC 
Seems there needs to be another value along with run.args.extra something like run.args.extra.perm which gets propagated
to the final build. Then run.args.extra and run.args.extra.perm can be merged, and that can allow folks to have some
options specific to development. It would be best to use run.args.dev and run.args.perm/prod or something, but .extra is
already in use with the scenario it supports, and that scenario still exists; there are some options one would just want
to use at development time instead of production, and of course there are options one wants set in the file at
deployment of the application. For instance, a non-visual application will always want to have the splash screen turned
off. Applications which do not allow their users to add other modules will most likely want a specific min and max
memory for the application to make it work best for what it does. So, I strongly believe there needs to be two concepts
supported by two variables.
Comment 11 _ wadechandler 2008-12-20 16:33:39 UTC 
Too, both options should be supported in the suites UI.
Comment 12 puce 2009-02-06 16:08:04 UTC 
In harness/jnlp.xml I found that "run.args" is used for the "run-jnlp" (suite.xml)/ "run" (jnlp.xml) target.
Unfortunatly, I couldn't find any documentation about it, and it isn't used in the "build-jnlp" target either, so it
doesn't make it into master.jnlp.
Comment 13 puce 2009-02-06 18:18:34 UTC 
I filed the following issue:
http://www.netbeans.org/issues/show_bug.cgi?id=158098

which is related to this one.
Comment 14 Jaroslav Tulach 2010-01-27 08:09:38 UTC 
"So things like "-J-Xms24m -J-Xmx64m" must be edit in etc/feedreader.conf as example. And  evertime you generate the project you must edit it again" - this is horrible and I needed to solve it as part of bug #179388 too. I've introduced new property app.conf which (if set to feedreader.conf) would allow one to provide completely own version of the config file in ${suiter.dir}/feedreader.conf.
Comment 15 Jesse Glick 2010-03-18 01:39:21 UTC 
*** Bug 182247 has been marked as a duplicate of this bug. ***