I would like to set some environment variables for a NetBeans Platform app. Is there a clean way of doing this so the environment variables are set when I start the app without having to write a custom startup script? I'm doing this on a linux environment.
https://netbeans.org/features/platform/
If you want to pass arguments/commandline parameters to the NetBeans Platform app during startup, you can pass those parameters either directly to the launcher or via the etc/<brandingname>.conf file which is located in the distribution of the application. There you can determine any options via the default_options attribute. Example-
default_userdir="${HOME}/.${APPNAME}/user"
default_cachedir="${HOME}/.${APPNAME}/cache"
default_options="-J-client -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-ea --branding mybrandingcluster"
jdkhome="jre"
Furthermore, you can separately assign the path of the Java
Platform, the user directory, and additional clusters in this file.
If you are looking forward to save environment variables specific to your application you can use the NbPreferences API. Detailed example is listed in Geertjan´s blog
Related
I have EJBs deployed on several different servers, for different environments. I have many projects that use these EJBs. I usually just run my projects against the DEV server EJBs, but sometimes I need to run against the TEST or PROD environment EJBs. This necessitates having to comment out all of the DEV nodes in my jboss-client-ejb.properties file and uncomment all of the TEST nodes. But then if I forget to change them back, I may mess up some data if I run it later. What I would like to do is create a different runtime configuration for each environment, and have each runtime config use a different version of the jboss-client-ejb.properties. Is there a way to do this? If so how? I have looked at all of properties of a run configuration, and don't see anything helpful.
In eclipse preferences search for string variable substitution. Here create variables that point to multiple config files for each of your environments. Then create multiple run configurations and for each one (like dev or prod) add a program argument that points to your string variable defined in your preferences like this -DmyconfigFile={$MyDevPropertiesFilePath}, or you could hard code the config path and have multiple runtime configurations that use different config files. Key point here is create multiple runtime launch configurations for each environment and add the properties for each environment that point to the config file respective to each environment. This way you can easily select the launch menu and decide to run "dev" "prod" or whatever you name your multiple configurations. Trying to do this with one runtime configuration will cause pain as you say, because it is easy to forget to revert or change the config file you want to to use. Hope that helps. Also if you create a new workspace you can export your runtime configurations using the export wizard which is also helpful for passing on to other developers or putting in source control.
P.S Looking more at your question you wan to pass in the config file path as a program argument, you are correct there are no specific options for setting this file path. Using program arguments with multiple launch configurations.
Can I set a workspace wide setting to add an environment variable to all future launchers created in the workspace?
Use Case
Our unit tests require an environment variable to guide the test to certain resources.
the variable varies with each version of our product
Options
- modify each junit launcher with the environment variable
- create start up script that sets variable and launches eclipse
- set globally
Ideally, I'd like to provide a way for users to set it once per workspace.
Does eclipse have a place to set an environment variable for all launchers?
Thanks
Peter
Only option which I can think of is similar to yours where you can create multiple shell scripts(linux) or batch files(windows) and set it up there. for ex -
I am giving examples for windows environment and same can be done for Linux as well -
for windows-
eclipse.exe -DvariableName1=value1 -DvariableName2=value2
As you want to pass different variables to different workspaces, you can also pass location of your workspace as part of arguments.
eclipse.exe -data <your_workspace_location> -DvariableName1=value1 -DvariableName2=value2
You can create multiple shortcuts of eclipse.exe in windows and place them on Desktop (for quick access) if needed. Each shortcut may point to a similar variant of above command with different workspace and different variables.
Hope this helps. Happy coding :)
I have a different approach for doing this on windows. This solution allows you to store a large number of environment variables to one place and apply them globally inside eclipse.
I have gitBash installed already, and associated in windows to execute .bash files
I set up a /c/Temp/.env file with lots of environment variables in the format
export VARIABLE=my value
I create an eclipse_startup.bash script that looks like this (and pin it to my start menu).
echo setting up env
. /c/Temp/.env
echo starting eclipse
/c/Users/me/eclipse-oxygen/eclipse/eclipse.exe
It has the disadvantage that I end up with a bash window open with eclipse, and I have to restart after changing the environment. On the plus side, my complex application has lengthy environment files already, so I can simply load them in and start.
I am enabling internationalization for my RCP application. The preferences tab allows the user to select between languages. I understand that Eclipse (3.7) has to load the language at start-up and can not dynamically change languages.
I know of three approaches to accomplish this:
1) Modify the OS level shortcut to pass in -nl XX
2) Change the app.ini file to have -nl XX (on separate lines)
3) Change the config.ini to have osgi.nl = XX
The issue with these approaches is that they all require write permission to the application directory. When running under Vista / Windows 7 and Linux implementations that do not provide write access to programs, a normal user does not have permissions to modify these files.
Is there another approach to pass in arguments that change the VM language? Is there a workaround for the file protection provided by the OS?
In Windows the application directory is write-protected for a good reason. Fortunately one can set Eclipse Runtime Options to configure where the RCP application should store
configuration data
workspace data
This can be accomplished in two ways:
setting command line arguments (-configuration , -data)
defining system properties (osgi.configuration.area to , osgi.instance.area to ) for example in config.ini
For further information see Runtime Options in official Eclipse Help.
In Windows such data should be stored in the user directory.
By the way you should be able to locate these settings in the Installation Details pane of the standard About dialog.
However setting these properties is a bit tricky. In my case the application installer evaluates the location of the user directory at installation time and modifies the config.ini file accordingly.
I'm using NAnt to build an ASP.NET MVC project.
The NAnt script then creates a zip package, containing a deploy script and all the necessary files.
The deploy script backs up the current running website, sets up the newer version of the website and updates the DB.
This works fine for a single environment.
However, we're asked more and more to set up a Staging/Acceptance environment next to the production. These environments, of course, differ in file structure, DB server, config settings etc.
How can I best handle this in the deploy scripts? I don't want to create separate variables for each environment, distinguishable by name only.
Providing defaults and providing the variables in separate files seems more logical.
Does anyone have practical experiences with this?
Store the things that you think are likely to change between environments in config files.
Visual Studio can do the heavy lifting here if you like; you can create settings and specify default values from the Settings tab of a Visual Studio project's properties.
This will create the config file for you and provide strongly-typed access through Properties.Settings.Default.
As for handling multiple environments through your build, I've seen some people recommend maintaining multiple copies of the config files - one for each environment for example - and others recommend using nant to modify the config files during the build or deployment phase. You can use a property passed to nant on the command line (for example) to select which environment you are building (or deploying, depending on how you're doing it).
I don't recommend either of these approaches because:
They both require changes to your build to support new environments.
If you change a setting in a deployed environment and forget to update the build then the next deployment will reset the change (somewhat defeating the point of config settings).
If someone creates a new environment (lets say they want to explore issues arising from upgrading to a new version of SQL Server for example) and doesn't fancy creating all new config files in the build system, they might decide to just use an existing environment's settings. Let's say they choose to deploy using the live settings and forget to change something afterwards. Your new 'test' environment could now be pointing to live kit.
I create a copy of each config file (called web.config.example, for example) and comment out the settings within them (unless they have meaningful defaults). I check these in and have those deployed instead of the real web.config (that is, web.config is NOT deployed automatically. web.config.example is deployed as web.config.example.
The admin of the new environment will have to copy and rename the file to web.config and provide meaningful values). I also put all the calls to the settings behind my own wrapper class - if a mandatory setting is missing I throw an exception.
The build and my environments no longer depend on each other - one build can be deployed to any environment.
If a setting is missing (a new environment or a new setting in an existing environment) then you get a nice clear exception raised to tell the admin what to do.
Existing settings are not altered after an upgrade because only the .example files were updated. It's an admin task to compare the current settings with the latest example and revise if necessary.
To configure the deployment, you could put all the environmental settings (install paths, etc) into nant properties and move them into a separate file (settings.build for example) then use the nant include task to include that file at the top of your deployment file (deploy.build for example). You can then deploy a new version of deploy.build without overwriting your config changes as they are in settings.build. If a new property is introduced into deploy.build nant will fail with a nice message to tell you that you haven't set that property.
I am developing a logging framework using Log4j. I am not able to figure out how to maintain separate log files for different environment, i.e., development, testing, staging and production.
Firstly you'll need a different copy of your log4j.xml for each environment.
Lets call it log4j-dev.xml, log4j-test.xml, log4j-stage.xml and log4j-prod.xml each having their own settings like log file name and log levels.
You then pass in the corresponding file at the the server startup as a system property like below -
-Dlog4j.configuration=log4j-dev.xml
This URL has the example on how to pass this for Tomcat. The concept is the same for whichever server you are deploying on.
On Windows, I have used "set CATALINA_OPTS=-Dlog4j.configurationFile=log4j2-dev.xml" instead of log4j.configuration