Bugzilla – Full Text Bug Listing
| Summary: | Set eclipse.home for separate VM builds | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jim Brady <james-vincent.brady> |
| Component: | Ant | Assignee: | Platform-Ant-Inbox <platform-ant-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | Darin_Swanson, diam, loskutov, Michael_Rennie, tim.roberts |
| Version: | 3.0.1 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows NT | ||
| Whiteboard: | |||
|
Description
Jim Brady
eclipse.running is not valid when you are in a separate VM...Eclipse is not
running (no workspace context) :-)
We have not had a request for eclipse.home in a separate VM.
This would be possible but I believe it would be a rare use case. Currently
the user can add the property themselves if required:
On the properties tab for you Ant build (or you could do it globally at the
Ant preference level), enter a variable called eclipse.home that resolves to
the "system" variable with the argument ECLIPSE_HOME:
${system:ECLIPSE_HOME}
This variable will overwrite the Eclipse provided variable that is only set
for same JRE execution and will be available in both same and separate JRE
builds.
If the properties are not going to be supplied to a seperate JRE then they should be removed from the properties display, as happens with the additional classpath entries (e.g. jdtCompilerAdapter.jar) when you switch away from the workspace JRE. It's certainly misleading as it is. I also think that it's confusing (or inconsistent) that these "workspace JRE only" Task and Property settings appear in the global Ant Runtime settings but are then removed depending upon the JRE selection at the individual Run Configuration level. This seems inconsistent with the "workspace JRE only" classpath settings which don't appear in the global Ant Runtime settings, but do appear in the individual run configuration settings if the workspace JRE is selected. This latter approach seems much more intuitive to me. *** Bug 79494 has been marked as a duplicate of this bug. *** You are correct Tim that this is confusing and inconsistent. I have reopened bug 56072 for that particular issue to work towards better presentation. Thanks for taking the time to present your problems with the current implementation. eclipse.target (added via bug 78752) should be considered as well. Deferred to post 3.1 consideration *** Bug 93227 has been marked as a duplicate of this bug. *** Any chance to get it into the 3.5? If using a different JRE as the Eclipse itself (project uses 1.5, Eclipse is running on 1.6), it's not possible to use eclipse ant tasks at all. Such simple things like workspace refresh are not working, this is frustrating... Btw, what about to remove "LATER" and re-open this bug, because it is NOT resolved. Bug 202578 is a dup of this. The Eclipse platform Ant support is essentially in maintenance mode. Patches would be reviewed and considered (including tests) but this is not a high priority. I think there is enough distinction between bug 202578 and this one to not mark as duplicate until the full scope of the enhancement for either was proposed and provided. There are no plans to implement this. If a community contribution is provided we can reopen. marking wontfix |