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