Where have all the sources gone?

[stephan-herrmann]

Up until https://download.eclipse.org/eclipse/updates/4.36/R-4.36-202505281830/features/ published SDK contains lots of source features, which upon installation pull in source bundles.

Already in 4.37 and continuing in 4.38-I-builds none of this can be found anymore in the p2 repo, see, e.g.,:

• https://download.eclipse.org/eclipse/updates/4.37/R-4.37-202509050730/features/
• https://download.eclipse.org/eclipse/updates/4.38-I-builds/I20251027-1800/features/

Need I say that this makes investigation of bugs in components which I don't actively work on very hard?

[laeubi]

The feature are not published but the source bundles... so it depends a bit on what setup you use how to enable source downloads there...

[stephan-herrmann]

The feature are not published but the source bundles... so it depends a bit on what setup you use how to enable source downloads there...

Installing "Eclipse SDK" via "Install new software".

[laeubi]

Hm... so you use the running platform as a target? I'm not completely sure about your workflow, usually (wen using oomph) it pulls in the sources automatically, or in your target platfrom you enable to download source... with a SDK downloaded it also should install sources automatically. I'm not sure about when installing SDK in another Eclipse...

[merks]

It's best practice to use a target platform to determine the content of your development environment rather than the content of the running installation. You can simply list the p2 repositories and installable units, specifying includeSource="true":

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde version="3.8"?>
<target name="My Target" sequenceNumber="1">
  <locations>
    <location includeAllPlatforms="true" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
      <unit id="org.eclipse.equinox.executable.feature.group" version="0.0.0"/>
      <unit id="org.eclipse.sdk.feature.group" version="0.0.0"/>
      <repository location="https://download.eclipse.org/eclipse/updates/4.38-I-builds"/>
      <repository location="https://download.eclipse.org/releases/2025-12"/>
      <repository location="https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2025-12"/>
    </location>
  </locations>
</target>

The SDK download does include all sources so you can can that for that purpose:

Indeed there are no more source features and so no general mechanism to install sources into any arbitrary installation. In principle one might add a flag to the install page for installing corresponding sources, but using the running IDE as the target platform is practically an anti-pattern...

[stephan-herrmann]

All "best practices" and "anti-patterns" are subjective.

After my "bad practice" has served me well for decades, stopping to ship source features looks like a plain regression to me. At least an announcement should have been made of it, or did I just miss that?

Thanks anyway for the provided target definition.

It seems I have only two options: abandon long time habits (and hope I don't step into new pitfalls) or refrain from debugging platform issues ;-P

usually (when using oomph) it pulls in the sources automatically

oomph is a splendid hammer, but not everything is a nail.

[merks]

I think most of us with our flooded inboxes assume that anyone who cares is paying attention. Bad assumption.

I think the option to learn new things is a good option, but that's my subjective opinion. 😬

(I'm actually not sure why you don't "simply have an SDK with all source already installed" since that's what is distributed by the Platform, but given this is now water under the bridge, it's not work discussing further.)

It was also announced via simrel-dev, most-recently this:

https://www.eclipse.org/lists/simrel-dev/msg00092.html

No one has spoken out.

[stephan-herrmann]

I think the option to learn new things is a good option, but that's my subjective opinion. 😬

If I'm free to decide what to learn, yes :)

(I'm actually not sure why you don't "simply have an SDK with all source already installed" since that's what is distributed by the Platform, but given this is now water under the bridge, it's not work discussing further.)

That's what I thought. But as my links show, Platform is no longer publishing source features in their p2 repos.

It was also announced via simrel-dev, most-recently this:

https://www.eclipse.org/lists/simrel-dev/msg00092.html

No one has spoken out.

OK, so that's the simrel side of it (where I'm no longer subscribed since Object Teams pulled out of it). I understand that simrel targets end users who normally don't debug eclipse and hence don't need sources. Fair enough.

But this current issue I intentionally filed against eclipse platform ... so if your explanation doesn't hold for the official Eclipse SDK update site, perhaps it should be re-opened?

[merks]

We are definitely not planning to bring source features back. Tycho has removed support for them. They’re history.

The SDK downloads do contain all the source bundles corresponding to all the installed binary bundles

https://download.eclipse.org/eclipse/downloads/drops4/S-4.38M2-202510240020/

I’ve already shared a screen capture showing you that. One of those is easy to unzip/untar the traditional way to keep working the traditional way. That will need to suffice.

[laeubi]

But this current issue I intentionally filed against eclipse platform ... so if your explanation doesn't hold for the official Eclipse SDK update site, perhaps it should be re-opened?

As a matter of bring things forward, the most sustainable option would be PDE.

Since a while we have the concept of IPluginSourcePathLocator extensions that e.g. m2e already provides some and PDE of course as well. These do solve the problem that you actually don't want to install the source, but need them during debug I assume.

So this is not really about source features, but about a long standing initative of mine to actually require "installing" source bundles or bug the user with "how do I get the sources" so I have created:

• Provide a IPluginSourcePathLocator that searches for a source bundle in p2 repostories and other sources eclipse-pde/eclipse.pde#2073

I would suggest to continue discussion there e.g. it would be good what exactly do you use as an IDE? e.g. do you download it from the packages? Because as Ed mentioned "usually" one would use an SDK product that already includes everything.

[merks]

@stephan-herrmann

There may be some misunderstanding here as well. If I take a 4.35 SDK, for example, it has this in the profile:

Therefore corresponding sources are always installed into that IDE. E.g., if I install the XSD feature into 4.35, the source bundle is installed:

And that happens without installing the source feature:

Maybe you have some very old SDK without that profile property that you've been "updating for a very long time"™'?

[stephan-herrmann]

@stephan-herrmann

There may be some misunderstanding here as well.

yes

If I take a 4.35 SDK, for example, it has this in the profile:

you guess correctly. I don't have that entry in what I assume to be the active profile (eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/1761670907289.profile.gz)

Therefore corresponding sources are always installed into that IDE.

that's nice, I want that, too :)

Maybe you have some very old SDK without that profile property that you've been "updating for a very long time"™'?

Sure, don't we all like sustainability and long life? :)

It's actually younger than I thought:

$ ls -ld --time=creation eclipse/
drwxrwxr-x 8 stephan stephan 4096 Apr 14  2017 eclipse/

Are there any means for a user to modify that profile?

[stephan-herrmann]

NB: In a different context I do use a .target file for some time now, so surely I'm not totally out of luck.

I was just quite surprised that such a long standing feature was removed without anybody asking me :)

Eclipse had such a nice tradition that there was one channel of distribution where you are always ready to debug all aspects of a regular self-hosted workbench.

If updating works in a way that it sustains this property from an original SDK download, then all is good.

In that light, perhaps updating the profile was the only thing that was missed when the concept org.eclipse.update.install.sources was "recently" introduced.

[merks]

With 7-Zip you can edit it a file in the archive and it will update it in the archive:

I assume there are command line tools that can unpack and repack a *.tar.gz.