Home » Modeling » Compare » org.eclipse.emf.compare singleton bundle?(why is it org.eclipse.emf.compare singleton?)
| | |
Re: org.eclipse.emf.compare singleton bundle? [message #1053227 is a reply to message #1053116] |
Fri, 03 May 2013 09:01 |
Mikael Barbero Messages: 55 Registered: July 2009 |
Member |
|
|
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.
Best regards,
Mikael Barbero
Obeo
|
|
|
Re: org.eclipse.emf.compare singleton bundle? [message #1053512 is a reply to message #1053227] |
Mon, 06 May 2013 11:00 |
Victor Roldan Betancort Messages: 524 Registered: July 2009 |
Senior Member |
|
|
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
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
Thanks for you insight,
Víctor
|
|
| |
Re: org.eclipse.emf.compare singleton bundle? [message #1058276 is a reply to message #1057772] |
Mon, 13 May 2013 12:43 |
|
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 09:05 |
Victor Roldan Betancort Messages: 524 Registered: July 2009 |
Senior Member |
|
|
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.
|
|
|
Goto Forum:
Current Time: Mon Sep 23 09:08:29 GMT 2024
Powered by FUDForum. Page generated in 0.04534 seconds
|