Bug 118946 - [java launching] support variables (string substitution) in "default VM arguments"
Summary: [java launching] support variables (string substitution) in "default VM argum...
Status: REOPENED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.1.1   Edit
Hardware: All All
: P3 enhancement with 3 votes (vote)
Target Milestone: ---   Edit
Assignee: JDT-Debug-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 95555 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-12-01 18:24 EST by Tim Eck CLA
Modified: 2009-09-01 12:29 EDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Eck CLA 2005-12-01 18:24:49 EST
It would be incredibly helpful for our development is we could use string substitution in the "default vm arguments" settings attached to installed JRE profiles. 

For instance, to run any piece of code I work on, I need specify the full path to a jar in -Xbootclasspath. That path depends on the value of ${workspace_loc} however, thus the desire for string substiution.

Thanks for the consideration!
Comment 1 Tim Eck CLA 2005-12-01 18:35:38 EST
I don't think it makes much of a difference in the description of this RFE, but I meant to say I want to subst ${project_loc} in my default VM args (as opposed to ${workspace_loc})
Comment 2 Darin Wright CLA 2006-01-25 16:23:58 EST
Deferred. Unfortunately this would break the existing API contract of IVMInstall.getVMArguments():

"Returns VM arguments to be used with this vm install whenever this VM is launched as they should be passed to the command line, or <code>null</code> if none."

Existing clients that use the API would not be expecting variables, and would be broken when attempting to launch.

CC'ing Jim for comment/suggestions.
Comment 3 Darin Wright CLA 2006-05-15 16:02:20 EDT
*** Bug 95555 has been marked as a duplicate of this bug. ***
Comment 4 Denis Roy CLA 2009-08-30 02:17:00 EDT
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.
Comment 5 Robert Spremulli CLA 2009-09-01 10:42:04 EDT
This still makes sense as an enhancement for me.

Use Case: grabbing an Environment Variable to use as part of a path.  Each build I download is installed into a folder based on build number and date, which I then need to pass as a parameter.  While this does work by setting it on each individual launch config, there is a vast number that end up getting created; it makes more sense to define it in one location.
Comment 6 Darin Wright CLA 2009-09-01 10:54:42 EDT
I'll re-open it to keep the request alive. Currnetly, we don't have resources to work on this.
Comment 7 Robert Spremulli CLA 2009-09-01 11:41:07 EDT
Thanks, I haven't done much with the eclipse bugzilla so I wasn't sure if simply replying would reopen or if it was a permission only available to the originator.

Is the eclipse project still doing Bug Days?  The wiki hadn't been updated with a date in a while and I don't see a separate flag on the defect page, but I would be willing to work on this during a Bug Day if it's a candidate.
Comment 8 Curtis Windatt CLA 2009-09-01 12:29:06 EDT
(In reply to comment #7)
> Thanks, I haven't done much with the eclipse bugzilla so I wasn't sure if
> simply replying would reopen or if it was a permission only available to the
> originator.
> 
> Is the eclipse project still doing Bug Days?  The wiki hadn't been updated with
> a date in a while and I don't see a separate flag on the defect page, but I
> would be willing to work on this during a Bug Day if it's a candidate.

Yes Bug Day is still active.  We don't typically update the wiki, but we mark appropriate bugs with the 'bugday' key word.  Before you look into fixing this, consider comment 2.