It would be an option - but seems to me to be too much work. I also don't particularly like the idea of having org.eclipse.ui.* packages floating about the ecosystem that aren't the real ones.
Thanks Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Thu, 15 Apr 2021 at 09:16, Christoph Läubrich <lae...@laeubi-soft.de> wrote: > Wouldn't it be an option to simply supply a "cli-only" bundle that > supplies the missing interfaces with dummy implementations? > > Am 15.04.21 um 15:04 schrieb Jonah Graham: > > > > On Thu, 15 Apr 2021 at 08:38, Christoph Läubrich <lae...@laeubi-soft.de > > <mailto:lae...@laeubi-soft.de>> wrote: > > > > I think there is no "one fits all". Optional dependency are really > > problematic to handle right and should be avoided as they often mean > > your bundle/services are not well shaped. > > > > > > Thanks - I do agree. > > > > If you describe your case it might be possible to give some more > advice. > > > > > > The issue is we (CDT project) have a bundle that has been around for a > > very long time. It is supposed to be a "core" bundle, but has some UI > > dependencies in it. This bundle is used headlessly today, and there are > > UI code paths than when run headlessly are effectively no-ops. > > > > Most of the dependencies on the UI are relatively easy to resolve. > > However one area is in the API - the API includes references > > to org.eclipse.ui.dialogs.IOverwriteQuery, and in the headless case > > these references are null. > > > > We would like to refactor the code so that an installation can be made > > that has no UI bundles included in it. The long plan is to deprecate and > > remove the code that depends on UI, but in the meantime we wanted to > > make the UI dependency optional. > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=572850 > > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=572850> tracks the > actual > > work. > > > > Thanks > > Jonah > > > > > > > > Am 15.04.21 um 13:38 schrieb Jonah Graham: > > > Hello, > > > > > > (Not sure this is on topic for the list - but not sure where to > ask.) > > > > > > What is the canonical way to check if an optional dependency is > > available? > > > > > > I know of a couple of methods: > > > > > > 1. wrapping code in try/catch and catching something wide like > > Throwable > > > or NoClassDefFoundError > > > 2. checking for bundle status (e.g. calling > > > Platform.getBundle(symbolicName) and Bundle.getState) > > > > > > Thank you. > > > Jonah > > > > > > > > > > > > > > > ~~~ > > > Jonah Graham > > > Kichwa Coders > > > www.kichwacoders.com <http://www.kichwacoders.com> > > <http://www.kichwacoders.com <http://www.kichwacoders.com>> > > > > > > _______________________________________________ > > > platform-dev mailing list > > > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org> > > > To unsubscribe from this list, visit > > https://www.eclipse.org/mailman/listinfo/platform-dev > > <https://www.eclipse.org/mailman/listinfo/platform-dev> > > > > > _______________________________________________ > > platform-dev mailing list > > platform-dev@eclipse.org <mailto:platform-dev@eclipse.org> > > To unsubscribe from this list, visit > > https://www.eclipse.org/mailman/listinfo/platform-dev > > <https://www.eclipse.org/mailman/listinfo/platform-dev> > > > > > > _______________________________________________ > > platform-dev mailing list > > platform-dev@eclipse.org > > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > > > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
