Re: [cross-project-issues-dev] p2 and optional not too greedy dependencies
There might be a better, p2-based solution, but I think you can move the problem from installation time to runtime: 1. Make the dependency from o.e.e.c.egit to EGit optional and non-greedy, so o.e.e.c.egit doesn't pull in EGit 2. Always include o.e.e.c.egit in your install 3. At runtime, check in o.e.e.c.egit if EGit is present and o.e.e.c.egit can do its thing. Otherwise just ignore it. On 25.11.2014 10:47, Laurent Goubet wrote: Hi all, I'd like the help of p2 experts on a little issue... This question is for emf compare, in namespace org.eclipse.emf.compare. For the sake of brevity, I'll abbreviate this namespace as o.e.e.c everywhere. We have a number of plugins that get installed through a feature, among which is plugin 'o.e.e.c.ide'. We support comparisons for specific files (namely, files representing EMF models) either 'with each other' or 'with a repository version'. This repository can be git, svn, cvs... through either EGit, Subversive, Team's CVS support... Our base implementation is generic and only uses the eclipse Team APIs... but in order to support some of the repository providers' quirks, we are forced to depend on them to use their specific APIs. We have done so in isolated plugins, separated in support for xxx features that the user needs to install manually. For example, if the user uses EGit and wishes to compare his models through that provider, he needs to install the EGit support feature, which contains a single bundle, o.e.e.c.egit. But this feature is not so obvious and the generic support will behave strangely as long as it is not installed. What I'd like is for this bundle to be installed automatically with EMF Compare if EGit is already installed in the environment, but not force the installation of EGit if it is not. I am not sure whether optional dependencies can get me there. case 1 : o.e.e.c.ide has an optional, non-greedy dependency towards o.e.e.c.egit, which has a non-optional dependency on egit. case 2 : o.e.e.c.ide has an optional, greedy dependency towards o.e.e.c.egit, which has a non-optional dependency on egit. In case 1, I believe that o.e.e.c.egit will never be installed automatically, even if its dependency, EGit, is present in the environment? In case 2, however, my understanding is that o.e.e.c.egit will always be installed as long as EGit is accessible i.e. even if it is not installed, if it is reachable through the registered repository URIs, p2 will install it along? Note that currently, o.e.e.c.ide does not even depend on o.e.e.c.egit : the dependency is not needed, we just think that p2 will need it somehow if we want this automatic installation to happen one way or another. In other words, what we'd like is : if the user selects the feature EGit support for EMF Compare in p2, then EGit will be installed along. After all, we need it and in this particular case, the user has asked for it. But if he does not select that feature, we'd like the support bundle, o.e.e.c.egit, to still be installed if and only if EGit already is (or has been selected for install)... Greedy, but not too much :p. Is that possible through p2.inf or anything? Regards, Laurent Goubet Obeo ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] p2 and optional not too greedy dependencies
Thanks for the suggestion Carsten, this would be possible, but only through the use of very quirky workarounds. Namely, this optional plugin depends on egit for proper compilation and provides adapter factories (org.eclipse.core.runtime.adapters) that directly depend on EGit APIs. If I were to make that dependency optional, I'd need to make the adapter factory completely independent from egit (there mustn't be any org.eclipse.egit.* imports in that class, lest I deal with LinkageErrors of some sort (IIRC, this case is a NoClassDefFoundError)). I would thus need to create a proxy which sole responsibility would be to check for the presence of EGit in its classpath and either delegate to the actual adapter factory or return null (which in itself is also a weird behavior : I tell the platform that I can adapt SomeClass into SomeOther, yet I still return it a null). Not to mention I'd have to do that for every single egit-dependent class, and that these proxies would be called very often even if they can't do a thing. So yes, that would be a workaround... but I'd really rather be able to properly tell that my plugin _does_ depend on EGit, and tell p2 that it is an important dependency of another of my plugins that should be installed if all of its own requirements are met. On 25/11/2014 13:53, Carsten Reckord wrote: There might be a better, p2-based solution, but I think you can move the problem from installation time to runtime: 1. Make the dependency from o.e.e.c.egit to EGit optional and non-greedy, so o.e.e.c.egit doesn't pull in EGit 2. Always include o.e.e.c.egit in your install 3. At runtime, check in o.e.e.c.egit if EGit is present and o.e.e.c.egit can do its thing. Otherwise just ignore it. On 25.11.2014 10:47, Laurent Goubet wrote: Hi all, I'd like the help of p2 experts on a little issue... This question is for emf compare, in namespace org.eclipse.emf.compare. For the sake of brevity, I'll abbreviate this namespace as o.e.e.c everywhere. We have a number of plugins that get installed through a feature, among which is plugin 'o.e.e.c.ide'. We support comparisons for specific files (namely, files representing EMF models) either 'with each other' or 'with a repository version'. This repository can be git, svn, cvs... through either EGit, Subversive, Team's CVS support... Our base implementation is generic and only uses the eclipse Team APIs... but in order to support some of the repository providers' quirks, we are forced to depend on them to use their specific APIs. We have done so in isolated plugins, separated in support for xxx features that the user needs to install manually. For example, if the user uses EGit and wishes to compare his models through that provider, he needs to install the EGit support feature, which contains a single bundle, o.e.e.c.egit. But this feature is not so obvious and the generic support will behave strangely as long as it is not installed. What I'd like is for this bundle to be installed automatically with EMF Compare if EGit is already installed in the environment, but not force the installation of EGit if it is not. I am not sure whether optional dependencies can get me there. case 1 : o.e.e.c.ide has an optional, non-greedy dependency towards o.e.e.c.egit, which has a non-optional dependency on egit. case 2 : o.e.e.c.ide has an optional, greedy dependency towards o.e.e.c.egit, which has a non-optional dependency on egit. In case 1, I believe that o.e.e.c.egit will never be installed automatically, even if its dependency, EGit, is present in the environment? In case 2, however, my understanding is that o.e.e.c.egit will always be installed as long as EGit is accessible i.e. even if it is not installed, if it is reachable through the registered repository URIs, p2 will install it along? Note that currently, o.e.e.c.ide does not even depend on o.e.e.c.egit : the dependency is not needed, we just think that p2 will need it somehow if we want this automatic installation to happen one way or another. In other words, what we'd like is : if the user selects the feature EGit support for EMF Compare in p2, then EGit will be installed along. After all, we need it and in this particular case, the user has asked for it. But if he does not select that feature, we'd like the support bundle, o.e.e.c.egit, to still be installed if and only if EGit already is (or has been selected for install)... Greedy, but not too much :p. Is that possible through p2.inf or anything? Regards, Laurent Goubet Obeo ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your
Re: [cross-project-issues-dev] p2 and optional not too greedy dependencies
Keep in mind that even if you get the scenario where EGit is installed first working as you desire, you will still have to contend with the case where EGit is installed after your plugins. - Konstantin -Original Message- From: cross-project-issues-dev-boun...@eclipse.org [mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Carsten Reckord Sent: Tuesday, November 25, 2014 6:36 AM To: Cross project issues Subject: Re: [cross-project-issues-dev] p2 and optional not too greedy dependencies On 25.11.2014 14:33, Laurent Goubet wrote: If I were to make that dependency optional, I'd need to make the adapter factory completely independent from egit (there mustn't be any org.eclipse.egit.* imports in that class, lest I deal with LinkageErrors of some sort (IIRC, this case is a NoClassDefFoundError)). I would thus need to create a proxy which sole responsibility would be to check for the presence of EGit in its classpath and either delegate to the actual adapter factory or return null (which in itself is also a weird behavior : I tell the platform that I can adapt SomeClass into SomeOther, yet I still return it a null). I would do it a bit differently. I'd keep the adapter class as-is and determine statically, e.g. at bundle startup, if it can be used. Then I would either register the adapter to the appropriate registries or not, based on that outcome. Or, if it's done via extension point, maybe the point supports enablement criteria using org.eclipse.core.expressions. If that's the case, putting the enablement logic into a property tester should be easy enough. So yes, that would be a workaround... but I'd really rather be able to properly tell that my plugin _does_ depend on EGit, and tell p2 that it is an important dependency of another of my plugins that should be installed if all of its own requirements are met. Agreed, that would be a nicer solution. ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
