Make henshin.interpreter's dependency on eclipse.debug.core optional

[HannesWell]

The (transitive) dependency closure of the org.eclipse.debug.core plugin is quite large and contains heavy-weight plugins like org.eclipse.core.resources, which one wants to avoid if possible. At the same time a great 'core' part of the content of org.eclipse.emf.henshin.interpreter can be used without it perfectly fine, e.g. if one doesn't use the Henshin Interpreter Debug facility.
If that's the case and one doesn't use any of the plugins mentioned above otherwise, having them in a runtime without actually using it is often not desired.
Therefore this PR proposes to make the dependency optional in order to allow avoiding org.eclipse.debug.core and it's dependencies entirely.

An alternative and a bit saver solution would be to move the part of the henshin.interpreter plugin that doesn't need org.eclipse.debug.core into a separate plugin, e.g. henshin.interpreter.core on which henshin.interpreter depends and which it reexports. This way those that already require henshin.interpreter, shouldn't see a difference.

[HannesWell]

@dstrueber could you please have a look at this and tell what's your preferred approach?

[dstrueber]

Thanks for this PR! Making the dependency optional sounds good to me, but I wonder if @mtttichy (who lead the development of the debugging functionality) has any concerns about this.

[HannesWell]

Thanks for this PR! Making the dependency optional sounds good to me, but I wonder if @mtttichy (who lead the development of the debugging functionality) has any concerns about this.

Great. As far as I can oversee it, the types from org.eclipse.debug.core respectively org.eclipse.core.resources are used in the APIs of many if not all henshin-interpreter-debug classes. Therefore if they are called from another Plug-in that plugin probably already has a (strict) dependency on the mentioned Plug-ins, which makes sure that they are available in a runtime where the Debug facility is used.
But of course in general making dependencies optional can be dangerous.
To avoid optional dependencies the split I described in my initial post would be the alternative solution, but then one needs re-exports dependencies and gets split-packages, which is both also not nice.
Therefore I don't see an ideal solution here, unless some classes can also be moved into another package. If the latter would be possible, at least split-packages could be avoided.

[mtttichy]

Thanks for your work on Henshin! That is much appreciated.

I personally would prefer a clean architectural solution to the problem. So i probably prefer the second solution. The first one could lead to unintended and difficult to debug problems for users, right?

Another option could be to simply revert the debugging commits.

As i dont have any time to work on Henshin in the next few years and currently no one in my group uses henshin, i let you decide on the way forward.

[HannesWell]

I personally would prefer a clean architectural solution to the problem. So i probably prefer the second solution. The first one could lead to unintended and difficult to debug problems for users, right?

Theoretically yes, but in practice I would assume that these cases are rare (but I cannot guarantee that they are impossible).

Another option could be to simply revert the debugging commits.

If strict API stability isn't a concern I would suggest to move the debug functionality into a separate Plugin named o.e.henshin.interpreter.debug instead of moving the other part into a 'interpreter.core' plugin and make sure that there are no overlapping/split-packages which only affects a fraction of the debug-classes so that one can also Import-Package without problems.
This means that existing users would have to adapt their required bundles/imported-packages and some imports when updating to the latest Henshin version, but if that's acceptable. This would be my preferred solution.

[mtttichy]

hmm.. one needs to check the feasibility of your split proposal. I am not sure whether this is indeed possible. It could be that the debugging classes (e.g. StackFrame) are pretty deeply integrated into the interpreter. This could be - unfortunately - a major refactoring.

[dstrueber]

My hope for making the import of org.eclipse.debug.core optional was that it would only limit the debugging functionality, not the core interpreter functionality, if the plugin is not loaded. In that case, it would be feasible to just print out/display a warning in case a user who doesn't have the optional plugin loaded wants to use debugging.

However, given that the debugging classes are deeply wired into the core interpreter functionality, I'm becoming more skeptical if this is feasible.

[HannesWell]

I'll take a look at it, if it's feasible and check potential implications. But first I'll work on a verification build (#5) so that we can see immediately if everything compiles.

[HannesWell]

If strict API stability isn't a concern I would suggest to move the debug functionality into a separate Plugin named o.e.henshin.interpreter.debug instead of moving the other part into a 'interpreter.core' plugin and make sure that there are no overlapping/split-packages which only affects a fraction of the debug-classes so that one can also Import-Package without problems.

I have now update this PR to implement this proposal and moved all Interpreter Debug related to a new plugin named org.eclipse.emf.henshin.interpreter.debug.
Actually this was pretty much straightforward, except for a little adjustment that is actually a simplification that I moved into #46, so I hope I didn't miss anything. But the code compiles well and all tests pass (except for the always flaky one).

An alternative and a bit saver solution would be to move the part of the henshin.interpreter plugin that doesn't need org.eclipse.debug.core into a separate plugin, e.g. henshin.interpreter.core on which henshin.interpreter depends and which it reexports. This way those that already require henshin.interpreter, shouldn't see a difference.

This would also be a solution, which should be similar to this, except that what is now (with this PR) is henshin.interpreter becomes henshin.interpreter.core and what is henshin.interpreter.debug becomes/stays henshin.interpreter. So it would basically just be a shift basically a shift.
Which solution should be preferred depends IMO on what you consider the main part of the henshin.interpreter plugin. If it's everything except of the debugger and you consider the latter an addition, then I would go with the current state. But if you consider everything 'cory' plus the debugger as the main part, then keeping henshin.interpreter with a rexport of a henshin.interpreter.core would be probably more suitable.

A third option would be to, instead of introducing a new plugin, to just move all interpreter-debug classes into o.i.emf.henshin.interpreter.ui.
As a Debugger is actually a UI feature, this would also make sense from an architectural point of view. And as the henshin.interpreter.ui plugin already depends on the henshin.interpreter plugin, it wouldn't require anything new for all that require it. Only those that only use the debugger without UI now would have to move to the UI plugin. But I cannot tell, if that even makes sense?

I personally would consider just moving the debug facility into the interpreter.ui plugin the most simple solution and therefore prefer it. But we are also not using the UI, so I cannot tell how others think about it.
What's your preferred solution respectively your thoughts on this topic?

[HannesWell]

I personally would consider just moving the debug facility into the interpreter.ui plugin the most simple solution and therefore prefer it. But we are also not using the UI, so I cannot tell how others think about it.
What's your preferred solution respectively your thoughts on this topic?

@dstrueber, @mtttichy could please let me know what's your opinion about this so I can adapt the PR accordingly?

[HannesWell]

@dstrueber, @mtttichy could you please provide an update on the pending questions?