feat: generate OSGi capabilities from declared nodetypes in cnd and xml import files

[dgriffon]

fixes #616

Description

Browse cnd files to extract nodetypes used and provided
Browse XML files to extract used nodetypes

Store used/provided nodetypes in OSGi require/provided capabilities.

Implementation

We use the library used by our maven jahia plugin: osgi tools to extract nodetypes the same way we do for jahia modules.
Cnd and XML files are parsed.

To use the library, we had to adapt the import packages as the library was not meant to use in an OSGi bundle. Also the library seems to provide too much regarding the current usage, a task will handle the extract of the parsing part to lightened and simplify its usage.

The usage of the library was not possible because of class conflicts resulting into the OSGi annotation (@activate more precisely) that was not working anymore. Using a light version, with no library embed, of the osgi-tool lib or by excluding the dependencies did not fix the issue. It has been chosen to embed the parses' classes into the Javascript module with a high level of depreciation.
#620 will handle the replacement of the parsers by a clean implementation

Note that implementing the changes shows up some inconsistencies in the hydrogen definitions, some namespaces were missing.

Checklist

Tests

• I've provided Unit and/or Integration Tests
• I've updated the parent issue with required manual validations

Tip

Documentation to guide the reviews: How to do a code review

[Copilot]

Pull request overview

This PR implements OSGi capability generation for node types by parsing CND (Content Node Definition) files and XML import files to extract provided and required node types, which are then stored as OSGi capabilities in the bundle manifest.

Changes:

• Integration of the osgi-tools library for parsing CND and XML files to extract node type information
• Refactoring of the bundle generation logic to collect node type capabilities during file processing
• Addition of namespace declarations to sample CND files to ensure proper parsing

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
tests/docker-compose.yml	Removed obsolete version declaration from docker-compose configuration
samples/hydrogen/src/components/Hero/CallToAction/definition.cnd	Added Jahia namespace declaration for proper CND parsing
samples/hydrogen/src/components/BlogPost/definition.cnd	Added mix namespace declaration for proper CND parsing
pom.xml	Added osgi-tools dependency to dependency management
javascript-modules-engine/pom.xml	Configured bundle plugin to embed osgi-tools and made jackrabbit JMX import optional
javascript-modules-engine-java/pom.xml	Added osgi-tools as a direct dependency
javascript-modules-engine-java/src/main/java/org/jahia/modules/javascript/modules/engine/jshandler/JavascriptProtocolConnection.java	Refactored bundle generation to parse CND/XML files and generate OSGi capabilities for node types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jkevan]

Overall, looks very good considering the limitations.
I added a couple of comments, mostly cosmetics.

It would also be great to add a bit more logging in the process, I know that for insight it's always very useful to check jahia logs when a module is starting/installed to see what is happening, I would like to have logs like:

• submitting file: /path/definitions.cnd to parsing for capabilities extraction.
• done processing file for capabilities
• etc..

I saw that the parse method is returning a boolean, it could be used to know when an import xml have been really processed or not.

also it seem's catching of errors and logging of errors when a parsing fail could be improved to help troubleshooting in case of issue.

The thing I am a bit scared of at the moment, but it could probably be part of the next iteration to clean this up, is that in case of issue in cnd/xml the parsing will have direct impact on module deployment compare to a java module where you get feedback when compiling. Runtime impact is way more intrusive and have to be handled properly in the context of module deployement jahia runtime, which is a huge difference and impacts ar clearly not the same.
We will reconsider a JS plugin to do this job later on, for now a working solution is the priority.