Support integration tests

[josteinaj]

The idea would be that all the dependencies (i.e. other modules) would be fetched and unzipped. All the module dependencies in the XML catalogs should be resolved to their path on the filesystem (according to their Maven coordinates?). For instance:

<nextCatalog catalog="org:daisy:pipeline:modules:common-utils"/>

...would become something like...

<nextCatalog catalog="file:/tmp/it/repo/org/daisy/pipeline/modules/common-utils/META-INF/catalog.xml"/>

wdyt?

[rdeltour]

this would only work with "pure XML" modules though, right ? I'm not sure it's worth the cost.

Also, it would be very specific to our use of URNs with the nextCatalog element, which is kind of a hack. So maybe better left to another, dedicated plugin ?

Not trying to sound too negative. The idea is interesting!

[josteinaj]

pure XML modules

Depends on how the "daisy pipeline"-mode of xproc-maven-plugin works; I don't know. But most of our modules are pure XML, or has pure XML fallbacks. And even Java-modules often have some XProc or XSLT wrappers which should have predictable behaviour when run in a pure-XML context.

our use of URNs

Right. Then how about this instead; each module has a "master XML catalog". This could default to "META-INF/catalog.xml" but possibly be configurable. Based on the Maven dependencies, a new XML catalog could be generated which references all of the modules XML catalogs. This XML catalog would be used as the "main XML catalog" passed to the XML processor (i.e. Calabash). Or simply pass all the XML catalogs directly to the XML processor if you can pass more than one - I don't know if it's possible to have more than one "main" catalog...

[josteinaj]

As a side question; could we generate those custom catalog URNs of ours based on the Maven dependencies?

(i.e. as part of the build process)

[rdeltour]

As a side question; could we generate those custom catalog URNs of ours based on the Maven dependencies?

Yeah, it could be considered. Right now module dependencies doesn’t even need to appear as Maven dependencies, e.g. when there’s no Java API dependency. But it kinda “breaks” the Maven graph, so it’s not ideal. And our naive dependency declaration in the catalog doesn’t declare the required version range.

[bertfrees]

Wait a minute! I don't think I like were this is going. Aren't you just trying to solve part of the problem that is already solved by Pax-Exam? This smells a bit of NIH.

[josteinaj]

Oh, right. I forgot about Pax-Exam. Sorry.

[bertfrees]

@josteinaj Tell me if you want to give the Pax-Exam approach a try in nordic-epub3-dtbook-migrator and you need my help.

[josteinaj]

Sure, I'd like that. I can try it out tomorrow. What should I look at to get started? Are you on Skype tomorrow?

[bertfrees]

Shall we close this?

[josteinaj]

Probably. Is the <nextCatalog ...> things still required?

[josteinaj]

I see there's an issue for nextCatalog in daisy/pipeline-build-utils#6 so this issue can be closed.