IEP-1673 Update the eclipse platform to the 2025-12 version #1380
Conversation
📝 WalkthroughWalkthroughUpdated target/platform repositories and installable units, bumped Java runtime to JavaSE‑21 in launch and classpath, pruned and reorganized many bundle MANIFEST Require‑Bundle/Import‑Package entries (adding select commons/JNA exports), enabled Tycho Surefire for JUnit 5, and made small .classpath and import tweaks. (50 words) Changes
Sequence Diagram(s)(none) Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
bundles/com.espressif.idf.branding/Espressif-IDE.launch (1)
45-62: Do not removeorg.eclipse.cdt.debug.gdbjtagfeature — it is actively used for debugging functionality.The codebase critically depends on the
org.eclipse.cdt.debug.gdbjtagfeature:
GDBStubDebuggerLauncher.javausesorg.eclipse.cdt.debug.gdbjtag.launchConfigurationTypeand numerousorg.eclipse.cdt.debug.gdbjtag.core.*properties to configure GDB/JTAG debuggingConfiguration.javaimportsorg.eclipse.cdt.debug.gdbjtag.core.IGDBJtagConstants- The DSF GDB launcher delegate (
org.eclipse.cdt.debug.gdbjtag.core.dsfLaunchDelegate) is explicitly referencedRemoving this feature will break all debugging functionality in the IDE. This feature must remain in the
selected_featureslist.
🤖 Fix all issues with AI agents
In @bundles/com.espressif.idf.branding/Espressif-IDE.launch:
- Line 39: The launch config sets JRE_CONTAINER to JavaSE-21 but VM_ARGUMENTS
still include a duplicated -Dosgi.requiredJavaVersion=11; update the
VM_ARGUMENTS entry to a single -Dosgi.requiredJavaVersion=21 (remove the
duplicate) so it matches JRE_CONTAINER, and then reconcile module manifests that
declare JavaSE-17: either update those manifest JavaSE/required execution
environment entries to JavaSE-21 (the branding bundle and any workspace bundles
declaring JavaSE-17) or revert JRE_CONTAINER to JavaSE-17 to match the lowest
declared runtime; ensure JRE_CONTAINER, VM_ARGUMENTS, and all manifest JavaSE
declarations use the same Java version and that -Dosgi.requiredJavaVersion
appears only once.
- Line 42: The VM arguments string (stringAttribute
key="org.eclipse.jdt.launching.VM_ARGUMENTS") still declares
-Dosgi.requiredJavaVersion=11 twice; update those occurrences to
-Dosgi.requiredJavaVersion=21 (matching JavaSE-21) and remove duplicate entries
if present so the value contains a single -Dosgi.requiredJavaVersion=21 token;
ensure you update the VM_ARGUMENTS attribute value used by the launch
configuration.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
bundles/com.espressif.idf.branding/Espressif-IDE.launchreleng/com.espressif.idf.target/com.espressif.idf.target.target
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build_linux
- GitHub Check: build_macos
- GitHub Check: build_windows
🔇 Additional comments (6)
bundles/com.espressif.idf.branding/Espressif-IDE.launch (2)
13-13: No hardcoded references found—configuration location change is safe.The configLocation path change from "Espressif IDE" to "Espressif-IDE" is isolated to the .launch file. Search results confirm there are no other hardcoded references to the old configuration path elsewhere in the codebase that could break.
35-36: Both attributes are valid Eclipse launch configuration attributes supported in Eclipse 4.38 / 2025-12:
org.eclipse.debug.core.ATTR_FORCE_SYSTEM_CONSOLE_ENCODINGis defined in the DebugPlugin API (since Eclipse 3.20) and controls system console encoding behavior.org.eclipse.jdt.launching.ATTR_ATTR_USE_ARGFILEis defined in IJavaLaunchConfigurationConstants (the double "ATTR_" is the correct constant name per JDT source) and controls argument file usage for Java launches.No compatibility issues detected.
releng/com.espressif.idf.target/com.espressif.idf.target.target (4)
6-6: Eclipse 4.38 is a stable, GA-released version.The update to Eclipse 4.38 (released December 1, 2025) is appropriate for production use.
46-46: Confirm Orbit 2025-12 is available; verify javax.xml.jre removal doesn't break XML parsing.Orbit 2025-12 (release 4.38.0) is confirmed stable and available as of January 2026. However, the codebase actively uses
javax.xmlclasses in:
bundles/com.espressif.idf.terminal.connector.serial/src/com/espressif/idf/terminal/connector/serial/launcher/GDBStubDebuggerLauncher.javabundles/com.espressif.idf.terminal.connector.serial/src/com/espressif/idf/terminal/connector/serial/launcher/CoreDumpPostmortemDebuggerLauncher.javaBoth files import
javax.xml.parsers.*andjavax.xml.transform.*classes. These are available in Java 9+ via the standardjava.xmlmodule, but you must verify that the affected bundle manifests properly declare imports forjavax.xml.parsersandjavax.xml.transformpackages without relying on the removedjavax.xml.jrebundle.
25-25: Migration from tm.terminal to org.eclipse.terminal is complete. Verified that no code in the codebase imports or depends on the legacyorg.eclipse.tm.terminal.*packages. The neworg.eclipse.terminal.feature.feature.groupis properly configured in the target definition.
20-20: Eclipse 2025-12 release is available and official as of January 2026, confirming the repository update tohttps://download.eclipse.org/releases/2025-12/is valid.
| <booleanAttribute key="org.eclipse.jdt.launching.ATTR_SHOW_CODEDETAILS_IN_EXCEPTION_MESSAGES" value="true"/> | ||
| <booleanAttribute key="org.eclipse.jdt.launching.ATTR_USE_START_ON_FIRST_THREAD" value="true"/> | ||
| <stringAttribute key="org.eclipse.jdt.launching.JRE_CONTAINER" value="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-11"/> | ||
| <stringAttribute key="org.eclipse.jdt.launching.JRE_CONTAINER" value="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-21"/> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n bundles/com.espressif.idf.branding/Espressif-IDE.launch | sed -n '35,45p'Repository: espressif/idf-eclipse-plugin
Length of output: 1722
🏁 Script executed:
fd -e MF -x gawk '/Bundle-RequiredExecutionEnvironment/ {print FILENAME ": " $0}'Repository: espressif/idf-eclipse-plugin
Length of output: 2139
Critical inconsistency: JRE version mismatch with VM arguments.
Line 39 sets JRE_CONTAINER to JavaSE-21, but line 42 VM_ARGUMENTS still specifies -Dosgi.requiredJavaVersion=11 (note: this argument is duplicated and should appear once). Additionally, the branding bundle's manifest declares JavaSE-17, and most workspace bundles are declared as JavaSE-17, not JavaSE-21. Update:
- VM_ARGUMENTS to require Java 21 and remove the duplicate
-Dosgi.requiredJavaVersionargument - Bundle manifests (branding and others) to match the Java 21 requirement, or revert JRE_CONTAINER to the minimum compatible version across all bundles
🤖 Prompt for AI Agents
In @bundles/com.espressif.idf.branding/Espressif-IDE.launch at line 39, The
launch config sets JRE_CONTAINER to JavaSE-21 but VM_ARGUMENTS still include a
duplicated -Dosgi.requiredJavaVersion=11; update the VM_ARGUMENTS entry to a
single -Dosgi.requiredJavaVersion=21 (remove the duplicate) so it matches
JRE_CONTAINER, and then reconcile module manifests that declare JavaSE-17:
either update those manifest JavaSE/required execution environment entries to
JavaSE-21 (the branding bundle and any workspace bundles declaring JavaSE-17) or
revert JRE_CONTAINER to JavaSE-17 to match the lowest declared runtime; ensure
JRE_CONTAINER, VM_ARGUMENTS, and all manifest JavaSE declarations use the same
Java version and that -Dosgi.requiredJavaVersion appears only once.
| <stringAttribute key="org.eclipse.jdt.launching.JRE_CONTAINER" value="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-21"/> | ||
| <stringAttribute key="org.eclipse.jdt.launching.PROGRAM_ARGUMENTS" value="-os ${target.os} -ws ${target.ws} -arch ${target.arch} -nl ${target.nl} -consoleLog"/> | ||
| <stringAttribute key="org.eclipse.jdt.launching.SOURCE_PATH_PROVIDER" value="org.eclipse.pde.ui.workbenchClasspathProvider"/> | ||
| <stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Dosgi.requiredJavaVersion=11 -Dosgi.instance.area.default=@user.home/eclipse-workspace -XX:+UseG1GC -XX:+UseStringDeduplication --add-modules=ALL-SYSTEM -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Dosgi.requiredJavaVersion=11 -Dosgi.dataAreaRequiresExplicitInit=true -Xms256m -Xmx2048m --add-modules=ALL-SYSTEM -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts"/> |
There was a problem hiding this comment.
Update VM arguments to reflect Java 21 requirement.
The VM arguments still reference -Dosgi.requiredJavaVersion=11 (appearing twice), but Line 39 upgraded to JavaSE-21. This inconsistency could cause validation issues or confusion about the actual Java requirement.
🔧 Proposed fix
- <stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Dosgi.requiredJavaVersion=11 -Dosgi.instance.area.default=@user.home/eclipse-workspace -XX:+UseG1GC -XX:+UseStringDeduplication --add-modules=ALL-SYSTEM -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Dosgi.requiredJavaVersion=11 -Dosgi.dataAreaRequiresExplicitInit=true -Xms256m -Xmx2048m --add-modules=ALL-SYSTEM -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts"/>
+ <stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Dosgi.requiredJavaVersion=21 -Dosgi.instance.area.default=@user.home/eclipse-workspace -XX:+UseG1GC -XX:+UseStringDeduplication --add-modules=ALL-SYSTEM -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Dosgi.dataAreaRequiresExplicitInit=true -Xms256m -Xmx2048m --add-modules=ALL-SYSTEM -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts"/>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Dosgi.requiredJavaVersion=11 -Dosgi.instance.area.default=@user.home/eclipse-workspace -XX:+UseG1GC -XX:+UseStringDeduplication --add-modules=ALL-SYSTEM -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Dosgi.requiredJavaVersion=11 -Dosgi.dataAreaRequiresExplicitInit=true -Xms256m -Xmx2048m --add-modules=ALL-SYSTEM -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts"/> | |
| <stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Dosgi.requiredJavaVersion=21 -Dosgi.instance.area.default=@user.home/eclipse-workspace -XX:+UseG1GC -XX:+UseStringDeduplication --add-modules=ALL-SYSTEM -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts -Dosgi.dataAreaRequiresExplicitInit=true -Xms256m -Xmx2048m --add-modules=ALL-SYSTEM -Xdock:icon=../Resources/Eclipse.icns -XstartOnFirstThread -Dorg.eclipse.swt.internal.carbon.smallFonts"/> |
🤖 Prompt for AI Agents
In @bundles/com.espressif.idf.branding/Espressif-IDE.launch at line 42, The VM
arguments string (stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS")
still declares -Dosgi.requiredJavaVersion=11 twice; update those occurrences to
-Dosgi.requiredJavaVersion=21 (matching JavaSE-21) and remove duplicate entries
if present so the value contains a single -Dosgi.requiredJavaVersion=21 token;
ensure you update the VM_ARGUMENTS attribute value used by the launch
configuration.
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
releng/com.espressif.idf.target/com.espressif.idf.target.target (1)
84-84: Update bundled snakeyaml to match target platform version.The target platform now includes
org.yaml.snakeyamlversion2.2.0from the CDT LSP repository, butcom.espressif.idf.corestill bundlessnakeyaml-1.30.jar. The bundle actively uses snakeyaml inHintsUtil.javaandClangdConfigFileHandler.java, and exports theorg.yaml.snakeyamlpackages, creating a version mismatch.Update the bundled JAR to 2.2.0 to match the target platform, or confirm this dual versioning is intentional. SnakeYAML 1.x to 2.x has breaking API changes and should be verified for compatibility with the existing code.
🤖 Fix all issues with AI agents
In @bundles/com.espressif.idf.help/META-INF/MANIFEST.MF:
- Around line 8-11: The MANIFEST.MF’s Require-Bundle header is missing required
Eclipse help/intro dependencies; update the Require-Bundle entry (alongside
existing org.eclipse.core.runtime) to include org.eclipse.help,
org.eclipse.ui.intro, org.eclipse.ui.intro.universal and org.eclipse.ui so the
help TOC (espidfToc.xml) and intro config (intro/esp_idf.xml) are recognized by
the platform; ensure the bundles are comma-separated in the Require-Bundle
header and keep Bundle-RequiredExecutionEnvironment and other headers unchanged.
In @bundles/com.espressif.idf.swt.custom/META-INF/MANIFEST.MF:
- Around line 12-15: The manifest for the com.espressif.idf.swt.custom bundle
currently lists Require-Bundle without declaring org.eclipse.swt and
org.eclipse.jface; update the Require-Bundle section to explicitly include
org.eclipse.swt and org.eclipse.jface (e.g. add "org.eclipse.swt,
org.eclipse.jface") so the com.espressif.idf.swt.custom bundle that contains
TextWithButton.java and StyledInfoText.java has direct dependencies on SWT and
JFace rather than relying on transitive re-exports from org.eclipse.ui.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MFbundles/com.espressif.idf.debug.gdbjtag.openocd/.classpathbundles/com.espressif.idf.debug.gdbjtag.openocd/META-INF/MANIFEST.MFbundles/com.espressif.idf.debug.gdbjtag.openocd/src/com/espressif/idf/debug/gdbjtag/openocd/dsf/console/IdfProcessConsole.javabundles/com.espressif.idf.help/META-INF/MANIFEST.MFbundles/com.espressif.idf.launch.serial.core/META-INF/MANIFEST.MFbundles/com.espressif.idf.launch.serial.ui/META-INF/MANIFEST.MFbundles/com.espressif.idf.lsp/META-INF/MANIFEST.MFbundles/com.espressif.idf.sdk.config.core/META-INF/MANIFEST.MFbundles/com.espressif.idf.sdk.config.ui/META-INF/MANIFEST.MFbundles/com.espressif.idf.serial.monitor/META-INF/MANIFEST.MFbundles/com.espressif.idf.swt.custom/META-INF/MANIFEST.MFbundles/com.espressif.idf.terminal.connector.serial/META-INF/MANIFEST.MFbundles/com.espressif.idf.terminal.connector.serial/src/com/espressif/idf/terminal/connector/serial/launcher/CoreDumpPostmortemDebuggerLauncher.javabundles/com.espressif.idf.terminal.connector/META-INF/MANIFEST.MFbundles/com.espressif.idf.ui/META-INF/MANIFEST.MFreleng/com.espressif.idf.target/com.espressif.idf.target.target
💤 Files with no reviewable changes (5)
- bundles/com.espressif.idf.lsp/META-INF/MANIFEST.MF
- bundles/com.espressif.idf.launch.serial.ui/META-INF/MANIFEST.MF
- bundles/com.espressif.idf.terminal.connector/META-INF/MANIFEST.MF
- bundles/com.espressif.idf.serial.monitor/META-INF/MANIFEST.MF
- bundles/com.espressif.idf.launch.serial.core/META-INF/MANIFEST.MF
✅ Files skipped from review due to trivial changes (1)
- bundles/com.espressif.idf.terminal.connector.serial/src/com/espressif/idf/terminal/connector/serial/launcher/CoreDumpPostmortemDebuggerLauncher.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build_windows
- GitHub Check: build_linux
- GitHub Check: build_macos
🔇 Additional comments (13)
bundles/com.espressif.idf.debug.gdbjtag.openocd/src/com/espressif/idf/debug/gdbjtag/openocd/dsf/console/IdfProcessConsole.java (1)
15-15: LGTM! Import added to support Eclipse platform 2025-12 update.The import enables proper compilation with the updated Eclipse platform. The
IDocumenttype is used implicitly through thegetDocument()method call on line 231, which is part of the URL pattern matching functionality.bundles/com.espressif.idf.sdk.config.core/META-INF/MANIFEST.MF (1)
8-16: Critical: Verify removed bundle dependencies aren't required.The removal of
org.eclipse.equinox.preferences,org.eclipse.cdt.core, andorg.eclipse.debug.corefromRequire-Bundlecould break functionality if this bundle's code still uses:
- CDT APIs for build configuration or project management
- Debug APIs for launch configuration
- Preferences APIs for storing SDK settings
Verify that no source files in
bundles/com.espressif.idf.sdk.config.core/src/import from these removed packages before merging.bundles/com.espressif.idf.debug.gdbjtag.openocd/.classpath (1)
4-9: No dependency resolution issues with current Maven configuration.The classpath is properly configured for a Maven-based Eclipse plugin. The
maven.pomderived="true"attributes on both the JRE_CONTAINER and src entry allow Maven to manage dependencies throughpom.xml(which declares the requiredcom.espressif.idf.coredependency). The absence ofMAVEN2_CLASSPATH_CONTAINERis correct for modern Maven + Eclipse PDE projects and does not cause issues. The addition ofmodule="true"for Java 21 JPMS support is appropriate.Likely an incorrect or invalid review comment.
bundles/com.espressif.idf.sdk.config.ui/META-INF/MANIFEST.MF (1)
8-17: No action required - org.eclipse.text removal is safe.The bundle does not use any classes from
org.eclipse.text. The code importsTextEditorfromorg.eclipse.ui.editors.textandAbstractTextEditorfromorg.eclipse.ui.texteditor, both of which are provided by the already-requiredorg.eclipse.ui.editorsandorg.eclipse.uibundles. Text editing functionality is unaffected.bundles/com.espressif.idf.terminal.connector.serial/META-INF/MANIFEST.MF (2)
8-14: Terminal bundle migration looks correct for Eclipse 2025-12.The migration from
org.eclipse.tm.terminal.*toorg.eclipse.terminal.*bundles aligns with the Eclipse 2025-12 terminal package consolidation. The version ranges[1.0.0,2.0.0)are appropriate for the new terminal bundle structure.Note that
com.espressif.idf.corewas removed from Require-Bundle, but this bundle still has access to it transitively throughcom.espressif.idf.ui, which reexportscom.espressif.idf.core.
26-26: LGTM!Moving
org.eclipse.ui.consolefrom Require-Bundle to Import-Package is a cleaner approach for package-level dependencies.bundles/com.espressif.idf.debug.gdbjtag.openocd/META-INF/MANIFEST.MF (1)
35-38: Dependency restructuring looks appropriate.The Import-Package additions for
org.eclipse.core.expressions,org.eclipse.embedcdt.debug.gdbjtag.ui, andorg.eclipse.jface.textproperly declare the specific package-level dependencies needed by this bundle after removing the broader bundle-level requirements.bundles/com.espressif.idf.ui/META-INF/MANIFEST.MF (2)
36-41: LGTM on Export-Package expansion.The newly exported packages (
com.espressif.idf.ui,com.espressif.idf.ui.dialogs,com.espressif.idf.ui.handlers,com.espressif.idf.ui.preferences,com.espressif.idf.ui.tracing,com.espressif.idf.ui.update) enable other bundles in this PR to depend on these UI components via Import-Package rather than requiring the entire bundle.
47-49: No action required. The removal ofcom.espressif.idf.lsp.preferencesimport is safe—no code in the bundle references this package.releng/com.espressif.idf.target/com.espressif.idf.target.target (3)
6-6: LGTM on Eclipse platform update to 4.38.The repository URL update from 4.37 to 4.38 aligns with the Eclipse 2025-12 release.
20-25: Terminal feature consolidation aligns with manifest changes.The consolidation from multiple
org.eclipse.tm.terminal.*units toorg.eclipse.terminal.feature.feature.groupcorrectly matches the bundle manifest updates that now referenceorg.eclipse.terminal.*packages.
30-37: No action required — JNA is available from the current Orbit repository.
com.sun.jnaandcom.sun.jna.platformare not explicitly listed in the target file's orbit location block, but they are available from the Eclipse Orbit 2025-12 repository (https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2025-12/), which contains JNA 5.18.1. The required version constraint[5.18.0,6.0.0)is satisfied. JNA bundles do not need to be explicitly declared in the target file if they are available from a configured repository.Likely an incorrect or invalid review comment.
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF (1)
61-64: JNA version constraint [5.18.0,6.0.0) is satisfied in Eclipse 2025-12.Verification confirms that JNA 5.18.1, available in the Eclipse 2025-12 release repository, satisfies the specified version range. The constraint is correct and the code change is valid.
| Require-Bundle: org.eclipse.core.runtime | ||
| Bundle-RequiredExecutionEnvironment: JavaSE-17 | ||
| Automatic-Module-Name: com.espressif.idf.help | ||
| Bundle-ActivationPolicy: lazy |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for help-related content and code
echo "=== Checking for help TOC and topic files ==="
fd -e xml . bundles/com.espressif.idf.help/ 2>/dev/null | head -20
echo -e "\n=== Searching for 'toc' and 'topic' patterns in XML files ==="
rg -n "toc|topic" bundles/com.espressif.idf.help/ --type xml 2>/dev/null | head -20
echo -e "\n=== Checking plugin.xml for help extensions ==="
if [ -f "bundles/com.espressif.idf.help/plugin.xml" ]; then
cat bundles/com.espressif.idf.help/plugin.xml
else
echo "plugin.xml not found"
fi
echo -e "\n=== Checking for help API imports in source code ==="
fd -e java . bundles/com.espressif.idf.help/src/ 2>/dev/null && rg -n "import org\.eclipse\.help\." bundles/com.espressif.idf.help/src/ 2>/dev/null || echo "No help imports found"
echo -e "\n=== Listing all files in help bundle ==="
fd . bundles/com.espressif.idf.help/ --type f 2>/dev/null | grep -v "\.class$"Repository: espressif/idf-eclipse-plugin
Length of output: 2594
Critical: Missing required dependencies for help system integration.
The bundle defines and uses Eclipse help and intro extensions but is missing the required dependencies. Evidence from plugin.xml:
org.eclipse.help.tocextension point (lines 12-16) registersespidfToc.xml, which contains help table of contents with topics pointing to HTML contentorg.eclipse.ui.intro.configExtensionextension point (lines 5-9) registers intro configuration referencingorg.eclipse.ui.intro.universalConfig
The corresponding content files exist:
espidfToc.xml- help table of contents with topicsintro/esp_idf.xml- intro/welcome page configurationhtml/eclipse_plugin_guide.html,html/esp_idf_guide.html- help content
Restore Require-Bundle entries for org.eclipse.help, org.eclipse.ui.intro, org.eclipse.ui.intro.universal, and org.eclipse.ui. Without these dependencies, the help system will not recognize or display the bundle's help content and intro pages.
🤖 Prompt for AI Agents
In @bundles/com.espressif.idf.help/META-INF/MANIFEST.MF around lines 8 - 11, The
MANIFEST.MF’s Require-Bundle header is missing required Eclipse help/intro
dependencies; update the Require-Bundle entry (alongside existing
org.eclipse.core.runtime) to include org.eclipse.help, org.eclipse.ui.intro,
org.eclipse.ui.intro.universal and org.eclipse.ui so the help TOC
(espidfToc.xml) and intro config (intro/esp_idf.xml) are recognized by the
platform; ensure the bundles are comma-separated in the Require-Bundle header
and keep Bundle-RequiredExecutionEnvironment and other headers unchanged.
| Require-Bundle: org.eclipse.core.variables, | ||
| com.espressif.idf.core, | ||
| org.eclipse.core.runtime, | ||
| org.eclipse.ui |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify SWT and JFace usage in this bundle
# First check if the directory exists and has source files
ls -la bundles/com.espressif.idf.swt.custom/src/ 2>/dev/null || find bundles/com.espressif.idf.swt.custom -type f -name "*.java" | head -20
# Check for SWT widget imports
rg -n "import org\.eclipse\.swt\." bundles/com.espressif.idf.swt.custom/ -C2
# Check for JFace imports
rg -n "import org\.eclipse\.jface\." bundles/com.espressif.idf.swt.custom/ -C2
# Check for registry usage
rg -n "import org\.eclipse\.core\.runtime\.(IExtensionRegistry|IExtension|IConfigurationElement)" bundles/com.espressif.idf.swt.custom/ -C2Repository: espressif/idf-eclipse-plugin
Length of output: 6770
🏁 Script executed:
# Check the current manifest to understand the full dependency structure
cat bundles/com.espressif.idf.swt.custom/META-INF/MANIFEST.MF
# Also verify if org.eclipse.ui actually re-exports SWT and JFace
rg -n "Re-Export-Package" bundles/com.espressif.idf.swt.custom/Repository: espressif/idf-eclipse-plugin
Length of output: 667
Add explicit dependencies on org.eclipse.swt and org.eclipse.jface.
This bundle directly imports and uses SWT and JFace classes (TextWithButton.java and StyledInfoText.java contain multiple imports from org.eclipse.swt.* and org.eclipse.jface.resource.*), but neither bundle is listed in Require-Bundle. Relying on transitive access through org.eclipse.ui is fragile and can break if upstream versions stop re-exporting these bundles. Declare these as direct dependencies in the manifest.
🤖 Prompt for AI Agents
In @bundles/com.espressif.idf.swt.custom/META-INF/MANIFEST.MF around lines 12 -
15, The manifest for the com.espressif.idf.swt.custom bundle currently lists
Require-Bundle without declaring org.eclipse.swt and org.eclipse.jface; update
the Require-Bundle section to explicitly include org.eclipse.swt and
org.eclipse.jface (e.g. add "org.eclipse.swt, org.eclipse.jface") so the
com.espressif.idf.swt.custom bundle that contains TextWithButton.java and
StyledInfoText.java has direct dependencies on SWT and JFace rather than relying
on transitive re-exports from org.eclipse.ui.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @tests/com.espressif.idf.core.test/pom.xml:
- Around line 24-34: The tycho-surefire-plugin configuration in this module sets
providerHint to junit5 but does not override the parent UI test settings,
causing a merge with useUIHarness/useUIThread/application that breaks pure
JUnit5 unit tests; update the tycho-surefire-plugin (artifactId
tycho-surefire-plugin) configuration to explicitly clear UI harness options and
set unit-test-safe values by adding useUIHarness false (and remove/override
useUIThread and application), keep providerHint junit5, and include skipTests
${skipTests} so the child POM fully overrides the parent's UI-specific
configuration.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tests/com.espressif.idf.core.test/pom.xml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build_macos
- GitHub Check: build_linux
- GitHub Check: build_windows
| <build> | ||
| <plugins> | ||
| <plugin> | ||
| <groupId>org.eclipse.tycho</groupId> | ||
| <artifactId>tycho-surefire-plugin</artifactId> | ||
| <configuration> | ||
| <providerHint>junit5</providerHint> | ||
| </configuration> | ||
| </plugin> | ||
| </plugins> | ||
| </build> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the pom.xml file structure and parent POM
fd pom.xml | head -20Repository: espressif/idf-eclipse-plugin
Length of output: 903
🏁 Script executed:
# Check the parent POM reference and plugin version management
cat tests/com.espressif.idf.core.test/pom.xmlRepository: espressif/idf-eclipse-plugin
Length of output: 1182
🏁 Script executed:
# Look for the parent POM file
fd -path "*/tests/com.espressif.idf.tests/*" pom.xmlRepository: espressif/idf-eclipse-plugin
Length of output: 240
🏁 Script executed:
# Find the parent POM file location
find tests -name "pom.xml" | head -10Repository: espressif/idf-eclipse-plugin
Length of output: 167
🏁 Script executed:
# Search for tycho-surefire-plugin version definition across POMs
rg "tycho-surefire-plugin" -A 5 -B 2Repository: espressif/idf-eclipse-plugin
Length of output: 1123
🏁 Script executed:
# Specifically look at parent POM structure
find . -path "*/tests/*" -name "pom.xml" -type fRepository: espressif/idf-eclipse-plugin
Length of output: 173
🏁 Script executed:
# Examine the parent POM file in full
cat tests/pom.xmlRepository: espressif/idf-eclipse-plugin
Length of output: 2477
🏁 Script executed:
# Search for tycho-version property definition
rg "tycho-version" -B 2 -A 2Repository: espressif/idf-eclipse-plugin
Length of output: 4675
Configuration conflict: JUnit 5 unit tests cannot run with parent's UI harness settings.
The plugin version is correctly managed via ${tycho-version} (4.0.12) inherited from the parent POM. However, there is a critical configuration issue: the child module's providerHint set to junit5 will merge with the parent's configuration that includes useUIHarness=true, useUIThread=false, and application=org.eclipse.ui.ide.workbench. These settings are designed for UI tests running in the Eclipse workbench, not for pure unit tests with JUnit 5.
The configuration needs to either override all parent settings explicitly or clear the incompatible UI-specific options. For a unit test module, use:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<configuration>
<providerHint>junit5</providerHint>
<useUIHarness>false</useUIHarness>
<skipTests>${skipTests}</skipTests>
</configuration>
</plugin>🤖 Prompt for AI Agents
In @tests/com.espressif.idf.core.test/pom.xml around lines 24 - 34, The
tycho-surefire-plugin configuration in this module sets providerHint to junit5
but does not override the parent UI test settings, causing a merge with
useUIHarness/useUIThread/application that breaks pure JUnit5 unit tests; update
the tycho-surefire-plugin (artifactId tycho-surefire-plugin) configuration to
explicitly clear UI harness options and set unit-test-safe values by adding
useUIHarness false (and remove/override useUIThread and application), keep
providerHint junit5, and include skipTests ${skipTests} so the child POM fully
overrides the parent's UI-specific configuration.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
tests/com.espressif.idf.core.test/META-INF/MANIFEST.MF (1)
14-14: Add version constraint to org.mockito.mockito-core for consistency.Unlike the JUnit dependencies above (lines 12-13),
org.mockito.mockito-corelacks abundle-versionconstraint. This inconsistency could lead to unpredictable behavior if an incompatible version is resolved at runtime.Additionally, the Bundle-ClassPath (lines 19-21) includes Mockito runtime dependencies (
byte-buddy-1.14.5.jar,byte-buddy-agent-1.14.5.jar,objenesis-3.3.jar). Clarify whether these bundled JARs are intended to work alongside the requiredorg.mockito.mockito-corebundle or if there's a version alignment concern.♻️ Proposed fix to add version constraint
- org.mockito.mockito-core + org.mockito.mockito-core;bundle-version="[5.0.0,6.0.0)"Note: Adjust the version range based on your project's Mockito version requirements.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tests/com.espressif.idf.core.test/META-INF/MANIFEST.MF
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build_windows
- GitHub Check: build_linux
- GitHub Check: build_macos
🔇 Additional comments (1)
tests/com.espressif.idf.core.test/META-INF/MANIFEST.MF (1)
12-13: The explicit version constraint (5.14.1) is appropriate for Eclipse 2025-12. JUnit Jupiter 5.14.1 is the supported release for the 2025-12 stream and includes migration helpers toward JUnit 6, so no changes are needed.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
tests/com.espressif.idf.core.test/META-INF/MANIFEST.MF (1)
16-22: Remove redundant Mockito transitive dependencies from Bundle-ClassPath.The
objenesis-3.3.jar,byte-buddy-1.14.5.jar, andbyte-buddy-agent-1.14.5.jarare transitive dependencies of Mockito and are not directly imported anywhere in the codebase. Withorg.mockito.mockito-corealready in Require-Bundle, these JARs should be provided by the Mockito bundle itself. Including them here creates risk of duplicate classes or version mismatches.Remove these three JARs from Bundle-ClassPath unless they're explicitly needed for a use case outside of Mockito.
🤖 Fix all issues with AI agents
In @tests/com.espressif.idf.core.test/META-INF/MANIFEST.MF:
- Around line 12-15: Add a bundle-version constraint for the Mockito entry in
the MANIFEST by updating the org.mockito.mockito-core token to include
bundle-version="5.20.0" so it matches Eclipse 2025-12; find the line containing
org.mockito.mockito-core in the tests/com.espressif.idf.core.test
META-INF/MANIFEST.MF and append the bundle-version attribute (e.g.,
org.mockito.mockito-core;bundle-version="5.20.0") to ensure deterministic
dependency resolution.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tests/com.espressif.idf.core.test/META-INF/MANIFEST.MF
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build_windows
- GitHub Check: build_linux
- GitHub Check: build_macos
| junit-jupiter-api;bundle-version="5.14.1", | ||
| junit-jupiter-engine;bundle-version="5.14.1", | ||
| junit-jupiter-params;bundle-version="5.14.1", | ||
| org.mockito.mockito-core |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n tests/com.espressif.idf.core.test/META-INF/MANIFEST.MFRepository: espressif/idf-eclipse-plugin
Length of output: 3261
🌐 Web query:
JUnit Jupiter 5.14.1 release date version
💡 Result:
JUnit Jupiter 5.14.1 was released on October 31, 2025. [1][2]
Sources:
[1] JUnit 5.14.1 Release Notes — docs.junit.org.
[2] JUnit 5.14.1 release entry — junit-team/junit5 GitHub.
🌐 Web query:
Mockito 5.0.0 OSGi bundle version constraint Eclipse
💡 Result:
Short answer: the problem is usually a manifest version constraint — some Eclipse plugins/OSGi bundles require org.mockito (or org.mockito.mockito-core) with a bundle-version range excluding 5.0.0. Fix by either (a) updating the Require-Bundle/Bundle-Version range to include Mockito 5.x, (b) import packages (Import-Package with package version ranges) instead of Require-Bundle, or (c) use an Eclipse-wrapped Mockito bundle that matches the required version.
Key points and links:
- Require-Bundle uses bundle-version ranges; a constraint like org.mockito.mockito-core;bundle-version="[4.0.0,5.0.0)" will NOT accept 5.0.0. Change the range (e.g. "[5.0.0,6.0.0)") or remove the bundle-version constraint. [1]
- Prefer Import-Package/version over bundle-version binding (imports bind to package versions; bundle-version is binding to the exporter bundle and is rarely needed). [2]
- Recent Eclipse builds include wrapped Mockito bundles (e.g. org.mockito.mockito-core available in Eclipse distributions), so using the Eclipse-provided wrapped bundle or wrapping mockito-core yourself with bnd/maven-bundle-plugin can resolve manifest mismatches. Example: Eclipse repo lists org.mockito.mockito-core:5.10.0. [3][4]
If you want, tell me the exact Manifest Require-Bundle/Import-Package lines or the error text from Eclipse/OSGi and I’ll propose the exact manifest change.
Sources:
[1] Mylyn commit showing Require-Bundle constraint on org.mockito.mockito-core;bundle-version="[4.0.0,5.0.0)".
[2] Explanation of version vs bundle-version in OSGi Import-Package.
[3] Lightrun note about Mockito junit-jupiter missing OSGi entries.
[4] Eclipse bundle list showing org.mockito.mockito-core in Eclipse releases.
🌐 Web query:
Eclipse 2025-12 Mockito version org.mockito.mockito-core bundle
💡 Result:
Eclipse Orbit (2025-12) includes the OSGi bundle org.mockito.mockito-core version 5.20.0. [1][2]
Sources:
- Orbit Aggregation 2025-12 bundle listing (shows org.mockito.mockito-core 5.20.0). [1]
- org.mockito.mockito-core.source 5.20.0 build report on download.eclipse.org. [2]
Specify a bundle-version constraint for org.mockito.mockito-core.
Line 15 lacks a bundle-version attribute for org.mockito.mockito-core, which can lead to unpredictable behavior if incompatible versions are resolved at runtime. Eclipse 2025-12 includes Mockito 5.20.0; add the version constraint to match.
🔧 Suggested fix
junit-jupiter-api;bundle-version="5.14.1",
junit-jupiter-engine;bundle-version="5.14.1",
junit-jupiter-params;bundle-version="5.14.1",
- org.mockito.mockito-core
+ org.mockito.mockito-core;bundle-version="5.20.0"🤖 Prompt for AI Agents
In @tests/com.espressif.idf.core.test/META-INF/MANIFEST.MF around lines 12 - 15,
Add a bundle-version constraint for the Mockito entry in the MANIFEST by
updating the org.mockito.mockito-core token to include bundle-version="5.20.0"
so it matches Eclipse 2025-12; find the line containing org.mockito.mockito-core
in the tests/com.espressif.idf.core.test META-INF/MANIFEST.MF and append the
bundle-version attribute (e.g.,
org.mockito.mockito-core;bundle-version="5.20.0") to ensure deterministic
dependency resolution.
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF (1)
26-26: Clarify the execution environment requirement for this bundle.The AI summary claims "Bumped IDE/runtime to JavaSE-21", but the manifest specifies
JavaSE-17. Across the codebase, only test bundles were updated to JavaSE-21; production bundles includingcom.espressif.idf.coreremain on JavaSE-17. Confirm whether this bundle should stay on JavaSE-17 or be updated to align with the test bundles on JavaSE-21.
🤖 Fix all issues with AI agents
In @bundles/com.espressif.idf.core/META-INF/MANIFEST.MF:
- Around line 45-46: Remove the unused export "org.apache.commons.lang3" from
the Export-Package list in the MANIFEST.MF (it’s not referenced by any code or
dependent bundles); for "org.apache.commons.io" inspect EclipseIniUtil.java
(which uses Commons IO) and the list of dependent bundles—if no other bundle
imports org.apache.commons.io then remove it from the Export-Package as well,
otherwise leave it exported; update the MANIFEST.MF Export-Package entries
accordingly and rerun resolution to ensure no dependent bundle breakage.
In @releng/com.espressif.idf.target/com.espressif.idf.target.target:
- Around line 35-36: Decide whether you intended to force JUnit 5.15 or to use
the latest stable 5.14.2, then update the <unit id="junit-jupiter-api" .../> and
<unit id="junit-jupiter-params" .../> entries to the chosen version (e.g.,
change both to version="5.14.2" if using stable), update the commit message to
match that exact version, and search the repo for any other references to
junit-jupiter-api or junit-jupiter-params to keep versions consistent.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MFreleng/com.espressif.idf.target/com.espressif.idf.target.targettests/com.espressif.idf.core.test/META-INF/MANIFEST.MFtests/com.espressif.idf.core.test/pom.xmltests/com.espressif.idf.ui.test/META-INF/MANIFEST.MF
🚧 Files skipped from review as they are similar to previous changes (2)
- tests/com.espressif.idf.core.test/META-INF/MANIFEST.MF
- tests/com.espressif.idf.ui.test/META-INF/MANIFEST.MF
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build_linux
- GitHub Check: build_windows
🔇 Additional comments (4)
tests/com.espressif.idf.core.test/pom.xml (1)
24-34: TheproviderHintconfiguration is correct; update the commit message for accuracy.The
providerHintvalue ofjunit512is appropriate for JUnit 5.14.1 (confirmed in MANIFEST.MF), as it targets JUnit Platform 5.12+. However, the commit message claiming "junit 5.15" is inaccurate—the actual JUnit version is 5.14.1. Update the commit message to reflect the correct version.Likely an incorrect or invalid review comment.
releng/com.espressif.idf.target/com.espressif.idf.target.target (2)
6-6: The target platform update to Eclipse 2025-12 (4.38) is using the officially released GA build (December 1, 2025). The repository references point to stable, established update sites. No concerns regarding release availability or stability.
25-25: Consolidation properly implemented across all terminal components.The terminal feature consolidation from multiple
org.eclipse.tm.*units toorg.eclipse.terminal.feature.feature.groupis complete. Code migration shows:
- All terminal functionality preserved in consolidated feature (serial, process, launcher delegates)
- Terminal connectors migrated with proper dependency declarations:
org.eclipse.terminal.view.core,org.eclipse.terminal.view.ui,org.eclipse.terminal.controlall pinned to[1.0.0,2.0.0)- API changes handled comprehensively: import paths updated, extension points renamed, launcher interface refactored to use
CompletableFuture, exception handling added with proper loggingbundles/com.espressif.idf.core/META-INF/MANIFEST.MF (1)
63-64: Version range is compatible with Eclipse 2025-12.The specified JNA version range
[5.18.0,6.0.0)is compatible with Eclipse 2025-12, which provides JNA 5.18.1. The patch version update from 5.18.0 to 5.18.1 carries no breaking changes to the JNA API.
| <unit id="junit-jupiter-api" version="5.14.1"/> | ||
| <unit id="junit-jupiter-params" version="5.14.1"/> |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
latest stable version JUnit 5 Jupiter January 2026
💡 Result:
The latest stable JUnit Jupiter (JUnit 5) release as of January 8, 2026 is 5.14.2 (released January 6, 2026). [1]
Sources:
[1] JUnit release notes — 5.14.2 (docs.junit.org).
🏁 Script executed:
# First, let's verify the actual content at the specified lines
cat -n releng/com.espressif.idf.target/com.espressif.idf.target.target | sed -n '30,40p'Repository: espressif/idf-eclipse-plugin
Length of output: 899
🏁 Script executed:
# Check the commit message to verify the claim about "forcing junit 5.15"
git log --oneline -5Repository: espressif/idf-eclipse-plugin
Length of output: 124
🏁 Script executed:
# Let's search for any related commits or changes mentioning junit versions
git log --all --oneline --grep="junit\|JUnit" | head -20Repository: espressif/idf-eclipse-plugin
Length of output: 416
Version mismatch between commit message and target file.
The commit message states "forcing junit 5.15", but the target definition at lines 35-36 specifies JUnit version 5.14.1. Note that the latest stable JUnit 5 version as of January 2026 is 5.14.2. Clarify the intended version, update the target file accordingly, and verify that the commit message reflects the actual implementation.
🤖 Prompt for AI Agents
In @releng/com.espressif.idf.target/com.espressif.idf.target.target around lines
35 - 36, Decide whether you intended to force JUnit 5.15 or to use the latest
stable 5.14.2, then update the <unit id="junit-jupiter-api" .../> and <unit
id="junit-jupiter-params" .../> entries to the chosen version (e.g., change both
to version="5.14.2" if using stable), update the commit message to match that
exact version, and search the repo for any other references to junit-jupiter-api
or junit-jupiter-params to keep versions consistent.
| <unit id="junit-jupiter-api" version="5.14.1"/> | ||
| <unit id="junit-jupiter-params" version="5.14.1"/> | ||
| <unit id="org.commonmark" version="0.0.0"/> <!-- 0.22.0 --> | ||
| <repository location="https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2025-09"/> | ||
| <repository location="https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2025-12"/> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# First, let's understand the repository structure and locate MANIFEST.MF files
echo "=== Finding MANIFEST.MF files ==="
find . -name "MANIFEST.MF" -type f | head -20
echo ""
echo "=== Checking for log4j references in MANIFEST.MF ==="
rg -l "org\.apache\.log4j" --type=text 2>/dev/null || echo "No log4j references found"
echo ""
echo "=== Checking for JNA references in MANIFEST.MF ==="
rg -l "com\.sun\.jna" --type=text 2>/dev/null || echo "No JNA references found"
echo ""
echo "=== Checking for snakeyaml references ==="
rg -l "org\.yaml\.snakeyaml" --type=text 2>/dev/null || echo "No snakeyaml references found"
echo ""
echo "=== Checking for batik references ==="
rg -l "org\.apache\.batik" --type=text 2>/dev/null || echo "No batik references found"Repository: espressif/idf-eclipse-plugin
Length of output: 1555
🏁 Script executed:
#!/bin/bash
echo "=== Content of com.espressif.idf.core MANIFEST.MF (first 50 lines) ==="
cat -n ./bundles/com.espressif.idf.core/META-INF/MANIFEST.MF | head -50
echo ""
echo "=== Checking the target file for removed/added units ==="
cat -n releng/com.espressif.idf.target/com.espressif.idf.target.target | head -60Repository: espressif/idf-eclipse-plugin
Length of output: 6919
🏁 Script executed:
#!/bin/bash
echo "=== Full target file content ==="
cat -n releng/com.espressif.idf.target/com.espressif.idf.target.target
echo ""
echo "=== Searching for snakeyaml in the target file ==="
grep -n "snakeyaml" releng/com.espressif.idf.target/com.espressif.idf.target.target
echo ""
echo "=== Searching for jna in the target file ==="
grep -n "jna" releng/com.espressif.idf.target/com.espressif.idf.target.target
echo ""
echo "=== Checking if cdt-lsp is in the target file ==="
grep -n "cdt-lsp" releng/com.espressif.idf.target/com.espressif.idf.target.targetRepository: espressif/idf-eclipse-plugin
Length of output: 7806
🏁 Script executed:
#!/bin/bash
echo "=== Check git log for this target file ==="
git log --oneline -20 releng/com.espressif.idf.target/com.espressif.idf.target.target 2>/dev/null || echo "Git history not available"
echo ""
echo "=== Search for all 'jna' references in the entire repository ==="
rg -i "jna" --type=text --type=xml 2>/dev/null | head -30
echo ""
echo "=== Check if any .target file has jna ==="
find . -name "*.target" -type f -exec grep -l "jna" {} \;
echo ""
echo "=== Verify com.espressif.idf.core manifest again for exact requirement ==="
grep -n "jna" ./bundles/com.espressif.idf.core/META-INF/MANIFEST.MFRepository: espressif/idf-eclipse-plugin
Length of output: 435
Add JNA platform bundle to target configuration.
The removal of Orbit units created a critical dependency issue. While org.yaml.snakeyaml is now sourced from the cdt-lsp-3.3 repository (version 2.2.0), the com.sun.jna.platform bundle and com.sun.jna package (required by com.espressif.idf.core manifest lines 21 and 63) are no longer defined in the target file and have no alternative source. This will cause build failures during dependency resolution. You must add JNA to an appropriate repository location in the target configuration or re-add the Orbit repository reference.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
releng/com.espressif.idf.target/com.espressif.idf.target.target (1)
1-96: Comprehensive testing required for major platform upgrade.This target platform file update represents a significant upgrade from Eclipse 2025-09 to 2025-12, which includes:
- Eclipse platform version bump (4.37 → 4.38)
- Orbit aggregation update
- Terminal feature consolidation
- JUnit 5 migration
- Various dependency removals (as noted in AI summary)
According to the PR objectives, none of the checklist items have been completed yet:
- ☐ PR Self Reviewed
- ☐ Applied Code formatting
- ☐ Added Documentation
- ☐ Added Unit Test
- ☐ Verified on all platforms - Windows, Linux and macOS
Given the scope of this platform upgrade, please ensure:
- The build completes successfully with the new target platform
- All existing unit tests pass (and are migrated to JUnit 5 if applicable)
- Manual testing on Windows, Linux, and macOS confirms no regressions
- Any removed dependencies (mentioned in AI summary: javax.xml.jre, org.apache.log4j, batik.* units) are truly no longer needed
Run the following to check if any removed dependencies are still referenced in the codebase:
#!/bin/bash # Check for references to removed dependencies echo "=== Checking for javax.xml references ===" rg -nP --type=java 'import\s+javax\.xml\.' | head -20 echo "=== Checking for log4j references ===" rg -nP 'org\.apache\.log4j' | head -20 echo "=== Checking for batik references ===" rg -nP 'org\.apache\.batik' | head -20 echo "=== Checking MANIFEST.MF for removed dependencies ===" fd -e MF -x cat {} \; | rg '(javax\.xml|log4j|batik)'
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
releng/com.espressif.idf.target/com.espressif.idf.target.target
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build_windows
- GitHub Check: build_macos
🔇 Additional comments (7)
releng/com.espressif.idf.target/com.espressif.idf.target.target (7)
37-37: LGTM: com.sun.jna dependency retained.Good that
com.sun.jnahas been retained (or added back per the commit message), as it's essential for Java Native Access functionality that the plugin likely requires.
86-86: LGTM: SnakeYAML dependency properly sourced.The
org.yaml.snakeyamldependency is correctly sourced from the CDT LSP repository with version 2.2.0. This ensures compatibility with the CDT LSP features.
20-20: Eclipse 2025-12 releases repository is accessible.The repository URL https://download.eclipse.org/releases/2025-12/ is available and responds correctly with HTTP 200. The update from 2025-09 to 2025-12 is valid.
6-6: The Eclipse 4.38 update site is available and stable. The GA release was published on December 10, 2025, with the URL https://download.eclipse.org/eclipse/updates/4.38/ correctly mapped to Eclipse 2025-12.
25-25: Consolidation toorg.eclipse.terminal.feature.feature.groupis clean.No references to the old Eclipse TM terminal packages (org.eclipse.tm.*) exist in the codebase, and the consolidated feature at line 25 appears to be the only terminal unit defined in the target platform. The consolidation carries no breaking changes from orphaned references.
39-39: Orbit-aggregation 2025-12 repository is accessible and functional.The repository URL is operational (HTTP 200) and 2025-12 is a valid released version. JUnit 5.14.1 is confirmed available in this release. The update from 2025-09 to 2025-12 is appropriate.
35-36: Review comment should be rewritten—assumptions about version pinning pattern were incomplete.JUnit Jupiter 5.14.1 was released on October 31, 2025, and artifacts are available on Maven Central. The version is legitimate and current for the 2025-12 Orbit aggregation being used.
However, the premise that "most dependencies use version 0.0.0" needs clarification: while items within the same location block (lines 31-34, 37-38) do use 0.0.0, the target file contains multiple pinned versions elsewhere (e.g., embedcdt at 6.4.0.202307251916, snakeyaml at 2.2.0, swtchart at 1.0.0.202412021530). Version pinning is not unusual in this file; it appears to be a deliberate choice for stability when needed.
If the intent is to question the specific use of pinned versions for JUnit dependencies in this location block, that's worth clarifying. Otherwise, no action is needed—the version is valid and the pinning aligns with established patterns in the file.
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF (1)
8-25: Fix missing dependency: org.eclipse.core.resources must be restored to Require-Bundle.Removing
org.eclipse.core.resourcesfrom the manifest will break compilation. The code actively uses classes from this bundle in 61 imports across 29 files, including:IProject,IFile,IMarker,IResource,IContainer,IBuildConfiguration,IWorkspace,IResourceChangeListener,IResourceChangeEvent,IResourceDelta, andResourcesPlugin.Affected files:
CsvTableDataService,SDKConfigUtil,ProjectDescriptionReader,ToolInitializer,FileUtil,ErrorMarkerListener,MarkerCleanupJob,IDFBuildConfiguration,ResourceChangeListener, and 20+ others.Re-add
org.eclipse.core.resourcesto the Require-Bundle list. Verify the other removed dependencies (org.eclipse.core.expressions,com.ibm.icu,org.eclipse.jgit,org.eclipse.cdt.jsoncdb,org.eclipse.core.commands,org.apache.commons.logging) are not similarly used before removing them.
🧹 Nitpick comments (1)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF (1)
45-46: Consider limiting exports from embedded JARs to only necessary third-party packages.The bundle exports
org.apache.commons.ioandorg.apache.commons.lang3from embedded JARs (lines 55-56), which is consistent with how other third-party packages likeorg.json.simpleandorg.yaml.snakeyamlare handled in the same manifest. While this pattern doesn't currently cause split-package conflicts in the codebase (no other bundles provide these packages), exporting third-party libraries is not ideal from an OSGi design perspective and can create coupling issues.Consider reviewing whether all seven exported third-party packages need to be public APIs, or if some could be kept internal-only by removing them from Export-Package.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build_windows
- GitHub Check: build_macos
🔇 Additional comments (2)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF (2)
26-26: Verify Java execution environment version.The AI summary indicates the Java runtime was bumped to JavaSE-21, but this manifest still specifies JavaSE-17. Confirm whether this file should be updated to JavaSE-21 to align with the Eclipse 2025-12 platform update.
63-64: The mixed JNA dependency approach and version constraints are correct and necessary for this codebase.The code directly imports
com.sun.jna.win32.W32APIOptions(inWinNativeFileTagOperations.java), which requires thecom.sun.jna.win32package to be available as a direct dependency. Whilecom.sun.jna.platformis included inRequire-Bundle, it does not re-export the core JNA packages, making theImport-Packagedeclarations necessary. The version constraint[5.18.0,6.0.0)is valid for Eclipse 2025-12's Orbit distribution, which provides JNA 5.18.1. This mixed approach (Require-Bundle for the platform bundle + Import-Package for directly imported packages) follows OSGi best practices and was intentionally added to fix a failing test.
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build_macos
- GitHub Check: build_windows
🔇 Additional comments (1)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF (1)
25-26: LSP4j 0.24.0 and JNA versions are valid for Eclipse 2025-12.Verification confirms:
org.eclipse.lsp4jversion 0.24.0 is used by LSP4e 0.29.0 and is compatible with Eclipse 2025-12com.sun.jnaresolves to version 5.18.1 from Eclipse Orbit 2025-12, which is appropriate for the target platformThe additions are correct and align with the target platform configuration.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @bundles/com.espressif.idf.core/META-INF/MANIFEST.MF:
- Around line 46-47: The MANIFEST.MF currently exports third-party packages
org.apache.commons.io and org.apache.commons.lang3 via Export-Package; remove
these package names from Export-Package so the commons libraries remain internal
to the bundle (or stop exporting them), and if shared use is required, create or
depend on a dedicated library bundle that exports those packages instead; update
Export-Package to no longer list "org.apache.commons.io" and
"org.apache.commons.lang3" and ensure any consumers either include their own
copy or declare a dependency on the shared commons bundle.
- Line 64: The MANIFEST.MF contains an unused Import-Package declaration
"Import-Package: org.apache.commons.logging"; remove that entry from the
MANIFEST.MF if no code imports org.apache.commons.logging, or if it must remain,
add a brief comment in the commit message explaining why the dependency is
required (e.g., runtime-supplied logging adapter or optional integration), and
ensure any classes that rely on org.apache.commons.logging (search for imports
or references to org.apache.commons.logging.Log / LogFactory) are documented in
the manifest or module metadata accordingly.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build_windows
- GitHub Check: build_linux
- GitHub Check: build_macos
🔇 Additional comments (2)
bundles/com.espressif.idf.core/META-INF/MANIFEST.MF (2)
27-27: [Your rewritten review comment text here]
[Exactly ONE classification tag]
25-26: No issues found. The manifest correctly specifies lsp4j version 0.24.0, which is the standard version included in Eclipse 2025-12. Additionally, bothcom.sun.jnaandcom.sun.jna.platformmust be explicitly listed in Require-Bundle (they are not redundant);com.sun.jna.platformhas an explicit OSGi dependency on the corecom.sun.jnabundle and requires both to be resolved.
| org.apache.commons.io, | ||
| org.apache.commons.lang3, |
There was a problem hiding this comment.
Exporting third-party libraries can cause OSGi class loading conflicts.
Exporting org.apache.commons.io and org.apache.commons.lang3 from this bundle is problematic:
- Version conflicts: Other bundles may depend on different versions of these libraries, leading to
ClassCastExceptionorNoSuchMethodErrorat runtime. - OSGi best practice: Third-party libraries should either remain internal to the bundle or be packaged in dedicated library bundles that other plugins can depend on.
Recommendation: Remove these packages from Export-Package and keep them internal. If other bundles need these libraries, they should include their own copies or depend on a shared library bundle.
📦 Verify if other bundles depend on these exports
#!/bin/bash
# Search for bundles that might be importing these packages
rg -n --type manifest "Import-Package.*org\.apache\.commons\.(io|lang3)"
rg -n "org\.apache\.commons\.(io|lang3)" --glob "*.java" -C 2🤖 Prompt for AI Agents
In @bundles/com.espressif.idf.core/META-INF/MANIFEST.MF around lines 46 - 47,
The MANIFEST.MF currently exports third-party packages org.apache.commons.io and
org.apache.commons.lang3 via Export-Package; remove these package names from
Export-Package so the commons libraries remain internal to the bundle (or stop
exporting them), and if shared use is required, create or depend on a dedicated
library bundle that exports those packages instead; update Export-Package to no
longer list "org.apache.commons.io" and "org.apache.commons.lang3" and ensure
any consumers either include their own copy or declare a dependency on the
shared commons bundle.
| lib/commons-compress-1.21.jar, | ||
| lib/xz-1.9.jar | ||
| Import-Package: org.eclipse.cdt.debug.core.launch, | ||
| Import-Package: org.apache.commons.logging, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for usage of org.apache.commons.logging in the codebase
rg "import org\.apache\.commons\.logging" --type java -C 2Repository: espressif/idf-eclipse-plugin
Length of output: 54
🌐 Web query:
Eclipse 2025-12 org.apache.commons.logging bundle availability target platform
💡 Result:
Short answer: Yes — the 2025-12 Eclipse release provides Commons Logging as OSGi bundles in the target platform: org.apache.commons.commons-logging 1.3.5 and org.apache.commons.logging 1.2.0 (both present in the 2025-12 repository). [1][2]
Sources:
- org.apache.commons.commons-logging 1.3.5 in Eclipse 2025-12 repository. [1]
- org.apache.commons.logging 1.2.0 in Eclipse 2025-12 repository. [2]
Remove unused Import-Package declaration or clarify dependency reason.
The package org.apache.commons.logging is available in Eclipse 2025-12, but it does not appear to be imported anywhere in the codebase. Either remove this declaration if it is not needed, or clarify in the commit message why this dependency is required.
🤖 Prompt for AI Agents
In @bundles/com.espressif.idf.core/META-INF/MANIFEST.MF at line 64, The
MANIFEST.MF contains an unused Import-Package declaration "Import-Package:
org.apache.commons.logging"; remove that entry from the MANIFEST.MF if no code
imports org.apache.commons.logging, or if it must remain, add a brief comment in
the commit message explaining why the dependency is required (e.g.,
runtime-supplied logging adapter or optional integration), and ensure any
classes that rely on org.apache.commons.logging (search for imports or
references to org.apache.commons.logging.Log / LogFactory) are documented in the
manifest or module metadata accordingly.
|
@sigmaaa hi ! Tested under: Clangd is not there. |
|
Tested under: The Serial Monitor gets stuck when starting. No error message is shown. However, when it tries to open the Serial Monitor after flashing, it just hangs and never opens: flash command: |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
releng/com.espressif.idf.target/com.espressif.idf.target.target (1)
84-88: Update CDT LSP to version 3.4.0 for Eclipse 2025-12 compatibility.The target file currently references
cdt-lsp-3.3.0(line 86), which was paired with Eclipse 2025-09. Eclipse 2025-12 ships with CDT LSP 3.4.0. Update the repository location and unit version to match the 2025-12 release. Also ensure clangd 17.x is installed on target systems, as the CDT LSP 3.x series is developed and tested against clangd 17.x.
🤖 Fix all issues with AI agents
In @releng/com.espressif.idf.target/com.espressif.idf.target.target:
- Around line 35-37: The pom unit listing includes an outdated, unmaintained
Log4j 1.x entry ("unit id=\"org.apache.log4j\"") which has known
vulnerabilities; replace this dependency with a maintained logging library
(e.g., Log4j 2, SLF4J + Logback) or remove it if unused, and update any code
that references org.apache.log4j classes to the new API (or add a compatibility
bridge) so builds and runtime logging still work; if you must keep
org.apache.log4j for compatibility, explicitly document the justification and
ensure SocketServer or other vulnerable features are disabled/unreachable from
untrusted networks and add a comment near the "org.apache.log4j" unit explaining
the mitigation and risk acceptance.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
releng/com.espressif.idf.target/com.espressif.idf.target.target
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: build_windows
- GitHub Check: build_linux
🔇 Additional comments (3)
releng/com.espressif.idf.target/com.espressif.idf.target.target (3)
6-6: LGTM: Platform repository URLs updated consistently.The Eclipse updates repository (4.38) and releases repository (2025-12) are correctly aligned for the Eclipse 2025-12 platform update.
Also applies to: 20-20
40-40: LGTM: Orbit repository URL updated.The orbit-aggregation repository is correctly updated to 2025-12, consistent with the platform update.
25-25: Terminal feature migration is correct and complete; Serial Monitor hanging is likely unrelated.The consolidation from
org.eclipse.tm.*units toorg.eclipse.terminal.feature.feature.grouphas been properly completed. All Java code dependencies have been migrated, and the terminal connector bundles correctly require the neworg.eclipse.terminal.*components (org.eclipse.terminal.view.core,org.eclipse.terminal.view.ui,org.eclipse.terminal.control).The Serial Monitor hanging issue reported by AndriiFilippov is unrelated to this feature change. The Serial Monitor core (
com.espressif.idf.serial.monitor) does not directly depend on Eclipse terminal APIs—it uses pty4j for terminal emulation. The reported hangs are likely caused by platform-specific serial port communication issues or pty4j compatibility, not the terminal feature consolidation.
| <unit id="junit-jupiter-api" version="5.14.1"/> | ||
| <unit id="junit-jupiter-params" version="5.14.1"/> | ||
| <unit id="org.apache.log4j" version="0.0.0"/> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check Maven Central for JUnit Jupiter versions
curl -s "https://search.maven.org/solrsearch/select?q=g:org.junit.jupiter+AND+a:junit-jupiter-api&rows=20&wt=json" 2>/dev/null | jq '.response.docs[] | {id, latestVersion}' | head -50Repository: espressif/idf-eclipse-plugin
Length of output: 153
🏁 Script executed:
# Check if version 5.14.1 specifically exists
curl -s "https://search.maven.org/solrsearch/select?q=g:org.junit.jupiter+AND+a:junit-jupiter-api+AND+v:5.14.1&rows=5&wt=json" 2>/dev/null | jq '.response'Repository: espressif/idf-eclipse-plugin
Length of output: 119
🌐 Web query:
JUnit Jupiter 5.14.1 release version availability
💡 Result:
Yes — JUnit Jupiter 5.14.1 was released on October 31, 2025 and its artifacts are available on Maven Central. [1][2]
Sources:
- JUnit release notes (5.14.1 release date). [1]
- Maven Central listing for org.junit.jupiter:junit-jupiter-api:5.14.1. [2]
🌐 Web query:
Log4j 1.x CVE security vulnerabilities current status
💡 Result:
Summary — current status (as of Jan 13, 2026)
- Apache Log4j 1.x is end-of-life (EOL) — no upstream maintenance or new fixes. [1]
- The primary high‑risk CVE for Log4j 1.2.x is CVE‑2019‑17571 (SocketServer deserialization). It affects 1.2 up through 1.2.17 when the SocketServer/listener for serialized log events is used. Apache will not fix 1.x upstream. [1][4]
- Log4j 1.x is NOT the source of the 2021 “Log4Shell” RCE (CVE‑2021‑44228) — that impacted Log4j 2.x. However, many environments still ship/retain vulnerable 1.x copies, so risk can remain in supply chains and older products. [5][1]
Recommended actions
- Replace Log4j 1.x with a supported logging library (Apache Log4j 2.x patched release or an alternative such as reload4j) wherever possible. [1]
- If you cannot upgrade immediately:
- Ensure the SocketServer/serialized-log listener is not enabled or reachable from untrusted networks (remove/disable org.apache.log4j.net.SocketServer usage). [4][3]
- Apply vendor/distribution backported patches where available (some OS/vendor packages have fixes/backports). Verify with your distro/vendor security advisories. [2][3]
- Inventory: scan builds, containers, firmware and third‑party dependencies for embedded log4j‑1.x copies and remediate. [5]
Selected sources
- Apache Log4j 1.x project page (EOL & security note). [1]
- NVD entry for CVE‑2019‑17571. [4]
- Debian/security tracker and vendor advisories about fixes/backports. [3]
- Coverage of Log4Shell vs Log4j 1.x persistence and remediation advice. [5]
If you want, I can: (a) scan a list of JARs/paths you provide for log4j‑1.x indicators, or (b) fetch vendor-specific advisories/patches for a particular distro or product.
Consider replacing Log4j 1.x with a maintained logging library.
The org.apache.log4j (Log4j 1.x) dependency is end-of-life with no upstream maintenance. It has known vulnerabilities including CVE-2019-17571 (SocketServer deserialization). If this is required for compatibility, ensure the SocketServer listener is not enabled or reachable from untrusted networks, and consider documenting the justification.
🤖 Prompt for AI Agents
In @releng/com.espressif.idf.target/com.espressif.idf.target.target around lines
35 - 37, The pom unit listing includes an outdated, unmaintained Log4j 1.x entry
("unit id=\"org.apache.log4j\"") which has known vulnerabilities; replace this
dependency with a maintained logging library (e.g., Log4j 2, SLF4J + Logback) or
remove it if unused, and update any code that references org.apache.log4j
classes to the new API (or add a compatibility bridge) so builds and runtime
logging still work; if you must keep org.apache.log4j for compatibility,
explicitly document the justification and ensure SocketServer or other
vulnerable features are disabled/unreachable from untrusted networks and add a
comment near the "org.apache.log4j" unit explaining the mitigation and risk
acceptance.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
bundles/com.espressif.idf.terminal.connector.serial/META-INF/MANIFEST.MF (1)
15-15: UpdateBundle-RequiredExecutionEnvironmenttoJavaSE-21.Eclipse 2025-12 requires Java 21 as the minimum version. The manifest currently specifies
JavaSE-17, which is inconsistent with the platform upgrade and the JavaSE-21 updates already applied to launch and classpath configurations elsewhere in this bundle. Align this entry toJavaSE-21.
🤖 Fix all issues with AI agents
In @bundles/com.espressif.idf.terminal.connector.serial/META-INF/MANIFEST.MF:
- Around line 8-14: The MANIFEST.MF is missing the org.eclipse.ui.plugin package
required by your Activator which extends org.eclipse.ui.plugin.AbstractUIPlugin;
update the manifest to either add org.eclipse.ui.plugin to the Import-Package
list or re-add the org.eclipse.ui bundle to Require-Bundle so the
AbstractUIPlugin class is available at runtime (ensure the entry references
org.eclipse.ui.plugin or org.eclipse.ui with an appropriate version constraint
to match your runtime).
🧹 Nitpick comments (1)
bundles/com.espressif.idf.terminal.connector.serial/META-INF/MANIFEST.MF (1)
26-27: Add version constraints to Import-Package entries for consistency with Eclipse 2025-12 requirements.Import-Package declarations for
org.eclipse.ui.consoleandorg.slf4jlack version constraints. While the project doesn't consistently enforce versioning on Import-Package entries, adding explicit version ranges improves compatibility with Eclipse 2025-12 and helps prevent resolution issues.♻️ Suggested fix with version constraints
-Import-Package: org.eclipse.ui.console, - org.slf4j +Import-Package: org.eclipse.ui.console;version="[3.8.0,4.0.0)", + org.slf4j;version="[1.7.0,3.0.0)"
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
bundles/com.espressif.idf.terminal.connector.serial/META-INF/MANIFEST.MF
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: build_linux
- GitHub Check: build_macos
- GitHub Check: build_windows
| Require-Bundle: org.eclipse.core.runtime;bundle-version="3.8.0", | ||
| org.eclipse.cdt.native.serial;bundle-version="1.0.0", | ||
| org.eclipse.debug.core, | ||
| com.espressif.idf.core, | ||
| com.espressif.idf.ui, | ||
| com.espressif.idf.serial.monitor, | ||
| org.eclipse.cdt.core.native, | ||
| org.eclipse.ui.console, | ||
| org.eclipse.terminal.view.core;bundle-version="[1.0.0,2.0.0)", | ||
| org.eclipse.terminal.view.ui;bundle-version="[1.0.0,2.0.0)", | ||
| org.eclipse.terminal.control;bundle-version="[1.0.0,2.0.0)" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
echo "=== Examining MANIFEST.MF structure ==="
cat bundles/com.espressif.idf.terminal.connector.serial/META-INF/MANIFEST.MF
echo ""
echo "=== Searching for usages of removed bundle packages ==="
fd -e java . bundles/com.espressif.idf.terminal.connector.serial 2>/dev/null | head -20
echo ""
echo "=== Checking imports of org.eclipse.ui, org.eclipse.core.expressions, org.eclipse.equinox.security ==="
rg -l "import org\.eclipse\.(ui\.|core\.expressions|equinox\.security)" bundles/com.espressif.idf.terminal.connector.serial 2>/dev/null || echo "No matches found"
echo ""
echo "=== All imports in source files ==="
fd -e java . bundles/com.espressif.idf.terminal.connector.serial --exec grep -h "^import org\.eclipse\." {} \; 2>/dev/null | sort -uRepository: espressif/idf-eclipse-plugin
Length of output: 6343
🏁 Script executed:
#!/bin/bash
echo "=== Checking Activator.java imports ==="
cat bundles/com.espressif.idf.terminal.connector.serial/src/com/espressif/idf/terminal/connector/serial/activator/Activator.java | head -30
echo ""
echo "=== Checking CoreDumpPostmortemDebuggerLauncher imports ==="
head -30 bundles/com.espressif.idf.terminal.connector.serial/src/com/espressif/idf/terminal/connector/serial/launcher/CoreDumpPostmortemDebuggerLauncher.java | grep -A 5 -B 5 "import org.eclipse.ui"Repository: espressif/idf-eclipse-plugin
Length of output: 1374
🏁 Script executed:
#!/bin/bash
echo "=== Verify org.eclipse.ui.plugin is missing from MANIFEST ==="
if grep -q "org.eclipse.ui.plugin" bundles/com.espressif.idf.terminal.connector.serial/META-INF/MANIFEST.MF; then
echo "Found in MANIFEST.MF"
else
echo "NOT found in MANIFEST.MF"
fi
echo ""
echo "=== Show CoreDumpPostmortemDebuggerLauncher.java imports ==="
sed -n '1,40p' bundles/com.espressif.idf.terminal.connector.serial/src/com/espressif/idf/terminal/connector/serial/launcher/CoreDumpPostmortemDebuggerLauncher.java
echo ""
echo "=== Summary: packages imported from org.eclipse.ui ==="
rg "import org\.eclipse\.ui\." bundles/com.espressif.idf.terminal.connector.serial/src --no-headingRepository: espressif/idf-eclipse-plugin
Length of output: 2167
Add missing org.eclipse.ui.plugin to Import-Package in MANIFEST.MF.
The bundle's Activator class extends org.eclipse.ui.plugin.AbstractUIPlugin but this package is not declared in the manifest. While org.eclipse.ui.console is in Import-Package, the org.eclipse.ui.plugin package is missing entirely. This will cause a ClassNotFoundException when the bundle attempts to activate, which directly explains the Serial Monitor hang on macOS arm64 and Windows 11—the bundle fails to initialize.
Add org.eclipse.ui.plugin to the Import-Package section, or restore the org.eclipse.ui bundle requirement in Require-Bundle if other classes depend on it.
🤖 Prompt for AI Agents
In @bundles/com.espressif.idf.terminal.connector.serial/META-INF/MANIFEST.MF
around lines 8 - 14, The MANIFEST.MF is missing the org.eclipse.ui.plugin
package required by your Activator which extends
org.eclipse.ui.plugin.AbstractUIPlugin; update the manifest to either add
org.eclipse.ui.plugin to the Import-Package list or re-add the org.eclipse.ui
bundle to Require-Bundle so the AbstractUIPlugin class is available at runtime
(ensure the entry references org.eclipse.ui.plugin or org.eclipse.ui with an
appropriate version constraint to match your runtime).
fixed |
This problem happens because of the missing commit from the 4.0 branch. Already handling here: https://github.com/espressif/idf-eclipse-plugin/pulls |
|
@sigmaaa hi ! Tested : able to run Monitor command. |
|
Hi @kolipakakondal , @alirana01 |
kolipakakondal
left a comment
kolipakakondal
left a comment
There was a problem hiding this comment.
Hi @AndriiFilippov LGTM. However, this needs to be tested extensively across different Eclipse versions—both fresh installations and update-site upgrades—since many dependencies have been modified.
Description
updated the eclipse platform to the 2025-12 version
Fixes # (IEP-1673)
Type of change
Please delete options that are not relevant.
How has this been tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Test Configuration:
Dependent components impacted by this PR:
Checklist
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.