Community
Participate
Working Groups
I have been following the work made by Dave Carver from a distance, and I picked XSL Tools to be included in our product. Sadly, it came with a dependency over JDT. After discussing this with Dave, it appears that he had to do so because of the way the debug framework is coded. I also faced the same issue with BIRT, unless it was Datatools. For our own product, we will probably need to have the ability to run debug sessions at some point. To do so, we will need to be able to plug to the debug support, if possible without having to distribute JDT.
(In reply to comment #0) > I have been following the work made by Dave Carver from a distance, and I > picked XSL Tools to be included in our product. > > Sadly, it came with a dependency over JDT. After discussing this with Dave, it > appears that he had to do so because of the way the debug framework is coded. > > I also faced the same issue with BIRT, unless it was Datatools. > > For our own product, we will probably need to have the ability to run debug > sessions at some point. > > To do so, we will need to be able to plug to the debug support, if possible > without having to distribute JDT. > The reason that we have a dependency on JDT is partially due to the Debug Framework, but mostly due to the fact that we need JVM runtime support, processor configuration, classpath support, etc. All of this is tightly entwined into the JDT instead of being seperated out into a Java Runtime UI and Java Core Runtime set of plugins. The XSL Debugging/Launching can be separated out if you don't use a Java XSLT processor. There are also cases where one wants to include the ANT editor with out JDT, but that currently isn't possible again because of the dependency on some JAVA core features that have nothing to do with Java editing. It's something that would be nice to address so that it's more consumeable. The issue I raised with debugging is that the only unit tests that the platform has are all for the JDT debugger. I would like to figure out some way to set tests that truely just tests the platform debug framework, with out all the JDT Advance functionality. One of the roles of unit tests is to provide examples of how to use a framework, not just verify that code. A well written suite of tests if pretty self documenting on what the framework it is testing does.
A dependency on JDT seems reasonable (even necessary) if you require support for JVMs, Java launching, class path management, etc. Is it the feature structure that makes you believe it is difficult to consume, or the dependencies dragged in by the JDT launching support? In any case, this bug seems more appropriate for the JDT Debug bucket.
(In reply to comment #2) > A dependency on JDT seems reasonable (even necessary) if you require support > for JVMs, Java launching, class path management, etc. Is it the feature > structure that makes you believe it is difficult to consume, or the > dependencies dragged in by the JDT launching support? > > In any case, this bug seems more appropriate for the JDT Debug bucket. > In my particular use case, I don't need the JDT Editor that is part of the jdt.ui. The problem here is that if you want to distribute only the ANT editor you have to also distribute the JDT editor as well. The other issue, and this is partly due to the way the XSL Tools debugger is designed is that it's extending some JDT Debug classes (when it probably should be implementing it's own instead). We do need to have JDT Launching but not necessarily all the inter-related dependencies brought in by the JDT Editor. What I and others need is the ability to have a Feature or be told of a way to package only the items that support Java Runtime and Launching ability, without needing the editor. The last use case is being able to distribute the ANT editor without having to have the JDT Java Editor as well...the issue here when I looked at it was that the ANT Editor leverages some classes that are also used by the JDT Editor so that even though they look like you can distribute them seperately they really aren't due to dependencies. Ideally these dependencies are separated to another plugin that both could depend on and be used if they need them. The overall theme for this bug probably should be that we as eclipse projects need to make our items as consumable independently as possible. But I agree the refactoring or packaging of the features probably best goes in JDT Debug.
(In reply to comment #2) > A dependency on JDT seems reasonable (even necessary) if you require support > for JVMs, Java launching, class path management, etc. Is it the feature > structure that makes you believe it is difficult to consume, or the > dependencies dragged in by the JDT launching support? > > In any case, this bug seems more appropriate for the JDT Debug bucket. > Here is a bit more information. I setup a application launch config to test out the XSL Tools plugins, and started eliminating the various plugins that I wouldn't think I would need. I left org.eclipse.jdt.debug.ui and the launching related plugins...here is what I found: org.eclipse.jdt.debug.ui has a hard dependency on org.eclipse.jdt.ui. Unfortunately at the moment the org.eclipse.wst.xslt.jaxp.debug.ui plugin from XSL Tools has a dependency on org.eclipse.jdt.debug.ui for some if it's classes. So, as you can see, this currently requires the full blown JDT feature set to be brought in along with the Java Editor (which I don't want or need for XSL Tools when dealing with XSLT related items). I've copied the other XSL Tools developer that created the main debugging support for XSLT in XSL Tools so he knows what is going on as well.
Hm... I'm not surprised that jdt.debug.ui requires jdt.ui... Note that the CDT debug support can do without jdt.debug. Perhaps you should start investigating what specificially you need from jdt.debug.ui? Factoring out the ANT editor seems reasonable "from the outside" (I don't know the code), perhaps that should be discussed in a separate bug? A totally different option could be to live with the JDT stuff in your install but hide it by means of a Capability (though I'm not too fond of this approach).
Ant leverages installed JRE's and VM launching from by JDT debug. Thus the dependency. This has been discussed before (but I can't find the old bug currently). My feeling is that nothing will be done here in the 3.x time frame - but there could be an opportunity to separate things differently in e4. The generic launching framework could be seperated from debug, and the JDT launching framework could be separated from JDT debug.
(In reply to comment #5) > Hm... I'm not surprised that jdt.debug.ui requires jdt.ui... Note that the CDT > debug support can do without jdt.debug. Perhaps you should start investigating > what specificially you need from jdt.debug.ui? > What we need is all of the Java Runtime support items. Basically the following: JRE Tab Classpath Tab Having the ability to add the additional JRE's in the preferences would be nice as well. > Factoring out the ANT editor seems reasonable "from the outside" (I don't know > the code), perhaps that should be discussed in a separate bug? > > A totally different option could be to live with the JDT stuff in your install > but hide it by means of a Capability (though I'm not too fond of this > approach). Either am I as it adds extra size and resources with out much added benefit. (In reply to comment #6) > Ant leverages installed JRE's and VM launching from by JDT debug. Thus the > dependency. This has been discussed before (but I can't find the old bug > currently). My feeling is that nothing will be done here in the 3.x time frame > - but there could be an opportunity to separate things differently in e4. The > generic launching framework could be seperated from debug, and the JDT > launching framework could be separated from JDT debug. Well, since adopters aren't necessarily going to do a mass shift to e4 right when it is released, I would like to see this done sooner rather than later. While I understand the history of where the Ant editor came from, there are use cases now where ANT can be used outside of JDT. Particularly as more languages start to leverage the Java VM.
Created attachment 121225 [details] An set of Abstract classes and utility classes for testing the Debugging Framework This is an refactoring or org.eclipse.jdt.debug.tests.AbstractDebugTest to a more general test case, that can be be leveraged by other projects to help test their implementation of the debugging framework. I'll be giving this a test in the XSL Tools incubator project to test our debugging framework implementation.
*** Bug 350438 has been marked as a duplicate of this bug. ***
