Create my own patches for JDT

[fedejeanne]

Tip

This question might be related to (or even be the exact same as?) @gayanper's #1146.

Hello all,
I am trying to patch JDT on my own so that I can deliver some (cherry-picked) commits or even open PRs to our development team a bit sooner than the upcoming release. For example, I would like to patch the JDT version that came out with Eclipse 4.37 and add the commits introduced by #4526.

I assume this should be fairly similar to the P-BUILDS that JDT uses to deliver patches to test the upcoming Java versions so I tried to do what's described in this README and started playing around with the build.sh, but so far I had no luck, I can't generate a patch.

My setup

• Windows 11
• Using WSL (Windows Subsystem for Linux)

What I've tried (in WSL)

• Checked out the BETA_JAVA25 branch and switched to the corresponding directory

git clone https://github.com/eclipse-jdt/eclipse.jdt.git -b BETA_JAVA25
cd eclipse.jdt/org.eclipse.jdt.releng/patchbuild

• Adapted the build.sh in that directory so that I can use it locally :
  • No signing the JARs (step 5)
  • No uploading any P2-site to the JDT servers (Step 10)
  • Exit the scripts as soon as any command fails (I added set -euo pipefail at the beginning)
• Ran the script like this (I took the parameters from this CI run (#59)):

Y_BUILD=https://download.eclipse.org/eclipse/updates/4.37-Y-builds/Y20250916-1440 \
SDKTIMESTAMP=20250905-0730 \
JDT_VERSION_MAX=3.20.349 \
SDKVERSION=4.37 \
DROPS_DIR=R-4.37-202509050730 \
bash ./build.sh

This is the output:

output (build failed)

Nov 21, 2025 9:11:19 AM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider org.slf4j.simple.SimpleServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle slf4j.simple
Buildfile: /home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/eclipse/plugins/org.eclipse.pde.build_3.12.800.v20250515-0456/scripts/build.xml

main:

preBuild:

preSetup:

checkLocalMaps:

getMapFiles:
      [cvs] cvs checkout: CVSROOT must be an absolute pathname (not `${mapsRepo}')
      [cvs] cvs checkout: when using local access method.
      [cvs] cvs [checkout aborted]: Bad CVSROOT: `${mapsRepo}'.

postSetup:

checkLocalBase:

getBaseComponents:

processRepos:

fetch:

preFetch:

allElements:

allElementsDelegator:

init:

fetchElement:
    [mkdir] Created dir: /home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/work/features
    [mkdir] Created dir: /home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/work/plugins

main:
     [copy] Copying 1 file to /home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/work/tempFeature
     [copy] Copying 1 file to /home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/work/tempFeature
[eclipse.fetch] The entry [email protected],3.43.50.qualifier has not been found. The entry [email protected] has been used instead.
[eclipse.fetch] The entry [email protected],3.43.50.qualifier has not been found. The entry [email protected] has been used instead.
[eclipse.fetch] The entry [email protected],3.35.150.qualifier has not been found. The entry [email protected] has been used instead.
[eclipse.fetch] The entry [email protected],1.23.150.qualifier has not been found. The entry [email protected] has been used instead.
[eclipse.fetch] The entry [email protected],3.23.450.qualifier has not been found. The entry [email protected] has been used instead.
[eclipse.fetch] The entry [email protected],3.24.50.qualifier has not been found. The entry [email protected] has been used instead.

fetch:

fetch.element:
     [copy] Copying 4 files to /home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/work/features/org.eclipse.jdt.javanextpatch

fetch.plugins:

FetchIUsFromRepo:
     [echo] Fetching IUs from https://download.eclipse.org/eclipse/updates/4.37-Y-builds/Y20250916-1440 to .

fetch.recursively:

postFetch:

generate:

preGenerate:

allElements:

allElementsDelegator:

init:

generateScript:
[eclipse.buildScript] Some inter-plug-in dependencies have not been satisfied.
[eclipse.buildScript] Bundle org.eclipse.jdt.launching:
[eclipse.buildScript]   Another singleton version selected: org.eclipse.jdt.launching_3.23.500.v20250902-1545
[eclipse.buildScript] Bundle org.eclipse.jdt.ui:
[eclipse.buildScript]   Another singleton version selected: org.eclipse.jdt.ui_3.35.200.v20250904-1303
[eclipse.buildScript] Bundle org.eclipse.jdt.core.manipulation:
[eclipse.buildScript]   Another singleton version selected: org.eclipse.jdt.core.manipulation_1.23.200.v20250905-2123
[eclipse.buildScript] Bundle org.eclipse.jdt.core:
[eclipse.buildScript]   Another singleton version selected: org.eclipse.jdt.core_3.43.50.v20250916-1548
[eclipse.buildScript] Bundle org.eclipse.jdt.debug:
[eclipse.buildScript]   Another singleton version selected: org.eclipse.jdt.debug_3.24.50.v20250805-1927

BUILD FAILED
/home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/eclipse/plugins/org.eclipse.pde.build_3.12.800.v20250515-0456/scripts/build.xml:38: The following error occurred while executing this line:
/home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/eclipse/plugins/org.eclipse.pde.build_3.12.800.v20250515-0456/scripts/build.xml:94: The following error occurred while executing this line:
/home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/eclipse/plugins/org.eclipse.pde.build_3.12.800.v20250515-0456/templates/headless-build/customTargets.xml:13: The following error occurred while executing this line:
/home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/eclipse/plugins/org.eclipse.pde.build_3.12.800.v20250515-0456/templates/headless-build/allElements.xml:17: The following error occurred while executing this line:
/home/myuser/eclipse.jdt/org.eclipse.jdt.releng/patchbuild/eclipse/plugins/org.eclipse.pde.build_3.12.800.v20250515-0456/scripts/genericTargets.xml:112: Processing inclusion from feature org.eclipse.jdt.javanextpatch: Bundle org.eclipse.jdt.ui_3.35.150.v20250916-1550 failed to resolve.:
        Another singleton version selected: org.eclipse.jdt.ui_3.35.200.v20250904-1303

Questions

1. Am I going for the right approach here (using P-BUILDs) or should I try something else?
2. Any hints on how to use the build.sh correctly so that I can create my own P2-site with the patches I want?

Thank you in advance!

cc @stephan-herrmann

[trancexpress]

What we do to patch various bits for downporting, from the aggeragator repo: https://github.com/eclipse-platform/eclipse.platform.releng.aggregator

mvn -e clean install -pl :eclipse-sdk-prereqs,:org.eclipse.jdt.core.compiler.batch -Dmaven.repo.local=/tmp/.m2/repository -DlocalEcjVersion=99.99
mvn -e clean verify -Pbree-libs -DaggregatorBuild=true -DskipTests=true -Dmaven.repo.local=/tmp/.m2/repository -Dcbi-ecj-version=99.99

In the result there should be an update site at: eclipse.platform.releng.tychoeclipsebuilder/eclipse.platform.repository/target/repository/

This of course builds the whole SDK. But assuming your aggeragor repository is "frozen" and only the JDT code submodule changes, it should be enough.

For using just the JDT repository, no idea.

[fedejeanne]

Thank you for the tip! So what you do is:

• Checkout the desired code branch/tag
• Patch it (either cherry-pick or write changes manually)
• Run those 2 mvn calls
• Point your current IDE to that update site and Help > Check for Updates

Is that correct?

[trancexpress]

Point your current IDE to that update site and Help > Check for Updates

I'm not sure about that part, this is something @iloveeclipse does (who is unfortunately very busy these days).

Up until then, yes. IIRC -DlocalEcjVersion=99.99 is what we use to force the aggregator build to consume our ecj build.

If you try this, let me know if it doesn't work. We have a lot of code in our build scripts, maybe I'm forgetting some important part.

Since JDT is more than just ecj: I was testing the JUnit 6 changes like this, the built SDK had the JDT UI changes. I did have to bump bundle versions in JDT (locally).

[fedejeanne]

Thank you for your answer @trancexpress . I haven't had time to make it work yet but in the past week I learned that what I am trying to do is the same thing that SAP wants to achieve (see #4648 (reply in thread)), so I'm going to try and apply the same technique and report back here.

[stephan-herrmann]

Am I going for the right approach here (using P-BUILDs) or should I try something else?

The script for P-Builds was developed for the following context:

• A full SDK build including the desired changes exists (called "Y builds").
• It is desired to install the changes as a selective replacement of few plugins.
  • The patch feature side-steps the linear version history of the main stream (still individual plugins need a strategy to avoid a conflict of versions, we use an increment of .50).

If this matches your use case, a patch feature might a suitable approach. I'm available to check what input / modifications for the build script might be needed.

If, OTOH, the intention is to create a regular maintenance build, then a regular build might be more appropriate.

Another question would be how much you need to actually build. If only JDT should be updated, then you problably don't need a full SDK build. The JDT feature plus a tiny extra repository project (to create the p2 update site) should suffice. Tycho experts will guide you if you select this path :)

[fedejeanne]

Hm, then I should most likely change strategies because what I am trying to do is to build a maintenance version i.e. port back fixes in the current version to previous versions.

Luckily this is something that the people from SAP (cc @sratz) also need to do and we discussed it in the last face-to-face meeting of the Eclipse IDE Working Group so I'm going to try and follow that same path.

Thank you anyway for chiming in, @stephan-herrmann !