Many modules doesn't mean you have a modular system

[bertfrees]

But it should! We are in the situation that we have a lot of modules (bundles) that are all coupled to each other. You don't actually have the choice to include a module or not. A further problem of having many modules is that it can become unclear what the functionality of each modules is. The fact is that often the only reason two components are in separate modules is to avoid circular dependencies (one component depends on another via a third component from another module).

Some things we can do to improve the situation:

• The reason why modules like liblouis-saxon and liblouis-calabash modules exist is to make the system not tied to specific XSLT/XPath/XProc engines. I still think this is a good idea. What's not so nice about this is that these modules are coupled with other modules using 'Require-Bundle'. They could be coupled more loosely using 'Require-/Provide-Capability'. (Also I think Require-Bundle doesn't allow circular dependencies while Require-Capability does.)
• Modules like liblouis-utils and liblouis-core may be merged if we can solve the problem of circular dependencies. Making use of 'Require-/Provide-Capability' (see above) may help with that. 'Declarative Services' is another means.
  • Modules such as liblouis-native and liblouis-tables already make 100% use of DS. Other modules such as liblouis-formatter and liblouis-mathml not yet but they could.
• Possibly merge foo-saxon and foo-calabash with foo-utils to simplify things, because we're not using multiple XSLT/XProc engines anyway. The modules can be split again at any time later.
• Make dependencies optional using resolution:=optional and throw runtime exceptions when needed.

Related issues:

• Clean up API #48
• Use Require-Capability and Provide-Capability instead of Require-Bundle daisy/pipeline-tasks#29
• Make it easier to run XProc and XSLT components in other environments (outside of Pipeline) daisy/pipeline-tasks#28