maven bundle for org.apache.commons.io has a different symbolic name

[trancexpress]

When trying to use a newer Eclipse SDK integration build with CDT 10.7, plugindependencies detects the following problem:

Error: [org.eclipse.cdt.cmake.is.core 1.0.200.202106071842] plugin not found: org.apache.commons.io 2.6.0

This seems to be due to the Bundle-SymbolicName for the Maven bundle being different:

Orbit:

Automatic-Module-Name: org.apache.commons.io
Bundle-SymbolicName: org.apache.commons.io

Maven:

Automatic-Module-Name: org.apache.commons.io
Bundle-SymbolicName: org.apache.commons.commons-io

I assume this will lead to problems at runtime (we can't build with the error above, so we can't test).

Using the Maven bundle is coming from: eclipse-platform/eclipse.platform.releng.aggregator#426

[trancexpress]

@jonahgraham are CDT maintainers aware of this problem?

How will CDT deal with the newer Eclipse SDKs? Will newer CDT releases (where the problem is fixed) require a newer SDK build to run on?

[iloveeclipse]

git grep "org.apache.commons.io"
debug/org.eclipse.cdt.debug.application.product/debug.product:      <plugin id="org.apache.commons.io"/>
debug/org.eclipse.cdt.debug.dap-feature/feature.xml:      <import plugin="org.apache.commons.io"/>
jsoncdb/org.eclipse.cdt.jsoncdb.core/META-INF/MANIFEST.MF: org.apache.commons.io;bundle-version="2.6.0"
jsoncdb/org.eclipse.cdt.jsoncdb.core/src/org/eclipse/cdt/jsoncdb/core/CompileCommandsJsonParser.java:import org.apache.commons.io.FilenameUtils;
jtag/org.eclipse.cdt.debug.dap.gdbjtag-feature/feature.xml:      <import plugin="org.apache.commons.io"/>
jtag/org.eclipse.cdt.debug.dap.gdbjtag/META-INF/MANIFEST.MF:Require-Bundle: org.apache.commons.io,

[jonahgraham]

My best guess is:

• this a side-effect of https://www.eclipse.org/lists/cross-project-issues-dev/msg19288.html
• we need releng/org.eclipse.cdt.repo/category.xml to be updated to re-publish the third-party dependencies we need. As the ones that were always in platform were not noticed as being absent from CDT's p2 site.
• Alternatives to the above is to change require-bundle to import-package - which seems more suitable for main branch, less so for cdt 10.7 one.

In the meantime, the workaround is to add https://download.eclipse.org/tools/orbit/downloads/drops/R20220531185310/repository to the list of available repos and "Contact all update sites during install to find required software".

The simrel seems to be fine because commons.io is pulled in from tracecompass and the commons-io one does not actually exist in the simrel site.

[iloveeclipse]

@jonahgraham : we aren't interested in workaround because we can build in our (closed) environment.

We are interested in a permanent solution that allows us consume CDT for offline build, without extra repositories added.

The main question is if CDT is supposed to be backwards compatible with older SDK releases? If not, one could simply replace old bundle name with new one I guess.

[jonahgraham]

The main question is if CDT is supposed to be backwards compatible with older SDK releases? If not, one could simply replace old bundle name with new one I guess.

We don't provide compatibility with older releases. The catch is that CDT 10.7 was released for 2022-06 and we weren't planning on a new release for 2022-09.

The fix on main branch is to just do the update (either require-bundle name change or change to import-package).

Do we need to do anything for 2022-09 release cycle?

[iloveeclipse]

Do we need to do anything for 2022-09 release cycle?

Well, update bundle references, see above. Because depending on how end users update or install CDT, they may face issues with missing dependencies.

[jonahgraham]

We can't change require-bundle in CDT 10.7 branch. We can add commons.io to the CDT p2 repo by adding it to category.xml.

[iloveeclipse]

We can't change require-bundle in CDT 10.7 branch.

Why?

We can add commons.io to the CDT p2 repo by adding it to category.xml.

Will that mean, the new bundle will be also found if updating from CDT update site without extra update sites, and the bundle will land in the zipped p2 update site? If so, sounds OK.

[jonahgraham]

We can't change require-bundle in CDT 10.7 branch.

Why?

I am being perhaps too pessimistic, but changing the dependencies of bundles in a service release seems like a bad idea.

We can add commons.io to the CDT p2 repo by adding it to category.xml.

Will that mean, the new bundle will be also found if updating from CDT update site without extra update sites, and the bundle will land in the zipped p2 update site? If so, sounds OK.

Yes - commons.io will be in the p2 site (zipped and plain) for CDT 10.7.1. All of CDT's 3rd party dependencies are supposed to be in there already, but commons.io is actually a relatively new dep of CDT (in the 20 year lifespan of CDT) and was missed.

Note that the CDT 10.7.0 repo will not be modified.

[jonahgraham]

I will be doing a 10.7.1 release that contains this in the coming days (for 2022-09 M3).

[trancexpress]

@jonahgraham , when I try to use the 10.7.1 release I still see the error for this plug-in:

https://download.eclipse.org/tools/cdt/releases/10.7/cdt-10.7.1/plugins/org.eclipse.cdt.jsoncdb.core_1.3.0.202206081803.jar

Error: [org.eclipse.cdt.jsoncdb.core 1.3.0.202206081803] plugin not found: org.apache.commons.io 2.6.0

In the MANIFEST.MF I see:

org.apache.commons.io;bundle-version="2.6.0"

I see the release contains org.apache.commons.io_2.8.0.v20210415-0900.jar... Does this work with the version constraint above?

[trancexpress]

@jonahgraham , when I try to use the 10.7.1 release I still see the error for this plug-in:

Actually never mind, I forgot to update an RPM. Seems to work when I use the new release, sorry for the noise.