chore: Make com.microsoft.copilot.eclipse.ui.test a fragment bundle of com.microsoft.copilot.eclipse.ui bundle

[travkin79]

Make com.microsoft.copilot.eclipse.ui.test a fragment bundle of com.microsoft.copilot.eclipse.ui bundle. This way, tests in com.microsoft.copilot.eclipse.ui.test can access package-private methods in com.microsoft.copilot.eclipse.ui bundle and we don't need to make them public. In addition, we no longer need to maintain redundant plug-in dependencies in the test bundle.

This is similar to the com.microsoft.copilot.eclipse.core.test bundle being a fragment bundle with com.microsoft.copilot.eclipse.core as the host bundle.

The PR #330 would benefit from changes in this PR, we could make some methods package-private that are public today in order to be accessible from tests n the test bundles. Improvement suggestion from PR #330:

Make test bundles fragments: Make com.microsoft.copilot.eclipse.ui.test bundle (and maybe other test bundles, too) a fragment bundle instead of a separate OSGi bundle (use Fragment-Host entry in MANIFEST.MF). This way we can avoid making production code package-private methods public, just for testing them from a test bundle. The following methods, for example, should all be package-private, not public: in BrowserConversationJavaJsBridge: escapeForJs, insertBlockScript, insertBlockBeforeScript, replaceBlockScript, removeBlockScript, collapseThinkingBlockScript, updateThinkingBodyTextScript, updateThinkingBlockTitleScript and UiUtils.isDark.

[Copilot]

Pull request overview

This PR updates the com.microsoft.copilot.eclipse.ui.test bundle to be an OSGi fragment of the com.microsoft.copilot.eclipse.ui host bundle, enabling UI tests to access package-private implementation without widening production API visibility and reducing redundant test-bundle dependencies.

Changes:

• Converted com.microsoft.copilot.eclipse.ui.test into a fragment bundle via Fragment-Host and simplified its bundle dependencies.
• Introduced fragment.xml to contribute test-specific Eclipse extensions (marker + editor registration).
• Updated build packaging to include fragment.xml instead of plugin.xml.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File	Description
com.microsoft.copilot.eclipse.ui.test/META-INF/MANIFEST.MF	Declares the test bundle as a fragment of com.microsoft.copilot.eclipse.ui and trims redundant dependencies.
com.microsoft.copilot.eclipse.ui.test/fragment.xml	Adds fragment-level extension contributions needed by integration tests (marker + editor).
com.microsoft.copilot.eclipse.ui.test/build.properties	Packages fragment.xml in the built test fragment.

[jdneo]

Potential regression in NesAnnotationTypeMappingTest after converting the test plug-in to a fragment:

Equinox qualifies a simple <extension id> with the contribution's default namespace. For a fragment, that namespace is the host bundle, so this declaration now registers the marker as:

com.microsoft.copilot.eclipse.ui.foreignTextMarker

However, NesAnnotationTypeMappingTest still looks up:

com.microsoft.copilot.eclipse.ui.test.foreignTextMarker

That old marker ID is no longer registered. AnnotationTypeLookup#getAnnotationType(...) returns null for it, and both current assertNotEquals(...) assertions still pass, so the test becomes vacuous.

Could we either update the test constant to the host-qualified ID, or fully qualify the extension ID to preserve the old namespace? It would also be useful for the test to assert that the intended marker contribution is registered before checking its annotation mapping.

I checked the other fragment contributions and ID references in this repository. This is the only analogous occurrence: fragment.xml has no other extension-level id. The editorForRefactorRenameTests value is a nested editor attribute that the workbench reads verbatim, so it is unaffected, and the other fragment bundles do not contribute extension descriptors.

[travkin79]

Thank you for this hint @jdneo,
It turns out, in testForeignTextMarkerSubtypeDoesNotResolveToNesAnnotations() AnnotationTypeLookup#getAnnotationType(...) always returns null, so the test case is weak anyway. I suggest to adapt the ID to FOREIGN_TEXT_MARKER = "com.microsoft.copilot.eclipse.ui.foreignTextMarker" and to add the following check to the test:

...
// assert our marker type is properly registered
assertTrue(isMarkerTypeDeclared(FOREIGN_TEXT_MARKER));
...


  private boolean isMarkerTypeDeclared(String markerTypeId) {
    IExtensionPoint point = Platform.getExtensionRegistry().getExtensionPoint(ResourcesPlugin.PI_RESOURCES, "markers");
    for (IExtension ext : point.getExtensions()) {
      if (markerTypeId.equals(ext.getUniqueIdentifier())) {
        return true;
      }
    }
    return false;
  }

This way, the test would fail with the ID "com.microsoft.copilot.eclipse.ui.test.foreignTextMarker", but succeeds with the adapted ID "com.microsoft.copilot.eclipse.ui.foreignTextMarker".