The way we handle this for the legacy code (also an optional dependency) is that the legacy bundle registers a service using the org.eclipse.e4.services extension point. Then code that needs to gets the service from the global context. A returned 'null' means that the bundle isn't there and the code can take appropriate actions (if any). This mechanism uses the service layer/context rather than reflection to determine the availability of the necessary classes. It also avoids the eager loading cases since services themselves are lazy loaded.
Not sure if this will help in the CSS case but it might provide some avenues to look at... Eric Ed Merks <[email protected]> Sent by: [email protected] 04/07/2009 06:11 AM Please respond to E4 Project developer mailing list <[email protected]> To E4 Project developer mailing list <[email protected]> cc Subject Re: [e4-dev] Re: CSS relationship to e4 workbench Gunnar, Well, you still have to be careful about Java wanting to load classes that might not be available. Certainly EMF makes quite heavy use of the type of pattern you describe, i.e., non-reflective code guarded by tests for availability of the classes used in that code. That's how we support stand alone execution with no Eclipse dependencies. Often it's necessary to put the logic in a separate class to prevent Java from eagerly loading it. It's obviously very important to test for proper behavior when the classes aren't available. Cheers, Ed Gunnar Wagenknecht wrote: Kevin McGuire schrieb: 1) The use of optional dependencies is cool, but makes writing more code here tricky since it must be reflective which is brutal to write (I believe Boris has a "reflectify" refactor but that only helps the first time and change/debug is still a challenge). It also is a potential point of introducing errors if we forget to add the CSS plugins to the product since the tooling won't warn you of their absence (being optional). The trick is to only use reflection to verify that an optional dependency is satisfied. Thereafter it's totally fine to call out to a different class which uses the API provided by the optional dependencies directly. An example of this can be found in the Equinox Preferences bundle. org.eclipse.core.internal.preferences.Activator#start org.eclipse.core.internal.preferences.Activator#addingService OSGi services actually do support this very well because you only need to reference the service class by name. -Gunnar _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
