[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] 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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
