|
| Re: ECLIPSE_HOME should point to target platform [message #1727270 is a reply to message #1727233] |
Mon, 21 March 2016 16:10   |
|
Am 21.03.2016 um 14:48 schrieb Tobias Pongs:
> The java classpath variable ECLIPSE_HOME is defined to point to the target platform.
I always thought it always points to the host IDE's install location, but now I've checked the defining code in
org.eclipse.pde.internal.core.EclipseHomeInitializer and org.eclipse.pde.core.plugin.TargetPlatform.getLocation(). I
must say that I find the name "ECLIPSE_HOME" highly misleading. Maybe it's relict from pre-OSGi times.
But worse than the name is the implementation: If the first ITargetLocation has a non-null location, that location is
used for ECLIPSE_HOME. If there are no ITargetLocations or the first one has a null location, the host IDE's install
location is used. More than the first ITargetLocation is never checked for non-null locations.
With this complex definition the ECLIPSE_HOME variable does not seem very useful to me. How are you using it?
>
> Due to bug 482197 the TargletContainer was changed to return the install location instead of the pool location.
>
> Was it intended, that this change have that effect?
I guess so. Do you think that is a problem?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: ECLIPSE_HOME should point to target platform [message #1727309 is a reply to message #1727270] |
Tue, 22 March 2016 05:41 |
 Tobias Pongs
Messages: 9
Registered: July 2015 |
Junior Member |
|
|
Eike Stepper wrote on Mon, 21 March 2016 16:10
> The java classpath variable ECLIPSE_HOME is defined to point to the target platform.
I always thought it always points to the host IDE's install location, but now I've checked the defining code in
org.eclipse.pde.internal.core.EclipseHomeInitializer and org.eclipse.pde.core.plugin.TargetPlatform.getLocation(). I
must say that I find the name "ECLIPSE_HOME" highly misleading. Maybe it's relict from pre-OSGi times.
When I first used that variable, I was surprised, too.
Eike Stepper wrote on Mon, 21 March 2016 16:10
But worse than the name is the implementation: If the first ITargetLocation has a non-null location, that location is
used for ECLIPSE_HOME. If there are no ITargetLocations or the first one has a null location, the host IDE's install
location is used. More than the first ITargetLocation is never checked for non-null locations.
With this complex definition the ECLIPSE_HOME variable does not seem very useful to me. How are you using it?
I need a special annotation processor from the target platform. So I used this variable in the annotation processing factory path to point to the plugin in the target platform.
Eike Stepper wrote on Mon, 21 March 2016 16:10
>
> Due to bug 482197 the TargletContainer was changed to return the install location instead of the pool location.
>
> Was it intended, that this change have that effect?
I guess so. Do you think that is a problem?
Is there another way to get the path of a plugin out of the target platform?
Best regards
Tobias
|
|
|
| Re: ECLIPSE_HOME should point to target platform [message #1727334 is a reply to message #1727309] |
Tue, 22 March 2016 08:44 |
|
Hi Tobias,
You could try to use one of the variables defined by the org.eclipse.oomph.targlets.core plugin:
<extension
point="org.eclipse.core.variables.dynamicVariables">
<variable
description="Targlet Container Profile ID"
name="targlet_container_profile_id"
resolver="org.eclipse.oomph.targlets.internal.core.variables.TargletContainerProfileID"
supportsArgument="true"/>
<variable
description="Targlet Container Profile File"
name="targlet_container_profile_file"
resolver="org.eclipse.oomph.targlets.internal.core.variables.TargletContainerProfileFile"
supportsArgument="true"/>
<variable
description="Targlet Container Profile Directory"
name="targlet_container_profile_directory"
resolver="org.eclipse.oomph.targlets.internal.core.variables.TargletContainerProfileDirectory"
supportsArgument="true"/>
<variable
description="Targlet Container Bundle Pool"
name="targlet_container_bundle_pool"
resolver="org.eclipse.oomph.targlets.internal.core.variables.TargletContainerBundlePool"
supportsArgument="true"/>
<variable
description="Targlet Container Classpath"
name="targlet_container_classpath"
resolver="org.eclipse.oomph.targlets.internal.core.variables.TargletContainerClasspath"
supportsArgument="true"/>
<variable
description="Targlet Container Classpath File"
name="targlet_container_classpath_file"
resolver="org.eclipse.oomph.targlets.internal.core.variables.TargletContainerClasspathFile"
supportsArgument="true"/>
</extension>
They all take the TargletContainerID as an argument.
And we provide the argument-free "target_platform_classpath_file" variable from the org.eclipse.oomph.util.pde plugin:
<extension
point="org.eclipse.core.variables.dynamicVariables">
<variable
description="Target Platform Classpath File"
name="target_platform_classpath_file"
resolver="org.eclipse.oomph.util.internal.pde.TargetPlatformClasspathFile"
supportsArgument="false"/>
</extension>
It produces a temp file with a classpath that represents the active target's contents.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04369 seconds
] 
Search
Help
Register
Login
Home
