0

I'm in the early stages of creating a new Eclipse plug-in in Eclipse 2019-06. I created the plug-in using the "Hello World" wizard option and created a debug configuration that successfully launches a secondary workbench for testing. I can click on my new menu option and step into my new code.

I want to use a modified version of org.eclipse.jdt.junit.wizards.NewTestCaseWizardPageOne, so I added the package to my project and edited NewTestCaseWizardPageOne. However, when I try to debug, the debugger asks for a source location. It seems to want to load the file from the local repository (.p2/pool/plugins/org.eclipse.jdt.junit_3.11.400.v20190510-0840.jar), rather than my edited version. Why is that?

Debugging session

There must be some kind of classpath problem, but don't versions of files in the project have precedence over those in the dependent plugins? I've looked at a number of similar questions (1, 2) and other sources, but I haven't yet found the answer. Please help.

kc2001
  • 5,008
  • 4
  • 51
  • 92
  • 1
    Note: You can't replace a page in a existing wizard. This isn't going to work. – greg-449 Jul 23 '19 at 14:34
  • @greg-499 - Thanks. I'm actually just trying to use some of the import-writing functionality and not the GUI. I'm having problems, but that may be a different question. :o – kc2001 Jul 23 '19 at 14:42
  • Why are you trying to use the original `org.eclipse.jdt....` package name? You can't easily replace bits of an existing plug-in. – greg-449 Jul 23 '19 at 14:47
  • @greg-499 There is package-private functionality I'm trying to access. Is the best solution to update the plugin whose functionality I'm trying to use/extend? BTW, my plug-in is for local use, not for use as a distributed product, so I'm willing to cut corners and accept some kludginess. – kc2001 Jul 23 '19 at 14:56
  • You won't be able to do this. The Eclipse plug-in system will not permit it. – greg-449 Jul 23 '19 at 15:01
  • 1
    You can try to create a fragment for org.eclipse.jdt.ui bundle and create your class there – Alexander Fedorov Jul 24 '19 at 15:21
  • @Alexander - The package fragment idea looks promising. I'll try it. (If you want to turn your comment into an answer, I'll give you credit.) – kc2001 Jul 28 '19 at 21:17

1 Answers1

0

Following Alexander Federov's suggestion, I converted my plugin into a fragment. This was fairly easy to do following the advice from this StackOverflow page. The main changes were:

  • Renamed plugin.xml to fragment.xml and changed the top level xml element from plugin to fragment.
  • Added a Fragment-Host entry to MANIFEST.MF

The key advantage that this provided is discussed in an Eclipse Wiki page:

... a fragment appears much the same as a normal plug-in. A fragment can specify libraries, extensions, and other files. When it is loaded by the platform loader, a fragment is logically, but not physically, merged into the host plug-in. The end result is exactly the same as if the fragment's manifest were copied into the plug-in manifest, and all the files in the fragment directory appear as if they were located in the plug-in's install directory. Thus, a runtime library supplied by a fragment appears on the classpath of its host plug-in. In fact, a Java class in a fragment can be in the same package as a class in the host and will even have access to package-visible methods on the host's classes.

The last part having to do with access to package-visible methods was what I needed. Thanks, Alexander!

kc2001
  • 5,008
  • 4
  • 51
  • 92