Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » Compiling(Compiling)
Compiling [message #519976] Wed, 10 March 2010 16:53 Go to next message
Brian Vosburgh is currently offline Brian VosburghFriend
Messages: 137
Registered: July 2009
Senior Member
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 09:08 Go to previous messageGo to next message
Ankur Sharma is currently offline Ankur SharmaFriend
Messages: 68
Registered: July 2009
Member
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 10:11 Go to previous messageGo to next message
Steffen Zschaler is currently offline Steffen ZschalerFriend
Messages: 266
Registered: July 2009
Senior Member
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 #520884 is a reply to message #520776] Mon, 15 March 2010 16:24 Go to previous messageGo to next message
Brian Vosburgh is currently offline Brian VosburghFriend
Messages: 137
Registered: July 2009
Senior Member
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 #522693 is a reply to message #520884] Tue, 23 March 2010 15:55 Go to previous messageGo to next message
Brian Vosburgh is currently offline Brian VosburghFriend
Messages: 137
Registered: July 2009
Senior Member
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? :-)
Re: Compiling [message #522994 is a reply to message #522693] Wed, 24 March 2010 17:09 Go to previous message
Brian Vosburgh is currently offline Brian VosburghFriend
Messages: 137
Registered: July 2009
Senior Member
I opened a bug to track this issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=306892

Thanks.
Brian
Re: Compiling [message #605041 is a reply to message #520682] Mon, 15 March 2010 10:11 Go to previous message
Steffen Zschaler is currently offline Steffen ZschalerFriend
Messages: 266
Registered: July 2009
Senior Member
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 16:24 Go to previous message
Brian Vosburgh is currently offline Brian VosburghFriend
Messages: 137
Registered: July 2009
Senior Member
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 15:55 Go to previous message
Brian Vosburgh is currently offline Brian VosburghFriend
Messages: 137
Registered: July 2009
Senior Member
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? :-)
Re: Compiling [message #605236 is a reply to message #605212] Wed, 24 March 2010 17:09 Go to previous message
Brian Vosburgh is currently offline Brian VosburghFriend
Messages: 137
Registered: July 2009
Senior Member
I opened a bug to track this issue:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=306892

Thanks.
Brian
Previous Topic:Unsatisfied version constraint
Next Topic:can't find packages after upgrading to 3.4.1
Goto Forum:
  


Current Time: Fri Mar 29 12:05:40 GMT 2024

Powered by FUDForum. Page generated in 0.05818 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top