Dependency Updates

[eclipse-releng-bot]

The content of the target eclipse-sdk-prereqs.target was updated

Please review the changes and merge if appropriate, or cherry pick individual updates.

The location https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/milestone/S202604020800 was updated:

• Location changed to https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/milestone/S202604101740
• Unit org.apache.ant was updated from 1.10.16.v20260402-1000 to 1.10.17.v20260410-1000

[merks]

@bodewig

FYI, I'll merge this with the verification is done we'll give it a full test spin overnight.

[merks]

@bodewig

FYI, the build completed with no ant-related failures:

https://download.eclipse.org/eclipse/downloads/drops4/I20260410-1800/reports.html#tests

Thanks again.

[bodewig]

@merks this is good news.

I wonder whether we could get some kind of early warning system like building (a subset of) Eclpse against a release candidate build of Ant. I guess we can do so in Ant land if we understand how to set up a complete build environment for Eclipse. Just thinking loud right now.

[merks]

Ant is kind of horrible. Well, not ant itself 😛 but how Eclipse consumes it.

Some gory details here:

https://github.com/eclipse-orbit/orbit-simrel/blob/main/maven-ant/org.eclipse.orbit.ant.generator/README.md

The executive summary is that Orbit repackages the full zipped ant download to produce a single bundle with nested ant libraries. It then uses BND to create a proper OSGi bundle from that. What a nightmare! But at least the processing is automated...

It does mean that testing something before following all the steps would be a significant manual effort carried locally in a development environment and is something that is not readily fully automated without really significant further investment. ☹️

[HannesWell]

FYI, the build completed with no ant-related failures:

https://download.eclipse.org/eclipse/downloads/drops4/I20260410-1800/reports.html#tests

Awesome.

Just started the Windows Java-25 test configuration to very that too:
https://ci.eclipse.org/releng/job/AutomatedTests/job/ep440I-unit-win32-x86_64-java25/11/

[bodewig]

Ant is kind of horrible. Well, not ant itself 😛 but how Eclipse consumes it.

Some gory details here:

https://github.com/eclipse-orbit/orbit-simrel/blob/main/maven-ant/org.eclipse.orbit.ant.generator/README.md

The executive summary is that Orbit repackages the full zipped ant download to produce a single bundle with nested ant libraries. It then uses BND to create a proper OSGi bundle from that. What a nightmare! But at least the processing is automated...

It does mean that testing something before following all the steps would be a significant manual effort carried locally in a development environment and is something that is not readily fully automated without really significant further investment. ☹️

Errm, yes, this looks more complex than it should and more complex than I'm prepared to set up (at least right now). Thank you for the hint. If we could do things in Ant land to make things easier (it doesn't look as if just providing OSGi Manifest lines in our jars was enough - we almost certainly have Java packages shared between different jars) then I'm sure we'd be open to suggestions (maybe not inside of the comments of a closed PR :-).