Community
Participate
Working Groups
It'd be very helpful if the launcher would support the insertion of environment variables in the <launcher>.ini. Whatever form might make sense(e.g. @ENV, % ENV%, ${ENV}, ${env_var:ENV}) e.g. something like -vm ${MYRCPAPP_VM} -mx${MYRCPAPP_HEAPSIZE}
The launcher is written in C. The code is in the platform-launcher project.
*** Bug 94087 has been marked as a duplicate of this bug. ***
*** Bug 215020 has been marked as a duplicate of this bug. ***
*** Bug 224091 has been marked as a duplicate of this bug. ***
Hi there, I'm attaching a patch to org.eclipse.core.runtime.adaptor.LocationManager (from plug-in org.eclipse.osgi) adding support for @env.ANY_ENV_VAR syntax. This works for location specified both on the command line or in the eclipse.ini file. For instance, -vmargs -Dosgi.instance.area.default=@env.HOMEDRIVE\@env.HOMEPATH\workspace provides a more user-friendly default location for the workspace in our deployment environment on Windows. This is not entirely foolproof: @env{ANY_ENV_VAR} would be a much better syntax but I wanted to stay close to the @user.home/@user.dir ones. Something to build on anyway (hopefully) I've been missing and worked around this feature for a while now. just by looking at the number of duplicates, I can see I'm not the only one. Hope this helps.
Created attachment 144200 [details] Patch to LocationManager adding support for environment variables
If this is expected to work for all properties, in particular, the various osgi.configuration.*, osgi.install.area, osgi.framework*, and some others, then this would also need to be handled in org.eclipse.equinox.launcher's Main. As well, the original comment #0, wants this on any argument including the vm, vmargs etc, in which case this would need to happen in the native code.
Personnaly, I miss environment variables most for user-specific settings (I feel the JVM location and associated options are more machine-specific and can therefore be sorted on installation) although extending this to all command line arguments would be nice.
Also, the patch does not compile for me because it uses methods/classes not in the OSGi/Minimum-1.2 execution environment. To see this yourself, go to your Preferences -> Java -> Installed JREs -> Add -> Execution Environment Description Point at org.eclipse.osgi/osgi/OSGi_Minimum-12.ee. Click ok, then go back to Installed JREs -> Execution Environments in the preference tree, select OSGi/Minimum-1.2 and check the jre you just added. You then may need to right click on the osgi project and do PDE Tools -> update class path.
Fair enough. The same code without regex support is going to be horrible and error-prone. Let's forget it then...
Hi eclipse.org, I got sufficiently annoyed by this bug that I actually resolved myself to write a fix for it in C, as requested. It hurt... Anyway, attached is a patch to eclipeConfig.c to dereference environment variables in the form of ${var} I have tested this on Windows (32-bit) and Linux (64-bit) and the code looks sufficiently bland to make me believe it should compile on most platforms. I left test-code in the patch to show the cases this patch covers to help reviewers spot shortcomings. Of course this should not remain where it is now. Hope this helps, Romain
Created attachment 162768 [details] Patch to eclipseConfig.c to dereference environment variables
Created attachment 162794 [details] Eclipse patch Here is a eclipse workspace patch of the same code with the string stuff changed to the macros (_TCHAR, _tcsstr, _tcscat, etc). I haven't tried running it. First comment is that we don't rescan the replaced string. Do we want to support something like this: USER = person ROOT = ${USER}/eclipse ${ROOT}/workspace -> ${USER}/eclipse/workspace -> person/eclipse/workspace
Hi Romain, thanks for the patch, this was discussed on the Equinox call during M7 but I forgot to make a note here. It was decided to wait until 3.7 before releasing it. We are now into the first release candidates for 3.6 and want to avoid making changes to the launcher if possible.
Thanks for the update. For the benefit of anyone waiting on this and not requiring environment variables dereferencing for the JVM location, there is a simple way to implement this in Java alone: write the code in Java and have the native launcher calling out to your class using the -startup option. Once all the environment variables expanded, call out to org.eclipse.equinox.launcher.Main located in plugins/org.eclipse.equinox.launcher_w.x.y.z.jar I'm sure there are disadvantages in doing it this way (and also benefits, for one can do more arguments/pre-startup processing without going back to C), but I thought I'd mention it as a possible workaround.
See also bug 215689 for setting / unsetting environment variables in the Launcher, which seems to be related. One extra feature I'd like to see with this is a fallback for cases where an environment variable is not set. For instance: -vm ${WIND_HOME:-../../..}/jre/bin/client/jvm.dll}
Not going to happen for 3.7.
Move all 3.8 bugs to Juno.
Hi all, Can I politely ask what is happening to this bug and the proposed patch? I feel the patch fulfils the requirement (to resolve environment variables in launcher ini file) Of course it could be better, as others suggested, but how about addressing improvements in an iterative fashion rather that waiting - possibly forever - on the perfect solution? Thanks, Romain
Not going to make Juno.
This bugs seems to have died even though there is a possible patch. I like the env option but I would also like a variable that points to where the eclipse executable resides, ie the ECLIPSE_HOME. This is important in order to pass java system properties to the jvm that point to locations relative to ECLIPSE_HOME. I tried doing this in the config.ini using the platform url form but these settings much we resolved before the JVM starts and passed in as VM args.
(In reply to Erik Englund from comment #21) > This bugs seems to have died even though there is a possible patch. I like > the env option but I would also like a variable that points to where the > eclipse executable resides, ie the ECLIPSE_HOME. This is important in > order to pass java system properties to the jvm that point to locations > relative to ECLIPSE_HOME. I tried doing this in the config.ini using the > platform url form but these settings much we resolved before the JVM starts > and passed in as VM args. Yes, this bug seems to have died. I will move it to Mars, but I think we likely need a new patch to be done against the latest code. There were also several open questions about the solution.
Bug 241192 added support for environment variables and Java properties in config.ini since 3.8/4.2. The decided upon syntax was $VARIABLE$, rather than ${VARIABLE} syntax. I recommend that any further work should be consistent with the already released implementation in config.ini.
(In reply to Steven Darnell from comment #23) > Bug 241192 added support for environment variables and Java properties in > config.ini since 3.8/4.2. The decided upon syntax was $VARIABLE$, rather > than ${VARIABLE} syntax. I recommend that any further work should be > consistent with the already released implementation in config.ini. Good point Steven. I agree we should be consistent here for the syntax.
Created attachment 245215 [details] Patch for Luna. Uses $VARIABLE$ syntax. To keep this going and, hopefully, see it one day resolved I'm attaching patch based off of Andrew Niefer's work that works with Luna (R4.4). It conforms with $VARIABLE$ syntax.
Two years later, still no support for this 11 years old request, althought multiple patches were offered m(
Why is this not considered for being merged? Is nobody maintaining the code to be able to merge this? On Windows Terminal Server environments it is needed to be able to resolve ENV Variables when launching the product to be able to have some directories in other folders than support by the @variable's.
(In reply to Rabea Gransberger from comment #27) > Why is this not considered for being merged? > Is nobody maintaining the code to be able to merge this? Sorry about that. I try to keep track of patches in gerrit but this one is not there. If someone puts it there we will try merging it for 4.11. > > On Windows Terminal Server environments it is needed to be able to resolve > ENV Variables when launching the product to be able to have some directories > in other folders than support by the @variable's.
@Predrag / @Andrew / @Romain: I know this is a lot of work to get into this again, but I and other would really appreciate if you'd take the time to get this into Gerrit :)
It has been 6 years since I made change to that code, and over 4 since the patch I posted. I cloned equinox repository today, installed Windows Server 2003 SP1 SDK and compiled and tested it again. I can make another git patch against current master, but I'm not committer and can't push it to Gerrit.
(In reply to Predrag Stanar from comment #30) > It has been 6 years since I made change to that code, and over 4 since the > patch I posted. I cloned equinox repository today, installed Windows Server > 2003 SP1 SDK and compiled and tested it again. > > I can make another git patch against current master, but I'm not committer > and can't push it to Gerrit. Everyone can push to Gerrit, but only committers can merge.
New Gerrit change created: https://git.eclipse.org/r/133322
(In reply to Alexander Kurtakov from comment #28) > (In reply to Rabea Gransberger from comment #27) > > Why is this not considered for being merged? > > Is nobody maintaining the code to be able to merge this? > > Sorry about that. I try to keep track of patches in gerrit but this one is > not there. If someone puts it there we will try merging it for 4.11. > > > > > On Windows Terminal Server environments it is needed to be able to resolve > > ENV Variables when launching the product to be able to have some directories > > in other folders than support by the @variable's. Patch seems to be in gerrit now. So, maybe this bug can soon be solved.
I want to specify where to write crash files. That would best be done with the VM arg -XX:ErrorFile, specifying an existing, writable directory that may differ by operating system and user. That in turn would best be done by using an environment variable in the <launcher>.ini file. Can this issue be addressed?
(In reply to Andrew Thomas from comment #34) > Can this issue be addressed? Sure. https://wiki.eclipse.org/Platform/How_to_Contribute
(In reply to Andrey Loskutov from comment #35) > (In reply to Andrew Thomas from comment #34) > > Can this issue be addressed? > > Sure. https://wiki.eclipse.org/Platform/How_to_Contribute (In reply to Eclipse Genie from comment #32) > New Gerrit change created: https://git.eclipse.org/r/133322 This patch needs a qualified reviewer.
(In reply to Andrey Loskutov from comment #36) > (In reply to Andrey Loskutov from comment #35) > > (In reply to Andrew Thomas from comment #34) > > > Can this issue be addressed? > > > > Sure. https://wiki.eclipse.org/Platform/How_to_Contribute > > (In reply to Eclipse Genie from comment #32) > > New Gerrit change created: https://git.eclipse.org/r/133322 > > This patch needs a qualified reviewer. I will review by this end of this week
Sravan, may I put this on your plan for 4.15?
(In reply to Andrey Loskutov from comment #38) > Sravan, may I put this on your plan for 4.15? Sure. I should be able to complete this by M1
(In reply to Sravan Kumar Lakkimsetti from comment #39) > (In reply to Andrey Loskutov from comment #38) > > Sravan, may I put this on your plan for 4.15? > > Sure. I should be able to complete this by M1 Sravan, may be something for M3?
Move to 4.16 M1
Where are we at for this one? Likely not to make M1?
Moving to M3. I could not find time to work on this due to JIPP migration work
Remove target milestone as it's clearly not a topic for 4.16.
Will this be part of 4.17?
(In reply to Udo Walker from comment #45) > Will this be part of 4.17? I will review this tomorrow. There some firefights going on today.
Gerrit change https://git.eclipse.org/r/133322 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=f49d80cfb5265ec98888ac9f48b219ac16863cc4
(In reply to Udo Walker from comment #45) > Will this be part of 4.17? Please test this in tomorrows I build I20200608-1800
Merged to master and rebuilt the launchers
New Gerrit change created: https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/174076
Reverting this fix as this caused regression bug 569885
Gerrit change https://git.eclipse.org/r/c/equinox/rt.equinox.framework/+/174076 was merged to [master]. Commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=3de698e0445d53ab78e17cc6f0a6413fa5f944e5
Is there any option to fix/adjust the patch? I think ${env_var:ENV} syntax would be much better as it will work inside eclipse also that way when used in a product config while the $ENV$ syntax will only work in exported product but not in the IDE, beside it might be easier/more reliable to find the bounds.
