Consider generating nextCatalog entries based on Maven dependencies

[josteinaj]

The nextCatalog entries in the XML catalogs are only used when the modules are deployed into the framework (or is it only for building the OSGi "Require-Bundle" declarations?). We want to maintain a valid dependency graph both in Maven (in the pom) and OSGi (through the catalog nextCatalog declarations). However, we don't have a way to test that the dependency graph is valid at the moment, and we have to maintain the dependencies in both the catalog and the pom (although we don't really do it in the pom atm I think?).

By generating the nextCatalog entries based on the maven dependencies, we only have to maintain the graph in one place.

The maven dependencies can also potentially be used for integration testing (daisy/xproc-maven-plugin#7) which would work as a way to make sure that all necessary dependencies are declared.

[rdeltour]

Thanks for creating the issue Jostein. Putting that dependency to the POM vs. Catalog vs. OSGi manifest was indeed an "open" question at the time we refactored the whole build system.

or is it only for building the OSGi "Require-Bundle" declarations?

yes, it is.

we have to maintain the dependencies in both the catalog and the pom (although we don't really do it in the pom atm I think?)

correct, POM dependencies are only used for Java dependencies.

One issue with declaring the dependencies in the POM is that there is no straightforward way to know wether the dependency is an "XML module", i.e. if it needs to be converted as a Required-Bundle directive. That's why we used the nextCatalog element an convert it with XSLT.

We could provide an explicit OSGi header via the configuration of the Maven Bundle Plugin, but the idea was that a module developer s/b able to create a simple module with a very minimalist POM, and just manually edit the catalog, with minimum knowledge of Maven.

I'd be happy to improve the situation, so any idea or experiment is welcome!

[josteinaj]

I'd be happy to improve the situation, so any idea or experiment is welcome!

Cool, I'll assign it to me for now, just so the issue is assigned, and in case I get time to experiment.

[josteinaj]

One issue with declaring the dependencies in the POM is that there is no straightforward way to know wether the dependency is an "XML module", i.e. if it needs to be converted as a Required-Bundle directive. That's why we used the nextCatalog element an convert it with XSLT.

We could provide an explicit OSGi header via the configuration of the Maven Bundle Plugin, but the idea was that a module developer s/b able to create a simple module with a very minimalist POM, and just manually edit the catalog, with minimum knowledge of Maven.

If we know that a module is a pure-XML module, and if we assume that the bundle symbolic names are on the form ${groupId}.${artifactId}, then it's pretty straight forward to generate the OSGi dependencies directly from the POM.

Modules with non-module-dependencies will always need to declare a custom service component (I think); which means that they have to configure the maven-bundle-plugin in the POM along with an explicit Import-Package anyway.

...which leaves modules that depend on modules with OSGi symbolic names other than ${groupId}.${artifactId}. For our modules, this should be rare and discouraged. If you really need to depend on such modules, we could require developers to configure the maven-bundle-plugin manually.

In most cases, at least for "simple XML modules", I think we can generate the Import-Package declaration directly from the list of POM /*/dependencies.

wdyt?

[rdeltour]

If we know that a module is a pure-XML module, and if we assume that the bundle symbolic names are on the form ${groupId}.${artifactId}, then it's pretty straight forward to generate the OSGi dependencies directly from the POM.

Right, but the primary issue is to know whether a POM dependency is a Pipeline module or not. It would be doable by inspecting the jar to look for META-INF/catalog.xml, but I suppose it wouldn't be super straightforward to do that in a POM.

Modules with non-module-dependencies will always need to declare a custom service component (I think)

yeah, unless we start to use Java annotations to declare that class provides a DS component :)

which means that they have to configure the maven-bundle-plugin in the POM along with an explicit Import-Package anyway.

no, see for instance the POM of the file-utils module. The POM explicitly declares the component, but the Require-Bundle directive is still automatically generated (IIRC the generated OSGi manifest is used a base manifest by the Maven Bundle Plugin).

[josteinaj]

mmhm, I see.

</experiment-over-for-now>

[bertfrees]

While I don't think this idea is impossible to implement, a better approach is to generate the Require-Bundle headers not from the pom.xml but from the source files (.xpl, .xsl) (see daisy/pipeline-tasks#41). Does everybody agree?

Note that ideally we shouldn't use Require-Bundle at all (daisy/pipeline-tasks#29, daisy/pipeline-tasks#33).