Target Platform definition fails to download nonexisting source bundle when nattable 2.6.0 repository is listed

[haubi]

So I fail to figure out what could cause this error message,
seen in the Target Editor as of Eclipse Staging 2025-12 (as provided by Oomph, today 2025-10-07):

Can't download artifact osgi.bundle,org.eclipse.core.filesystem.linux.aarch64.source,1.4.200.v20220812-1420 required by org.eclipse.core.filesystem.linux.aarch64.source[1.4.200.v20220812-1420], org.eclipse.pde.core.target.source.bundles[1.0.0] from any of the following repositories: 
file:///workspace/haubi/eclipse/committers-staging/eclipse/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/
file:/home/haubi/.p2/org.eclipse.equinox.p2.core/cache/
file:/home/haubi/.p2/pool/.eclipseextension
file:/workspace/haubi/eclipse/committers-staging/eclipse/configuration/org.eclipse.osgi/226/data/listener_1925729951/
file:///home/haubi/.p2/pool/
file:/workspace/haubi/eclipse/committers-staging/eclipse/.metadata/.plugins/org.eclipse.pde.core/.p2/org.eclipse.equinox.p2.core/cache/
https://download.eclipse.org/releases/2025-09/202509101001/
https://download.eclipse.org/nattable/releases/2.6.0/repository/

This happens on some test.target file having this content:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde?>
<!-- generated with https://github.com/eclipse-cbi/targetplatform-dsl -->
<target name="Test" sequenceNumber="1759855312">
  <locations>
    <location includeMode="slicer" includeAllPlatforms="true" includeSource="true" includeConfigurePhase="false" type="InstallableUnit">
      <unit id="org.eclipse.core.filesystem.linux.aarch64" version="1.4.200.v20220812-1420"/>
      <repository location="https://download.eclipse.org/releases/2025-09/202509101001/"/>
    </location>
    <location includeMode="slicer" includeAllPlatforms="true" includeSource="true" includeConfigurePhase="false" type="InstallableUnit">
      <repository location="https://download.eclipse.org/nattable/releases/2.6.0/repository/"/>
    </location>
  </locations>
</target>

It does work when:

• I remove that nattable/releases/2.6.0/repository location,
• or when I use nattable/releases/2.5.0/repository instead,
• or when I add releases/2025-03/ repository as well, for really providing that source bundle.

As far as I understand, that one source bundle should be gone since #1772,
but how can the pure listing of that nattable/2.6.0/repository make a difference here?

Thanks!

[merks]

FYI @fipro78

Unfortunately the nebula repository has some rather nasty references to other repositories:

    <repository uri='https://download.eclipse.org/eclipse/updates/4.32/R-4.32-202406010610' url='https://download.eclipse.org/eclipse/updates/4.32/R-4.32-202406010610' type='0' options='1'/>
    <repository uri='https://download.eclipse.org/eclipse/updates/4.32/R-4.32-202406010610' url='https://download.eclipse.org/eclipse/updates/4.32/R-4.32-202406010610' type='1' options='1'/>
    <repository uri='https://download.eclipse.org/nebula/releases/latest' url='https://download.eclipse.org/nebula/releases/latest' type='0' options='1'/>
    <repository uri='https://download.eclipse.org/nebula/releases/latest' url='https://download.eclipse.org/nebula/releases/latest' type='1' options='1'/>
    <repository uri='https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/milestone/latest' url='https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/milestone/latest' type='0' options='1'/>
    <repository uri='https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/milestone/latest' url='https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/milestone/latest' type='1' options='1'/>

Your target works when I add followRepositoryReferences="false":

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde?>
<!-- generated with https://github.com/eclipse-cbi/targetplatform-dsl -->
<target name="Test" sequenceNumber="1759855312">
  <locations>
    <location includeMode="slicer" includeAllPlatforms="true" includeSource="true" includeConfigurePhase="false" type="InstallableUnit">
      <unit id="org.eclipse.core.filesystem.linux.aarch64" version="1.4.200.v20220812-1420"/>
      <repository location="https://download.eclipse.org/releases/2025-09/202509101001/"/>
    </location>
    <location includeMode="slicer" includeAllPlatforms="true" includeSource="true" includeConfigurePhase="false" type="InstallableUnit" followRepositoryReferences="false">
      <repository location="https://download.eclipse.org/nattable/releases/2.6.0/repository/"/>  
    </location>
  </locations>
</target>

I really don't have the cycles to track down why all the bad repository references cause problems. 😢

[fipro78]

@merks

Unfortunately the nebula repository has some rather nasty references to other repositories

Do you mean the Nebula or the NatTable repository? And why they are nasty? I mean you and @laeubi suggested to build the NatTable update site in this way to avoid that the NatTable dependencies are included.

I really don't have the cycles to track down why all the bad repository references cause problems.

I really don't understand what you mean with "bad repository references". Why they are bad? How should that be changed? What would be a "good repository reference"?

[laeubi]

I don't understand the issue here and it is maybe more due to

The target file looks completely odd to me... if you want org.eclipse.core.filesystem.linux.aarch64 why the heck do you add nebula as an (empty) location all this in slicer mode and referencing a sub-repository reference instead of using plain https://download.eclipse.org/releases/2025-09/ ?

[merks]

@merks

Unfortunately the nebula repository has some rather nasty references to other repositories

Do you mean the Nebula or the NatTable repository?

Sorry, NatTable.

And why they are nasty? I mean you and @laeubi suggested to build the NatTable update site in this way to avoid that the NatTable dependencies are included.

I have major concerns about that recommended approach, but I don't wish to rehash them, because it's "just an opinion". I think @HannesWell added support that one can use this approach to filter but without actually added the reference to the repository.

In this case we have a reference to 4.32 which is really old. I expect anyone installing or creating a target platform will have the appropriate repository for the platform that they actually want (as we see in this simple example) so this reference is kind of "worse than useless".

Then there are references to two "moving target" repositories which contain god knows what depending on when you look at them and may not contain what's actually needed at some time in the future, which seems bad.

So to me all this looks like a problem waiting to happen and/or helpfulness that hurts. But that's my personal opinion and opinions can differ.

I really don't have the cycles to track down why all the bad repository references cause problems.

I really don't understand what you mean with "bad repository references". Why they are bad? How should that be changed? What would be a "good repository reference"?

Generally I don't think there is a good repository reference. You should pin down and include in your repository exactly any 3rd party bundles needed to install and you should avoid including in repository any content from other projects and avoid referencing such things. Again, it's my opinion.

In any case, what I mean here is that I do not have time to figure out why all the repositories reachable by composition and reference (good or bad) from this starting point result in PDE wanting to mirror an artifact that doesn't exist. I'm doubtful that anyone will spend the time to figure out why that is.

[merks]

I don't understand the issue here and it is maybe more due to

The target file looks completely odd to me... if you want org.eclipse.core.filesystem.linux.aarch64 why the heck do you add nebula as an (empty) location all this in slicer mode and referencing a sub-repository reference instead of using plain https://download.eclipse.org/releases/2025-09/ ?

I imagine this is a small minimal sample that reproduces a problem; a problem that should not happen and doesn't happen if one doesn't follow reference.

[laeubi]

I imagine this is a small minimal sample that reproduces a problem; a problem that should not happen and doesn't happen if one doesn't follow reference.

Before we blame any well working features or spliting hairs about good or bad references (PDE ignores any failing references just in case) the whole "problematic target" loads perfectly fine for me:

[merks]

Maybe a Windows thing, maybe a hash order thing, maybe depends on what's in your cache(s):

So many theories. In any case, that source bundle IU is not actually physically in that in that repository:

Anyway, I've done what I can and my opinions are probably best kept to myself...

[laeubi]

Maybe a Windows thing, maybe a hash order thing, maybe depends on what's in your cache(s)

Sure but from PDE side it is impossible to analyze with a proper test-case. The target is not anywhere referencing the source UI and if any repository claim it is contained but can not be downloaded there is not much we can do.

Again its also hard to be analyzed on such "synthetic" cases, where it even would work to disable "include sources" (so maybe that "a bad option") or deleting completely empty locations (maybe we should forbidd that? Who knows?)....

[merks]

Oh well, there is a workaround and that's all I have time to offer.

[haubi]

I imagine this is a small minimal sample that reproduces a problem; a problem that should not happen and doesn't happen if one doesn't follow reference.

Exactly that!

Before we blame any well working features or spliting hairs about good or bad references (PDE ignores any failing references just in case) the whole "problematic target" loads perfectly fine for me:

Ah, well: It needs to be in a fresh workspace, wherein that o.e.c.filesystem.linux.aarch64.source bundle has not been resolved as part of some .target definition yet.

[merks]

Ah, well: It needs to be in a fresh workspace, wherein that o.e.c.filesystem.linux.aarch64.source bundle has not been resolved as part of some .target definition yet.

FYI, the underlying frameworks are quite clever ad discovering all kinds of artifact repositories on disk and using those when possible...

[haubi]

Your target works when I add followRepositoryReferences="false":

Hmm, how can I declare that property within Target Platform DSL .tpd file?

My current workaround is to add /releases/2025-03/202503121000 as another location, to actually allow for resolving that source bundle.

[laeubi]

Your workspace is not "fresh"... it looks at these locations:

file:///workspace/haubi/eclipse/committers-staging/eclipse/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/
file:/home/haubi/.p2/org.eclipse.equinox.p2.core/cache/
file:/home/haubi/.p2/pool/.eclipseextension
file:/workspace/haubi/eclipse/committers-staging/eclipse/configuration/org.eclipse.osgi/226/data/listener_1925729951/
file:///home/haubi/.p2/pool/
file:/workspace/haubi/eclipse/committers-staging/eclipse/.metadata/.plugins/org.eclipse.pde.core/.p2/org.eclipse.equinox.p2.core/cache/
https://download.eclipse.org/releases/2025-09/202509101001/
https://download.eclipse.org/nattable/releases/2.6.0/repository/

so actually we need maybe a "fresh installed computer" whats a bit to much to ask.

So my first guess would be, can we reproduce it with Tycho and a fresh m2 repository (what is usually easier to setup). Then maybe the problem just goes away soon when there is a new Eclipse release and Nebula include more up-to-date references (no idea why there are such old ones mixed with latest).

Furthermore one might want to improve PDE to not fail on failed source downloads...

[fipro78]

no idea why there are such old ones mixed with latest

Well the Nebula latest is used because there were some important fixes in the rich text editor that are required to use it in older and current Eclipse versions. The old Eclipse version is referenced, because otherwise NatTable can't be used in older Eclipse versions anymore, as there are some breaking changes, especially with regards to the DPI and the multi-monitor stuff.

But I agree, the next NatTable version will again try to use a stable Nebula release update site and a current Eclipse platform one. Thanks for the pointers!

[laeubi]

The old Eclipse version is referenced, because otherwise NatTable can't be used in older Eclipse versions anymore

I don't think there is a direct relation between the eclipse version used in the build and the one a component can run off...