Today I extended my current implementation a bit so that I now extract the currently injected fields in a class and display them in the dialog one can open from within the JavaEditor. The following videos present shows this in action.
The next step is to add injected services through the Dialog. People asked in comments of the last post whether this support is isolated to e4 and it’s services and the answer is no. The current implementation simply registers a service in the OSGi-ServiceRegistry.
public interface IDIServiceRegistry { public void addServiceProvider(IDIServiceProvider descriptor); public void removeServiceProvider(IDIServiceProvider descriptor); public List<IDIServiceProvider> getProviders(); }
Potential Tool implementors can use and provide informations about available services who are probably available at runtime. As an example implementation I’ve implemented 2 example bundles who contribute providers for e4-core services using DS (you see in the screencast that no available services are there until the tooling bundles are started).
The contribution of the Logger-Service is done looks like this:
public class LoggerProvider extends DIServiceProvider implements IDIServiceProvider { public LoggerProvider() { System.err.println("Instance created"); } public String getLabel() { return "Logger Service"; } public String getDescription() { return "Logging warnings, errors, information, as well as capturing debug and trace information. Everything done through this interface is not meant for normal end users. Strings are not expected to be translated."; } public String getServiceClassName() { return "org.eclipse.e4.core.services.Logger"; } public String getBundle() { return "org.eclipse.e4.core.services"; } public String getProduct() { return "e4"; } public String getCategory() { return "Core Services"; } }
and contributed like this using DS:
<?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" enabled="true" immediate="true" name="org.eclipse.e4.core.services.jdt"> <implementation class="org.eclipse.e4.core.services.jdt.LoggerProvider"/> <service> <provide interface="org.eclipse.e4.ui.jdt.IDIServiceProvider"/> </service> </scr:component>
After having implemented the Class-Modification. I think the next logic step would be to write some PDE-Addon which simply registers all available DS-Services found in the Target-Platform into the DI-Registry. I’m still in an experimental stage so probably this is all crap and one has to address the problem differently.
Anyways I’ve learned something about IJavaProject and the AST-Stuff coming with JDT and it’s been a lot of fun so far.
Hmmm – Dialogs bite. 🙂 Why isn’t this a View?
Good idea let’s see how this works out.
great ! … first steps into the direction of DS tooling 🙂
ekke
This would be a starting point, but… it does not really help with the cases, where I believe DI really sucks: ContextInjectionFactory.invoke and friends…
Right but let’s solve things step by step.