Start of adding XSuite tests to Maven for XQSuite

[adamretter]

DO NOT MERGE YET.

I made a start on having the XQSuite tests execute via XSuite with Maven.

There is a problem where XSuite is run outside of eXist-db, and an XQuery module imports another module, the resolution of the module fails. Unfortunately there is not a quick solution to this. XSuite assumes that all dependencies are available in eXist-db, but eXist-db does not know where to find the dependencies.

There are a number of options I can think of here:

1. When we start eXist-db from Maven for testing, we could autodeploy a copy of the built XAR. Actually we also need to deploy other Xars on which our Xar depends too, e.g. shared-resources, templating, etc...
2. For testing, we use the Maven resources plugin to rewrite the "at" declarations in our XQuery modules to point to the real location of the modules on the filesystem.
3. When we start eXist-db for testing, we tell it to use a custom URI Resolver for module lookups, which is Maven project aware.

Either way, it will take some time to write some Java code and test it.

My preference would likely be (1). This could be done either by:

1. Adding options to conf.xml which specify Xars which should be autodeployed at startup if they are not already available.
2. Developing an eXist-db plugin for Maven.

[adamretter]

There is also a bug in eXist-db's SourceFactory.java which compounds this problem. Fixing that might be enough for simple XQSuite tests to run via XSuite.

[duncdrum]

phew i know that @dizzzz has already done work in that area, so he might have some ideas.

Looking at the mavenization of the docs in general i have a two feature wishes though.

• XQSuite tests should be executable during development from inside a running instance. Users shouldn't have to rebuild and reinstall the whole project every time they add a single %test:arg. This means that tests need to be accessible from /modules/ inside the deployed .xar
• XQSuite test should run with the equivalent of both :latest and :release to get a heads-up with respect to upcoming changes.

This leads me to think that we could,

• We could have a maven aware XQSuite test-runner at src/test/xquery/${project.name}/other-runner.xql which handles the imports differently and gets filtered and copied into modules, i.e. 3.
• We could try using something along docker maven plugin lines to use docker images from inside maven (this would also make integration testing easier) , i.e. alternative to 1.

We could also adopt a similar approach to what I did with yeoman. If my local mocha can access the apps inside a running exist instance it executes the XQSuite tests, if it gets a 200 the XQSuite tests are skipped (but not failed). So mvn test will try to talk to a local exist and if it isn't there skip the XQSuite tests. This plays well with CI and local development workflows. Since we already have mocha we could just reuse the code for this from the generator.

The copy a conf.xml approach seems inelegant, expath-pkg.xml should suffice for xapth dependencies, what happens if i put duncans-new.xar in there, but don't declare it in the former? What happens between different version of exist with modified conf.xml?

an exist-db plugin seems more suited, and future-proof overall.

[duncdrum]

see #333
see eXist-db/exist#2657

[duncdrum]

point of caution exist-testkit is not available since 4.7.0

[line-o]

Is this PR being worked on in the future or should we rather close it?

[adamretter]

@line-o Yes, it just requires a newer version of eXist-db first, and then some refactoring of the tests.