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 [email protected] 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
<<attachment: laurent_goubet.vcf>>
_______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
