Hi all,
While reviewing third-party dependencies included in the IoTDB binary
distribution, I noticed that the CLI package brings in the following
dependencies transitively through iotdb-jdbc:
- org.osgi:osgi.core
- org.osgi:osgi.cmpn
- org.ops4j.pax.jdbc:pax-jdbc-common
These dependencies are used by the OSGi integration in the JDBC module, mainly
through:
- org.apache.iotdb.jdbc.Activator
- org.apache.iotdb.jdbc.IoTDBDataSourceFactory
- the OSGi Declarative Services annotation on IoTDBDriver
- the Karaf feature descriptor under
iotdb-client/jdbc/src/main/feature/feature.xml
The regular CLI does not use the OSGi service. It loads IoTDBDriver through
Class.forName() and obtains connections through DriverManager.
As a local check, I removed the three OSGi/Pax jars from the all-in-one
distribution and verified that the CLI could still load the JDBC driver, print
its help output, and enter the normal connection path without class-loading
errors.
During the investigation, I also found some signs that the OSGi/Karaf support
may no longer be actively maintained:
1. The Karaf feature descriptor refers to artifacts such as:
mvn:org.apache.iotdb/tsfile/${project.version}
mvn:org.apache.iotdb/hadoop-tsfile/${project.version}
These coordinates do not appear to match the current module and dependency
structure. In particular, TsFile now uses the org.apache.tsfile group ID.
2. The feature descriptor uses pax-jdbc-common 1.4.5, while the current Maven
dependency is 1.5.6. Some other dependency versions in the descriptor also
appear outdated.
3. I could not find tests that start an OSGi framework, install the JDBC bundle
or Karaf feature, and verify that the JDBC DataSourceFactory service is
registered and usable.
Therefore, the source code and OSGi metadata are still present, but it is
unclear whether the feature works in a current OSGi/Karaf environment or
whether there are still users relying on it.
I would like to discuss which direction we should take:
1. Continue maintaining OSGi support
Update the Karaf feature descriptor, verify all bundle dependencies and
package imports, and add an integration test that installs and starts the JDBC
bundle and checks the registered JDBC services.
2. Keep it, but separate it from the regular distribution
Preserve OSGi support in the JDBC artifact, but exclude the OSGi/Pax runtime
jars from the CLI and all-in-one distributions. OSGi users would obtain the
required dependencies through their OSGi/Karaf environment.
3. Deprecate and eventually remove it
Mark the OSGi-specific API and packaging as deprecated, ask users to provide
feedback during a deprecation period, and remove the Activator,
DataSourceFactory integration, Karaf feature descriptor, and related
dependencies in a later release.
My initial preference is option 2 as an immediate, low-risk cleanup: the CLI
does not need these dependencies, while the published JDBC artifact can retain
its existing OSGi metadata.
In parallel, if no active users or maintainers can be identified, we could
consider deprecating the OSGi integration before removing it in a future
release.
Does anyone know of current deployments using the IoTDB JDBC driver through
OSGi, Apache Karaf, or Pax JDBC? Is anyone interested in maintaining and
testing this integration?
Any feedback or historical context would be appreciated.
Best regards,
Haonan Hou
