leoroos/sandboxdroog — Issue #49: Hot Deployment in Production
Author: leoroos
Created: 2011-10-18 15:37:39+00:00
State: open

For a full IDE experience it must be possible to work with Tigerseye languages as it is possible with Java Projects.
In the same project a language should be possible to be developed and used.

== Accessing a Plug-in that extends dslDefinitions in the Eclipse workspace ==
The obstacle for Tigerseye Projects lies in its dependence on a registration of a DSL providing plug-in.
The extension registry is only at runtime available. Hence a project in the same workspace as the DSL can not use it
since the Tigerseye Plug-in has not yet knowledge of that DSL since it only knows the registered DSL plug-ins.

== Update Classes Already Loaded in the Bundle Classloader ==
A more subtle problem is connected to the classloading. Once classes are loaded into a classloader a modification of
the physical counterpart won't effect them. They have to be "updated"
I already have a solution for that when testing Tigerseye in a development Eclipse instance. It is possible, though somewhat cryptic, to access the OSGI services which support a refresh of classes at runtime. This is handled by the DSLResourceHandler which tries to refresh each DSL Bundle everytime before a transformation takes place.

== Consistent Solution ==

=== Workspace Projects ===
A satisfactorily solution (for workspace projects) would be to, of course, add the default classpath from workspace plugins. In development mode the bundles are loaded into the workspace as well. This should happen before the classpath of those is resolved, that would support a consistent use (currently the linked projects are considered first when they already have been linked into the workspace before)

=== DSL plug-ins From Installed Bundles ===
For dependent on bundles I should consider to add language plug-ins directly to the required plug-ins classpath. By doing that OSGI would be responsible to resolve all further dependencies. A drawback is of course to potentially to have a lot of extra dependencies forced upon the plug-in that uses the language.
Check out:
- `JavaCore.getClasspathContainer(containerPath, project)`
- `org.eclipse.pde.internal.core.PDEClasspathContainer.getExternalEntries(IPluginModelBase model)`
- RequiredPluginsClasspathContainer