Home » Eclipse Projects » Plugin Development Environment (PDE) » Compiling(Compiling)
| Compiling [message #519976] |
Wed, 10 March 2010 11:53  |
Eclipse User |
|
|
|
I have a question about how PDE determines which version of a plug-in our code (Dali) compiles against.
Our target workspace has 2 versions of the org.junit plug-in: 3.8.2 and 4.8.1 (both supplied by the Eclipse JDK download). Since we are a part of WTP, we are currently required to run against junit 3.8.2. As a result, we set our Required Plug-ins list to include
org.junit (3.8.0)
meaning we can run against junit 3.8.0 or anything higher. The problem comes that, when we compile, the build path uses junit 4.8.1. This doesn't seem right. Sure, we can *run* against 4.8.1; but that does not mean we want to *compile* against 4.8.1. In fact, that can cause us to have code that compiles cleanly but cannot run against 3.8.2. Does that make sense? It seems that the compile-time path should *require* a plug-in with a version that matches the low end of your own plug-ins required version. Otherwise, you have the potential for run-time errors.
I would appreciate any insights.
|
|
|
| Re: Compiling [message #520682 is a reply to message #519976] |
Sun, 14 March 2010 05:08  |
| Eclipse User |
|
|
|
On 3/10/2010 10:23 PM, Brian Vosburgh wrote:
> I have a question about how PDE determines which version of a plug-in
> our code (Dali) compiles against.
>
> Our target workspace has 2 versions of the org.junit plug-in: 3.8.2 and
> 4.8.1 (both supplied by the Eclipse JDK download). Since we are a part
> of WTP, we are currently required to run against junit 3.8.2. As a
> result, we set our Required Plug-ins list to include
>
> org.junit (3.8.0)
>
> meaning we can run against junit 3.8.0 or anything higher. The problem
> comes that, when we compile, the build path uses junit 4.8.1. This
> doesn't seem right. Sure, we can *run* against 4.8.1; but that does not
> mean we want to *compile* against 4.8.1. In fact, that can cause us to
> have code that compiles cleanly but cannot run against 3.8.2. Does that
> make sense? It seems that the compile-time path should *require* a
> plug-in with a version that matches the low end of your own plug-ins
> required version. Otherwise, you have the potential for run-time errors.
>
> I would appreciate any insights.
>
If you open your the MANIFEST.MF file, you will see the required-bundle entry for junit plug-in like
this
org.junit;bundle-version="3.8.2"
this means PDE shall resolve it to the plug-in with the highest version in target greater than
3.8.2. For this reason junit 4.8.1 is getting picked.
There are two ways to ensure only 3.8.2 version gets picked.
1. Modify the target and remove 4.8.1 from it. But this is not what I would recommend.
2. Modify the manifest file and change the entry to
org.junit;bundle-version="[3.8.2,4.0.0)"
This means the plugin will now be resolved to a version 3.8.2 or higher (3.8.2 inclusive - implied
by "[" ) but lesser than 4.0.0 (exclusive - implied by ")" )
The easier way to configure this is on Dependency tab using the properties button.
After saving you can ensure which plugin it is getting resolved to using Plugin Dependencies view.
To use it right click on the plugin and choose PDE tools -> Open dependencies. Find org.junit plugin
in the list and note the version your plugin will be compiled against. (you may press the third
toolbar button in view - Set hierarchical layout to easily find the plugin)
hth
--
Ankur..
Eclipse PDE UI Committer | IBM India Software Lab, Bangalore
+91-99456-94011 | @ankur_sharma | http://blog.ankursharma.org
|
|
|
| Re: Compiling [message #520776 is a reply to message #520682] |
Mon, 15 March 2010 06:11 |
| Eclipse User |
|
|
|
I don't think this actually answers the OP's question: You well explain
the deployment semantics of version constraints, but I believe he was
making the point that this semantics was broken by the compile-time
semantics: In particular, to allow any plugin version greater or equal
than 3.8.2 to be chosen at deployment time, a plugin should be compiled
against 3.8.2 assuming backward-compatible development of plugins.
I'm not sure there is an easy answer here: The relation between
deployment-time semantics and compile-time semantics heavily depends on
how each of the plugins is evolved and what changes can happen between
releases. I know there are some rules for this in the Eclipse space, but
even so it's probably not possible to come up with a set of constraints
that would guarantee correct deployment if a plugin compiles correctly.
Cheers,
Steffen
On 14/03/2010 09:08, Ankur Sharma wrote:
> On 3/10/2010 10:23 PM, Brian Vosburgh wrote:
>> I have a question about how PDE determines which version of a plug-in
>> our code (Dali) compiles against.
>>
>> Our target workspace has 2 versions of the org.junit plug-in: 3.8.2 and
>> 4.8.1 (both supplied by the Eclipse JDK download). Since we are a part
>> of WTP, we are currently required to run against junit 3.8.2. As a
>> result, we set our Required Plug-ins list to include
>>
>> org.junit (3.8.0)
>>
>> meaning we can run against junit 3.8.0 or anything higher. The problem
>> comes that, when we compile, the build path uses junit 4.8.1. This
>> doesn't seem right. Sure, we can *run* against 4.8.1; but that does not
>> mean we want to *compile* against 4.8.1. In fact, that can cause us to
>> have code that compiles cleanly but cannot run against 3.8.2. Does that
>> make sense? It seems that the compile-time path should *require* a
>> plug-in with a version that matches the low end of your own plug-ins
>> required version. Otherwise, you have the potential for run-time errors.
>>
>> I would appreciate any insights.
>>
>
> If you open your the MANIFEST.MF file, you will see the
> required-bundle entry for junit plug-in like this
>
> org.junit;bundle-version="3.8.2"
>
> this means PDE shall resolve it to the plug-in with the highest
> version in target greater than 3.8.2. For this reason junit 4.8.1 is
> getting picked.
>
> There are two ways to ensure only 3.8.2 version gets picked.
>
> 1. Modify the target and remove 4.8.1 from it. But this is not what I
> would recommend.
>
> 2. Modify the manifest file and change the entry to
>
> org.junit;bundle-version="[3.8.2,4.0.0)"
>
> This means the plugin will now be resolved to a version 3.8.2 or
> higher (3.8.2 inclusive - implied by "[" ) but lesser than 4.0.0
> (exclusive - implied by ")" )
>
> The easier way to configure this is on Dependency tab using the
> properties button.
>
>
> After saving you can ensure which plugin it is getting resolved to
> using Plugin Dependencies view. To use it right click on the plugin
> and choose PDE tools -> Open dependencies. Find org.junit plugin in
> the list and note the version your plugin will be compiled against.
> (you may press the third toolbar button in view - Set hierarchical
> layout to easily find the plugin)
>
>
> hth
|
|
| | | |
| Re: Compiling [message #605041 is a reply to message #520682] |
Mon, 15 March 2010 06:11 |
| Eclipse User |
|
|
|
I don't think this actually answers the OP's question: You well explain
the deployment semantics of version constraints, but I believe he was
making the point that this semantics was broken by the compile-time
semantics: In particular, to allow any plugin version greater or equal
than 3.8.2 to be chosen at deployment time, a plugin should be compiled
against 3.8.2 assuming backward-compatible development of plugins.
I'm not sure there is an easy answer here: The relation between
deployment-time semantics and compile-time semantics heavily depends on
how each of the plugins is evolved and what changes can happen between
releases. I know there are some rules for this in the Eclipse space, but
even so it's probably not possible to come up with a set of constraints
that would guarantee correct deployment if a plugin compiles correctly.
Cheers,
Steffen
On 14/03/2010 09:08, Ankur Sharma wrote:
> On 3/10/2010 10:23 PM, Brian Vosburgh wrote:
>> I have a question about how PDE determines which version of a plug-in
>> our code (Dali) compiles against.
>>
>> Our target workspace has 2 versions of the org.junit plug-in: 3.8.2 and
>> 4.8.1 (both supplied by the Eclipse JDK download). Since we are a part
>> of WTP, we are currently required to run against junit 3.8.2. As a
>> result, we set our Required Plug-ins list to include
>>
>> org.junit (3.8.0)
>>
>> meaning we can run against junit 3.8.0 or anything higher. The problem
>> comes that, when we compile, the build path uses junit 4.8.1. This
>> doesn't seem right. Sure, we can *run* against 4.8.1; but that does not
>> mean we want to *compile* against 4.8.1. In fact, that can cause us to
>> have code that compiles cleanly but cannot run against 3.8.2. Does that
>> make sense? It seems that the compile-time path should *require* a
>> plug-in with a version that matches the low end of your own plug-ins
>> required version. Otherwise, you have the potential for run-time errors.
>>
>> I would appreciate any insights.
>>
>
> If you open your the MANIFEST.MF file, you will see the
> required-bundle entry for junit plug-in like this
>
> org.junit;bundle-version="3.8.2"
>
> this means PDE shall resolve it to the plug-in with the highest
> version in target greater than 3.8.2. For this reason junit 4.8.1 is
> getting picked.
>
> There are two ways to ensure only 3.8.2 version gets picked.
>
> 1. Modify the target and remove 4.8.1 from it. But this is not what I
> would recommend.
>
> 2. Modify the manifest file and change the entry to
>
> org.junit;bundle-version="[3.8.2,4.0.0)"
>
> This means the plugin will now be resolved to a version 3.8.2 or
> higher (3.8.2 inclusive - implied by "[" ) but lesser than 4.0.0
> (exclusive - implied by ")" )
>
> The easier way to configure this is on Dependency tab using the
> properties button.
>
>
> After saving you can ensure which plugin it is getting resolved to
> using Plugin Dependencies view. To use it right click on the plugin
> and choose PDE tools -> Open dependencies. Find org.junit plugin in
> the list and note the version your plugin will be compiled against.
> (you may press the third toolbar button in view - Set hierarchical
> layout to easily find the plugin)
>
>
> hth
|
|
|
| Re: Compiling [message #605047 is a reply to message #520776] |
Mon, 15 March 2010 12:24 |
| Eclipse User |
|
|
|
Quote:
> I don't think this actually answers the OP's question: You well explain
> the deployment semantics of version constraints, but I believe he was
> making the point that this semantics was broken by the compile-time
> semantics: In particular, to allow any plugin version greater or equal
> than 3.8.2 to be chosen at deployment time, a plugin should be compiled
> against 3.8.2 assuming backward-compatible development of plugins.
Exactly! As I said in my original post, I think it should actually be a compile time error if a version matching the low end of your plug-in's acceptable version range is not available to compile against; *and* that is the version your plug-in should be compiled against, not the highest compatible version. At runtime, your plug-in should be able to run with any compatible version of the required plug-in PDE wants to use (highest available or otherwise).
Does this make sense?
|
|
|
| Re: Compiling [message #605212 is a reply to message #520884] |
Tue, 23 March 2010 11:55 |
| Eclipse User |
|
|
|
Brian Vosburgh wrote on Mon, 15 March 2010 12:24
> Quote:
> > I don't think this actually answers the OP's question: You well explain
> > the deployment semantics of version constraints, but I believe he was
> > making the point that this semantics was broken by the compile-time
> > semantics: In particular, to allow any plugin version greater or equal
> > than 3.8.2 to be chosen at deployment time, a plugin should be compiled
> > against 3.8.2 assuming backward-compatible development of plugins.
>
> Exactly! As I said in my original post, I think it should actually be a compile time error if a version matching the low end of your plug-in's acceptable version range is not available to compile against; *and* that is the version your plug-in should be compiled against, not the highest compatible version. At runtime, your plug-in should be able to run with any compatible version of the required plug-in PDE wants to use (highest available or otherwise).
>
> Does this make sense?
Ankur, you still there? :-)
|
|
| |
Goto Forum:
Current Time: Sat Jul 05 02:47:53 EDT 2025
Powered by FUDForum. Page generated in 0.09447 seconds |
Home