Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Different Versions same Plug-In
Different Versions same Plug-In [message #500712] Fri, 27 November 2009 16:00 Go to next message
Dirk Hoffmann is currently offline Dirk HoffmannFriend
Messages: 163
Registered: July 2009
Senior Member
Hi,

asked this on the eclipse.platform.rcp platform and thought someone else
reading the eclipse.tools.emf newsgroup may have faced the same problem:

we're developing a feature with lots of plug-ins some of which depend on
a set of third party plug-ins, namely EMF plug-ins.

We have to integrate with an RCP-based product which also uses EMF, lets
call it XIDE. Mixing our EMF plug-ins with theirs causes our feature or
their XIDE product to fail. Of course the plug-in loader is not able to
decide which version of the EMF plug-ins to load.

So then we specified the EMF-versions that we need in the MANIFEST.MF
files of our plug-ins with bundle-version=[...) clauses, but that's only
half of the solution. Actually the makers of the XIDE product should do
the same, so their XIDE's plug-in loader doesn't get confused by our EMF
plug-ins.

Unfortunately we cannot get them to add the bundle-version constraints
to their MANIFEST.MF files.

Does anybody have an idea how we can isolate the EMF plug-ins we need
from the rest of the plug-ins?

At the moment we think about renaming the EMF plug-ins required by our
feature (Meanwhile we found that a bad idea because there is probably
some code inside the bundles refering to the plug-in id). But maybe
there is a better and cleaner way.

Thanks and Regards,
Dirk
Re: Different Versions same Plug-In [message #500713 is a reply to message #500712] Fri, 27 November 2009 16:12 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30620
Registered: July 2009
Senior Member
Dirk,

Comments below.


Dirk Hoffmann wrote:
> Hi,
>
> asked this on the eclipse.platform.rcp platform and thought someone
> else reading the eclipse.tools.emf newsgroup may have faced the same
> problem:
>
> we're developing a feature with lots of plug-ins some of which depend on
> a set of third party plug-ins, namely EMF plug-ins.
>
> We have to integrate with an RCP-based product which also uses EMF, lets
> call it XIDE. Mixing our EMF plug-ins with theirs causes our feature or
> their XIDE product to fail. Of course the plug-in loader is not able to
> decide which version of the EMF plug-ins to load.
That will depend a lot on range restrictions...
>
> So then we specified the EMF-versions that we need in the MANIFEST.MF
> files of our plug-ins with bundle-version=[...) clauses, but that's only
> half of the solution. Actually the makers of the XIDE product should do
> the same, so their XIDE's plug-in loader doesn't get confused by our EMF
> plug-ins.
Do they have no range restrictions? Anything should work in that case
and the most recent version should be chosen...
>
> Unfortunately we cannot get them to add the bundle-version constraints
> to their MANIFEST.MF files.
>
> Does anybody have an idea how we can isolate the EMF plug-ins we need
> from the rest of the plug-ins?
I have a hard time imagining how lack of range constraints causes a
problem...
>
> At the moment we think about renaming the EMF plug-ins required by our
> feature (Meanwhile we found that a bad idea because there is probably
> some code inside the bundles refering to the plug-in id). But maybe
> there is a better and cleaner way.
Yes, that's not likely to work. It sounds to me like the problem must
be one of the ranges being over constrained so that no solution is
possible, but you make it sound like it's under constrained and I don't
see how that would cause a problem...
>
> Thanks and Regards,
> Dirk
Re: Different Versions same Plug-In [message #501194 is a reply to message #500713] Tue, 01 December 2009 13:41 Go to previous messageGo to next message
Dirk Hoffmann is currently offline Dirk HoffmannFriend
Messages: 163
Registered: July 2009
Senior Member
Ed,

thanks for the prompt reply.

It turned out that apparently no two different versions of the EMF
features can be installed into one Eclipse installation at once. I tried
that out with Galileo and the EMF Core Runtime with versions 2.2.5 and
2.5.0.

The log says:

!ENTRY org.eclipse.equinox.p2.ui 4 0 2009-12-01 14:34:41.499
!MESSAGE Operation details
!SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
!MESSAGE Cannot complete the install because of a conflicting dependency.
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
!MESSAGE Software being installed: EMF - Eclipse Modeling Framework Core
Runtime 2.5.0.v200906151043 (org.eclipse.emf.ecore.feature.group
2.5.0.v200906151043)
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
!MESSAGE Software currently installed: Eclipse Modeling Framework (EMF)
Runtime + End-User Tools 2.2.5.v200808252119
(org.eclipse.emf.feature.group 2.2.5.v200808252119)
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
!MESSAGE Only one of the following can be installed at once:
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
!MESSAGE EMF Change Model 2.5.0.v200906151043
(org.eclipse.emf.ecore.change 2.5.0.v200906151043)
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
!MESSAGE EMF Ecore Change Model 2.2.1.v200808252119
(org.eclipse.emf.ecore.change 2.2.1.v200808252119)
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
!MESSAGE Cannot satisfy dependency:
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
!MESSAGE From: EMF - Eclipse Modeling Framework Core Runtime
2.5.0.v200906151043 (org.eclipse.emf.ecore.feature.group
2.5.0.v200906151043)
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
!MESSAGE To: org.eclipse.emf.ecore.change
!SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
!MESSAGE Cannot satisfy dependency:
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
!MESSAGE From: Eclipse Modeling Framework (EMF) Runtime + End-User Tools
2.2.5.v200808252119 (org.eclipse.emf.feature.group 2.2.5.v200808252119)
!SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
!MESSAGE To: org.eclipse.emf.ecore.change [2.2.1.v200808252119]

Is there any special reason why that isn't possible or is there any work
around to make two EMF versions co-exist. I believe Eclipse bundles are
actually designed to be able to do so.

Best Regards,
Dirk


Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
>
> Dirk Hoffmann wrote:
>> Hi,
>>
>> asked this on the eclipse.platform.rcp platform and thought someone
>> else reading the eclipse.tools.emf newsgroup may have faced the same
>> problem:
>>
>> we're developing a feature with lots of plug-ins some of which depend on
>> a set of third party plug-ins, namely EMF plug-ins.
>>
>> We have to integrate with an RCP-based product which also uses EMF, lets
>> call it XIDE. Mixing our EMF plug-ins with theirs causes our feature or
>> their XIDE product to fail. Of course the plug-in loader is not able to
>> decide which version of the EMF plug-ins to load.
> That will depend a lot on range restrictions...
>>
>> So then we specified the EMF-versions that we need in the MANIFEST.MF
>> files of our plug-ins with bundle-version=[...) clauses, but that's only
>> half of the solution. Actually the makers of the XIDE product should do
>> the same, so their XIDE's plug-in loader doesn't get confused by our EMF
>> plug-ins.
> Do they have no range restrictions? Anything should work in that case
> and the most recent version should be chosen...
>>
>> Unfortunately we cannot get them to add the bundle-version constraints
>> to their MANIFEST.MF files.
>>
>> Does anybody have an idea how we can isolate the EMF plug-ins we need
>> from the rest of the plug-ins?
> I have a hard time imagining how lack of range constraints causes a
> problem...
>>
>> At the moment we think about renaming the EMF plug-ins required by our
>> feature (Meanwhile we found that a bad idea because there is probably
>> some code inside the bundles refering to the plug-in id). But maybe
>> there is a better and cleaner way.
> Yes, that's not likely to work. It sounds to me like the problem must
> be one of the ranges being over constrained so that no solution is
> possible, but you make it sound like it's under constrained and I don't
> see how that would cause a problem...
>>
>> Thanks and Regards,
>> Dirk
Re: Different Versions same Plug-In [message #501226 is a reply to message #501194] Tue, 01 December 2009 15:18 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30620
Registered: July 2009
Senior Member
Dirk,

Comments below.

Dirk Hoffmann wrote:
> Ed,
>
> thanks for the prompt reply.
>
> It turned out that apparently no two different versions of the EMF
> features can be installed into one Eclipse installation at once. I
> tried that out with Galileo and the EMF Core Runtime with versions
> 2.2.5 and 2.5.0.
>
> The log says:
>
> !ENTRY org.eclipse.equinox.p2.ui 4 0 2009-12-01 14:34:41.499
> !MESSAGE Operation details
> !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
> !MESSAGE Cannot complete the install because of a conflicting dependency.
> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
> !MESSAGE Software being installed: EMF - Eclipse Modeling Framework
> Core Runtime 2.5.0.v200906151043 (org.eclipse.emf.ecore.feature.group
> 2.5.0.v200906151043)
> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
> !MESSAGE Software currently installed: Eclipse Modeling Framework
> (EMF) Runtime + End-User Tools 2.2.5.v200808252119
> (org.eclipse.emf.feature.group 2.2.5.v200808252119)
> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
> !MESSAGE Only one of the following can be installed at once:
> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
> !MESSAGE EMF Change Model 2.5.0.v200906151043
> (org.eclipse.emf.ecore.change 2.5.0.v200906151043)
> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
> !MESSAGE EMF Ecore Change Model 2.2.1.v200808252119
> (org.eclipse.emf.ecore.change 2.2.1.v200808252119)
> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
> !MESSAGE Cannot satisfy dependency:
> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
> !MESSAGE From: EMF - Eclipse Modeling Framework Core Runtime
> 2.5.0.v200906151043 (org.eclipse.emf.ecore.feature.group
> 2.5.0.v200906151043)
> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
> !MESSAGE To: org.eclipse.emf.ecore.change
> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
> !MESSAGE Cannot satisfy dependency:
> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
> !MESSAGE From: Eclipse Modeling Framework (EMF) Runtime + End-User
> Tools 2.2.5.v200808252119 (org.eclipse.emf.feature.group
> 2.2.5.v200808252119)
> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
> !MESSAGE To: org.eclipse.emf.ecore.change [2.2.1.v200808252119]
>
> Is there any special reason why that isn't possible or is there any
> work around to make two EMF versions co-exist. I believe Eclipse
> bundles are actually designed to be able to do so.
Bundles that define extension points or provide extensions must be
singletons and hence only one version can be active. EMF definitely
defines and uses extension points as do all the generated plugins.
>
> Best Regards,
> Dirk
>
>
> Ed Merks schrieb:
>> Dirk,
>>
>> Comments below.
>>
>>
>> Dirk Hoffmann wrote:
>>> Hi,
>>>
>>> asked this on the eclipse.platform.rcp platform and thought someone
>>> else reading the eclipse.tools.emf newsgroup may have faced the same
>>> problem:
>>>
>>> we're developing a feature with lots of plug-ins some of which
>>> depend on
>>> a set of third party plug-ins, namely EMF plug-ins.
>>>
>>> We have to integrate with an RCP-based product which also uses EMF,
>>> lets
>>> call it XIDE. Mixing our EMF plug-ins with theirs causes our feature or
>>> their XIDE product to fail. Of course the plug-in loader is not able to
>>> decide which version of the EMF plug-ins to load.
>> That will depend a lot on range restrictions...
>>>
>>> So then we specified the EMF-versions that we need in the MANIFEST.MF
>>> files of our plug-ins with bundle-version=[...) clauses, but that's
>>> only
>>> half of the solution. Actually the makers of the XIDE product should do
>>> the same, so their XIDE's plug-in loader doesn't get confused by our
>>> EMF
>>> plug-ins.
>> Do they have no range restrictions? Anything should work in that
>> case and the most recent version should be chosen...
>>>
>>> Unfortunately we cannot get them to add the bundle-version constraints
>>> to their MANIFEST.MF files.
>>>
>>> Does anybody have an idea how we can isolate the EMF plug-ins we need
>>> from the rest of the plug-ins?
>> I have a hard time imagining how lack of range constraints causes a
>> problem...
>>>
>>> At the moment we think about renaming the EMF plug-ins required by our
>>> feature (Meanwhile we found that a bad idea because there is
>>> probably some code inside the bundles refering to the plug-in id).
>>> But maybe there is a better and cleaner way.
>> Yes, that's not likely to work. It sounds to me like the problem
>> must be one of the ranges being over constrained so that no solution
>> is possible, but you make it sound like it's under constrained and I
>> don't see how that would cause a problem...
>>>
>>> Thanks and Regards,
>>> Dirk
Re: Different Versions same Plug-In [message #501396 is a reply to message #501226] Wed, 02 December 2009 07:43 Go to previous message
Dirk Hoffmann is currently offline Dirk HoffmannFriend
Messages: 163
Registered: July 2009
Senior Member
Ed Merks schrieb:
> Dirk,
>
> Comments below.
>
> Dirk Hoffmann wrote:
>> Ed,
>>
>> thanks for the prompt reply.
>>
>> It turned out that apparently no two different versions of the EMF
>> features can be installed into one Eclipse installation at once. I
>> tried that out with Galileo and the EMF Core Runtime with versions
>> 2.2.5 and 2.5.0.
>>
>> The log says:
>>
>> !ENTRY org.eclipse.equinox.p2.ui 4 0 2009-12-01 14:34:41.499
>> !MESSAGE Operation details
>> !SUBENTRY 1 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
>> !MESSAGE Cannot complete the install because of a conflicting dependency.
>> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
>> !MESSAGE Software being installed: EMF - Eclipse Modeling Framework
>> Core Runtime 2.5.0.v200906151043 (org.eclipse.emf.ecore.feature.group
>> 2.5.0.v200906151043)
>> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
>> !MESSAGE Software currently installed: Eclipse Modeling Framework
>> (EMF) Runtime + End-User Tools 2.2.5.v200808252119
>> (org.eclipse.emf.feature.group 2.2.5.v200808252119)
>> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
>> !MESSAGE Only one of the following can be installed at once:
>> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
>> !MESSAGE EMF Change Model 2.5.0.v200906151043
>> (org.eclipse.emf.ecore.change 2.5.0.v200906151043)
>> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
>> !MESSAGE EMF Ecore Change Model 2.2.1.v200808252119
>> (org.eclipse.emf.ecore.change 2.2.1.v200808252119)
>> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
>> !MESSAGE Cannot satisfy dependency:
>> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
>> !MESSAGE From: EMF - Eclipse Modeling Framework Core Runtime
>> 2.5.0.v200906151043 (org.eclipse.emf.ecore.feature.group
>> 2.5.0.v200906151043)
>> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
>> !MESSAGE To: org.eclipse.emf.ecore.change
>> !SUBENTRY 2 org.eclipse.equinox.p2.director 4 1 2009-12-01 14:34:41.499
>> !MESSAGE Cannot satisfy dependency:
>> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
>> !MESSAGE From: Eclipse Modeling Framework (EMF) Runtime + End-User
>> Tools 2.2.5.v200808252119 (org.eclipse.emf.feature.group
>> 2.2.5.v200808252119)
>> !SUBENTRY 3 org.eclipse.equinox.p2.director 4 0 2009-12-01 14:34:41.499
>> !MESSAGE To: org.eclipse.emf.ecore.change [2.2.1.v200808252119]
>>
>> Is there any special reason why that isn't possible or is there any
>> work around to make two EMF versions co-exist. I believe Eclipse
>> bundles are actually designed to be able to do so.
> Bundles that define extension points or provide extensions must be
> singletons and hence only one version can be active. EMF definitely
> defines and uses extension points as do all the generated plugins.
Thanks a lot! I didn't know this - but it sounds quite reasonable.
Otherwise the version would have to be specfied with the extension point
id.
>>
>> Best Regards,
>> Dirk
>>
>>
>> Ed Merks schrieb:
>>> Dirk,
>>>
>>> Comments below.
>>>
>>>
>>> Dirk Hoffmann wrote:
>>>> Hi,
>>>>
>>>> asked this on the eclipse.platform.rcp platform and thought someone
>>>> else reading the eclipse.tools.emf newsgroup may have faced the same
>>>> problem:
>>>>
>>>> we're developing a feature with lots of plug-ins some of which
>>>> depend on
>>>> a set of third party plug-ins, namely EMF plug-ins.
>>>>
>>>> We have to integrate with an RCP-based product which also uses EMF,
>>>> lets
>>>> call it XIDE. Mixing our EMF plug-ins with theirs causes our feature or
>>>> their XIDE product to fail. Of course the plug-in loader is not able to
>>>> decide which version of the EMF plug-ins to load.
>>> That will depend a lot on range restrictions...
>>>>
>>>> So then we specified the EMF-versions that we need in the MANIFEST.MF
>>>> files of our plug-ins with bundle-version=[...) clauses, but that's
>>>> only
>>>> half of the solution. Actually the makers of the XIDE product should do
>>>> the same, so their XIDE's plug-in loader doesn't get confused by our
>>>> EMF
>>>> plug-ins.
>>> Do they have no range restrictions? Anything should work in that
>>> case and the most recent version should be chosen...
>>>>
>>>> Unfortunately we cannot get them to add the bundle-version constraints
>>>> to their MANIFEST.MF files.
>>>>
>>>> Does anybody have an idea how we can isolate the EMF plug-ins we need
>>>> from the rest of the plug-ins?
>>> I have a hard time imagining how lack of range constraints causes a
>>> problem...
>>>>
>>>> At the moment we think about renaming the EMF plug-ins required by our
>>>> feature (Meanwhile we found that a bad idea because there is
>>>> probably some code inside the bundles refering to the plug-in id).
>>>> But maybe there is a better and cleaner way.
>>> Yes, that's not likely to work. It sounds to me like the problem
>>> must be one of the ranges being over constrained so that no solution
>>> is possible, but you make it sound like it's under constrained and I
>>> don't see how that would cause a problem...
>>>>
>>>> Thanks and Regards,
>>>> Dirk
Previous Topic:[CDO] problems with cdo server of N200911221008
Next Topic:One genmodel vs. multiple genmodels
Goto Forum:
  


Current Time: Tue Nov 12 15:50:23 GMT 2019

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

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

Back to the top