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 199053 - Active Grails Environment should allow for custom environment settings
Summary: Active Grails Environment should allow for custom environment settings
Status: NEW
Alias: None
Product: groovy
Classification: Unclassified
Component: Editor (show other bugs)
Version: 7.0
Hardware: PC Other
: P3 normal with 4 votes (vote)
Assignee: Martin Janicek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-05-31 19:10 UTC by mj.homeschool
Modified: 2016-02-12 11:17 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mj.homeschool 2011-05-31 19:10:12 UTC
Currently, the only official means of setting the environment variable is to go into the project properties and change the Active Grails Environment. This field is limited to the default environments (Development, Test, Production).

Grails offers the flexibility of creating custom environments as well. The feature can be used to permit different data sources, specific bootstrap operations, etc. This can be set in the command line with "-Dgrails.env=", in the format "grails -Dgrails.env=development run-app". In such cases, there might be multiple dev, test, and production configurations (under different environment names.)

The NetBeans commands currently pass the environment from the project properties in the format "grails dev run-app", which conflicts with the above command-line parameter. Grails appears to accept the user-defined option in most cases, reading "grails dev -Dgrails.env=customenv run-app" the same as "grails -Dgrails.env=customenv run-app", as a workaround. However, when also setting JVM options, the Grails engine incorrectly interprets the conflicting setting as the Grails command, attempting to run "Dev" or "Test", rather than "run-app".

Rather than treat this as a bug, it seems like the best option would be to work on an enhancement where the "Run Grails Command" dialog allows the user to select the environment for this command, or specify a custom environment name. The environment would then be passed to the grails command as the parameter "grails.env", rather than the aforementioned "dev"/"test"/"prod" shortcuts. Entering this parameter in the "Parameters" field would override the selected setting.

In this case, the order of priority would be
1. The value entered in the "Parameters" field for "grails.env".
2. The selection in this new dropdown in the "Run Grails Command" dialog, or if "Custom" is selected, the value entered.
3. The Active Grails Environment (if none is selected.)

For quick-run options, like "Run" and "Test", the format of "grails Test test-app" would still be appropriate.