chore(databricks): remove the Python converter

[Haoranli503]

Summary

Removes the deprecated Python implementation of the Databricks converter. The Java converter under converters/databricks/java becomes the only implementation: it has been the maintained one since #333 and covers the Python converter's behavior (#496 ported the #428 cascade drop guards, #500 added the import tests the Java suite lacked). The apache-ossie-databricks package was never published to PyPI.

Changes:

• Delete converters/databricks/python (21 files), its python CI job, and its Dependabot entry. The java CI job and the Maven Dependabot entry stay.
• Drop the references the removal leaves dangling: the python/ row and link in converters/databricks/README.md, the Python converter link and note in converters/databricks/java/README.md, and Java comments that cited the Python converter or its tests. No Java code changes.

Not changed: the Cube interop matrix (converters/cube/tools/interop_matrix.py) still lists the databricks spoke as uv run ossie-databricks, which has reported SKIP since #333 moved the Python project under python/. Pointing it at the Java converter is left to a separate change.

Testing: the Java suite passes locally (89 tests). A few export edge case tests existed only in the Python suite and are not ported here.

Related Issues

Checklist

Specification

• Spec changes are included in core-spec/ and follow the existing structure
• Spec changes have been discussed on the mailing list or in a linked issue
• Breaking changes to the spec are clearly called out in the summary

Ontology

• Ontology changes in ontology/ are consistent with spec changes
• New or modified terms are defined and documented

Converters

• Converter logic in converters/ is updated to reflect spec or ontology changes
• New converters include tests under the converter's test directory
• If adding a new converter, .github/labeler.yml is updated with the new path

Validation

• Validation rules in validation/ are updated if the spec changed
• New validation cases are covered by tests

Documentation

• docs/ is updated to reflect any user-facing changes
• New features or behaviors are documented with examples where appropriate
• CONTRIBUTING.md is updated if the contribution process changed

Examples

• examples/ are added or updated for any new spec constructs or converter support

Tests

• All existing tests pass (pytest / CI green)
• New functionality is covered by tests

Compliance

• ASF license headers are present on all new source files
• No third-party dependencies are added without PMC/IPMC approval
• If third-party source code is vendored/copied (not just declared as a dependency), NOTICE and/or LICENSE have been updated per ASF policy

[jbonofre]

@Haoranli503 it makes perfect sense for me. It could be confusing for users (which one they should use) especially when the two converters are not at the same level.

If the Databricks guys are fine with that, I'm fine to merge.

[christianeu-db]

@Haoranli503 it makes perfect sense for me. It could be confusing for users (which one they should use) especially when the two converters are not at the same level.

If the Databricks guys are fine with that, I'm fine to merge.

Yes - consolidating around the Java impl LGTM. Thanks @Haoranli503 for the change - @jbonofre this looks good to merge

[jbonofre]

Thanks for confirming. Let's clean this up 😉