|
| Re: Different Versions same Plug-In [message #500713 is a reply to message #500712] |
Fri, 27 November 2009 16:12   |
 Ed Merks
Messages: 33133
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Different Versions same Plug-In [message #501194 is a reply to message #500713] |
Tue, 01 December 2009 13:41 |
Dirk Hoffmann
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 |
Ed Merks
Messages: 33133
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
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Different Versions same Plug-In [message #501396 is a reply to message #501226] |
Wed, 02 December 2009 07:43 |
Dirk Hoffmann
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
|
|
|
Powered by
FUDForum. Page generated in 0.05471 seconds
] 
Search
Help
Register
Login
Home
