Inline o.e.jdt.launching.macosx into jdt.launching

[HannesWell]

What it does

This simplifies the assembly of Eclipse runtimes on MacOS.

Fixes #849

Author checklist

• I have thoroughly tested my changes
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[HannesWell]

Before this is submitted, the plugin should also be removed from the JDT feature:
https://github.com/eclipse-jdt/eclipse.jdt/blob/696fa4f553ce2cbc9389d20422e54654a8561a15/org.eclipse.jdt-feature/feature.xml#L117-L120

I can provide a PR for that as well.
And will remove all references to the plugin introduced to handle the current situation.

[HannesWell]

@iloveeclipse what do you think about this effort respectively can you tell who else would be interested?

[iloveeclipse]

@HannesWell : technically the change should work.

I just have some weird feeling hard coding previously separately contributed extension & bundle, but I also don't see how it would be possible today to avoid that this extension is being used on Mac, so it is "implicitly" hard coded to be always contributed, except one manipulates extension registry via code.

Looking at the bundle history, I see it was originally using native scripts and binaries to launch something on Mac. That was probably the reason why it was provided as separated bundle. See for example c8ace81 or 9b792ae.

I'm not sure if we would need to have some special native bits again on Mac in the future.

[eclipse-jdt-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

org.eclipse.jdt.debug.ui/META-INF/MANIFEST.MF
org.eclipse.jdt.debug.ui/pom.xml

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 0ae32b879ed6c66c403db57fed00e15d3a21ebb5 Mon Sep 17 00:00:00 2001
From: Eclipse JDT Bot <jdt-bot@eclipse.org>
Date: Mon, 8 Jun 2026 18:00:59 +0000
Subject: [PATCH] Version bump(s) for 4.41 stream


diff --git a/org.eclipse.jdt.debug.ui/META-INF/MANIFEST.MF b/org.eclipse.jdt.debug.ui/META-INF/MANIFEST.MF
index d79023ca1..a36b0b98a 100644
--- a/org.eclipse.jdt.debug.ui/META-INF/MANIFEST.MF
+++ b/org.eclipse.jdt.debug.ui/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.jdt.debug.ui; singleton:=true
-Bundle-Version: 3.15.400.qualifier
+Bundle-Version: 3.15.500.qualifier
 Bundle-Activator: org.eclipse.jdt.internal.debug.ui.JDIDebugUIPlugin
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
diff --git a/org.eclipse.jdt.debug.ui/pom.xml b/org.eclipse.jdt.debug.ui/pom.xml
index 8f60cab50..743144ba4 100644
--- a/org.eclipse.jdt.debug.ui/pom.xml
+++ b/org.eclipse.jdt.debug.ui/pom.xml
@@ -18,7 +18,7 @@
   </parent>
   <groupId>org.eclipse.jdt</groupId>
   <artifactId>org.eclipse.jdt.debug.ui</artifactId>
-  <version>3.15.400-SNAPSHOT</version>
+  <version>3.15.500-SNAPSHOT</version>
   <packaging>eclipse-plugin</packaging>
   <properties>
   	<defaultSigning-excludeInnerJars>true</defaultSigning-excludeInnerJars>
-- 
2.54.0

Further information are available in Common Build Issues - Missing version increments.

[HannesWell]

I just have some weird feeling hard coding previously separately contributed extension & bundle, but I also don't see how it would be possible today to avoid that this extension is being used on Mac, so it is "implicitly" hard coded to be always contributed, except one manipulates extension registry via code.

Agree. But I don't have a better idea to restore the exact state as before. I'm not aware that Extensions can be contributed conditionally in a plugin.xml.
For me the question is, if there is a real chance that anybody is intercepting the contribution of that extension?
Although I assume the chance is low (I assume one can also not intercept regular VMInstallTypes for other platforms?), I changed the check to still check the extension registry first and only use the hard-coded implementation as back-up.
This way, external contributions are still considered.

Looking at the bundle history, I see it was originally using native scripts and binaries to launch something on Mac. That was probably the reason why it was provided as separated bundle. See for example c8ace81 or 9b792ae.

I'm not sure if we would need to have some special native bits again on Mac in the future.

I cannot say that, but I hope not.
Nevertheless in case native code is necessary again, the FFM API could be used without the need for real native code. And a few extra classes or resources just for Mac would IMO not hurt.
And if the situation changes completely and it becomes necessary, we could still reintroduce the separate plugin, reverting that change.

@iloveeclipse if you agree with this and don't have requests for code changes, I can prepare the changes necessary in other repositories as outlined in

• Inline o.e.jdt.launching.macosx into jdt.launching #855 (comment)

[HannesWell]

@iloveeclipse how to proceed here?
Now would be a good time in the release cycle.

[HannesWell]

@iloveeclipse any update on this?
Otherwise, who else would be interested in reviewing this?

[HannesWell]

@iloveeclipse can we proceed with this? I think now would be a good time.
Since neither I nor you (as far as I know) are on Mac, @BeckerWdf can you (or one of your colleagues) or @HeikoKlare help with testing this on a real Mac?

[iloveeclipse]

@SougandhS : I believe you are using Mac? Can you test this patch?

[SougandhS]

Hi @HannesWell
With this patch 2 MacOS X VM is shown in Add new JRE page

EDIT:
I tested it by simply running a child eclipse with your changes. Is it to be checked in a different way ?

[HannesWell]

With this patch 2 MacOS X VM is shown in Add new JRE page

Thank you for testing this!
I believe this is because you still have the to be removed org.eclipse.jdt.launching.macosx fragment in the launched runtime.
In general this change also requires to remove that fragment from the JDT feature:

• Remove deleted org.eclipse.jdt.launching.macosx Plug-in from JDT feature eclipse.jdt#160

I have now added a guard to prevent adding the macOS VM type twice. I think that's still useful in case some installations don't have the fragment properly removed.
It would be great if you could test this again, with and without the org.eclipse.jdt.launching.macosx fragment being removed from the JDT feature to also verify that the mentioned guard works as expected.

[SougandhS]

I tested again with and without eclipse-jdt/eclipse.jdt#160 and it is now not showing twice in both cases.

[SougandhS]

LGTM 👍

[iloveeclipse]

I tested again with and without eclipse-jdt/eclipse.jdt#160 and it is now not showing twice in both cases.

Thanks! OK, let us merge this.

[HannesWell]

Great! Thanks to all of you.