Eclipse Community Forums: Compare » org.eclipse.emf.compare singleton bundle?

Home » Modeling » Compare » org.eclipse.emf.compare singleton bundle?(why is it org.eclipse.emf.compare singleton?)

org.eclipse.emf.compare singleton bundle? [message #1053063]

Thu, 02 May 2013 05:57

Eclipse User

Hi EMF Compare team and Eclipse community,

during our integration of the new EMF Compare 2.0, I realized the bundle org.eclipse.emf.compare is singleton in both 1.X and 2.X stream. That makes impossible both version to coexist in the same OSGi instance. I'd like to keep our old code running EMF 1.X, and the newer code running the latest 2.0.

Which is the reason for those to be singletons? Any chance this could change?

Re: org.eclipse.emf.compare singleton bundle? [message #1053080 is a reply to message #1053063]

Thu, 02 May 2013 07:08

Eclipse User

Hi Victor,

Eclipse (Equinox in fact) requires to make bundles singleton as soon as it contributes extensions. This is a limitation from the ExtensionRegistry. We were previously declaring the generated_package EMF extension in the o.e.emf.compare plugin as it is the one containing the generated code of the Comparison model. We moved this generated_package declaration to the o.e.emf.compare.rcp bundle to be more consistent but we forgot to remove the singleton directive.

In conclusion, there is no more reason for this directive to be there. I pushed the change in commit c9e03bd696f9006f4c75270995cf1c54fba47103. It will be integrated in the next integration build.

One last question: do you face the same situation with the o.e.emf.compare.edit plugin? The extension itemProviderAdapterFactories has not been moved to the rcp bundle. Maybe it should so that we could remove the singleton directive from this plugin too. What do you think?

Re: org.eclipse.emf.compare singleton bundle? [message #1053116 is a reply to message #1053080]

Thu, 02 May 2013 10:09

Eclipse User

Mikael,

thanks for the prompt response. Indeed, I myself though about extension points and realized it may be not possible, but luckily the new EMF Compare runtime has no extension points declared / used.

However, the issue still remains for me, as 1.X is singleton, and I believe it cannot be changed (right?). I guess I'll be forced to change 1.X bundle bundle name in our product to workaround this issue. Could you figure out another workaround to this?

Quote:

One last question: do you face the same situation with the o.e.emf.compare.edit plugin? The extension itemProviderAdapterFactories has not been moved to the rcp bundle. Maybe it should so that we could remove the singleton directive from this plugin too. What do you think?

We are currently not using .edit bundle, but if is possible, such a change should be welcome by other clients.

Thanks a lot!
Víctor

Re: org.eclipse.emf.compare singleton bundle? [message #1053227 is a reply to message #1053116]

Fri, 03 May 2013 05:01

Eclipse User

Hi Victor,

Quote:

However, the issue still remains for me, as 1.X is singleton, and I believe it cannot be changed (right?). I guess I'll be forced to change 1.X bundle bundle name in our product to workaround this issue. Could you figure out another workaround to this?

You guess wisely, this can't be changed in 1.x. Other bundles of EMF Compare have some dependencies (through require-bundle) to the o.e.emf.compare bundle. Be careful that you may have to rebuild all of Compare 1.x. I wish we used import-package, it would have simplified the workaround.

BTW, i wish we did use import-package it too for 2.x but we did not... EMF is not a very good citizen / example regarding those concerns.

Quote:

We are currently not using .edit bundle, but if is possible, such a change should be welcome by other clients.

After deeper investigation, we are also declaring an extension point in the .edit bundle and it seems to be the good place to declare it. The singleton directive is then required.

Re: org.eclipse.emf.compare singleton bundle? [message #1053512 is a reply to message #1053227]

Mon, 06 May 2013 07:00

Eclipse User

Mikael,

Quote:

You guess wisely, this can't be changed in 1.x. Other bundles of EMF Compare have some dependencies (through require-bundle) to the o.e.emf.compare bundle. Be careful that you may have to rebuild all of Compare 1.x. I wish we used import-package, it would have simplified the workaround.

I also though I could remove the extension points so I can remove the singleton directive (as long as there are not any users of those extension point in my deployment). That should avoid rebuiliding, hopefully.

Quote:

BTW, i wish we did use import-package it too for 2.x but we did not... EMF is not a very good citizen / example regarding those concerns.

I think using import packages is an old known issue for us all, dont worry about it Wink

Quote:

After deeper investigation, we are also declaring an extension point in the .edit bundle and it seems to be the good place to declare it. The singleton directive is then required.

Thats how the platform works, there nothing else we can do Sad

Thanks for you insight,
Víctor

Re: org.eclipse.emf.compare singleton bundle? [message #1057772 is a reply to message #1053512]

Wed, 08 May 2013 12:20

Eclipse User

Hi Mikael,

regarding EMF Compare 1.X singleton usage, I've checked it and it appears to be a contribution to org.eclipse.core.expressions.propertyTesters (ContentTypePropertyTester). Don't know the exact reason of its usage, but it i think may be possible to refactor this into a new bundle, or move it to a different bundle. That should be enough. I've tested it and, by only removing the singleton usage on org.eclipse.emf.compare, it should be enough to allow users to have EMF Compare 1.X and 2.X in the same OSGi instance, at least the core. What do you think?

Cheers,
Víctor.

Re: org.eclipse.emf.compare singleton bundle? [message #1058276 is a reply to message #1057772]

Mon, 13 May 2013 08:43

Eclipse User

Victor,

If I am not mistaken, the "contentTypePropertyTester" of EMF Compare 1.* was there to workaround the lack of any such tester in early versions of Eclipse. It can probably be entirely replaced with the "org.eclipse.core.resources.contentTypeId" property, allowing us to remove our own.

You might look into that direction since the FilePropertyTester has appeared in 3.2 and we've dropped the support for that version of Eclipse since EMF Compare 1.1.

Please note that there are most likely a number of name collisions (features and bundles alike) since we have never intended for the two to be able to coexist. It would be a "nice to have"... but is not planned yet. If you manage to remove the singleton directives and find out that it solves your issue, feel free to open a review request on gerrit (see the wiki page).

Laurent Goubet
Obeo

Re: org.eclipse.emf.compare singleton bundle? [message #1058820 is a reply to message #1058276]

Wed, 15 May 2013 05:05

Eclipse User

Laurent,

so far, I managed to let both coexist. The only changes I needed was removing singleton directives on o.e.e.compare bundles on both versions (in the case of 1.X stream, I removed contentTypePropertyTester). Fortunately enough, the rest of the bundles that I need do not share the same symbolic name. The core, at least, seems feasible to coexist. Then there is a collision with o.e.e.compare.edit, but its a bundle I dont need.

So, to sum up, it could be feasible to have both versions of the core code, at least. The there are conflicts with other components of the framework, such as .edit bundles. There could possibly be more, but I dont use all the bundles of the framework.

Cheers,
Víctor.

Previous Topic:	Workspace Setup EMF Compare
Next Topic:	[EMF Compare] Exchange ScopeProvider in UI plugin

Goto Forum:

-=] Back to Top [=-

Current Time: Tue Jul 22 15:24:31 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter