Ticket #108 (new task)
Tests that launch Kauri Runtime do not run with "mvn test", only with "mvn install"
| Reported by: | bruno | Owned by: | bruno |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | Build system | Version: | |
| Keywords: | Cc: | lily-developers@… |
Description
Upon an initial Lily build (or when doing rm -rf ~/.m2/repository/org/lilycms), tests that launch Kauri Runtime do not run with "mvn test", only with "mvn install". This is because Kauri will not find the artifacts of the kauri-modules that are part of Lily, since they are not installed yet in the local maven repository.
Once "mvn install" has been run once, things will work, even if the installed jars are from a previous build. This is because Maven puts the classes from the dependent projects itself on the classpath, and we use source-mode for loading the other resources.
Note that usually the only reason to add the Kauri modules as dependencies to the project that contains the Kauri Runtime based tests is to force these modules to be build before the tests.
While the workaround is simply (use "mvn install"), we should fix this. One idea is to let these dependencies resolve to a 'dummy module jar'. After all, the classes are put on the classpath by Maven (or your IDE) so it would be less confusing if there is only one source for them.
Related, we should probably document the pattern for testing Kauri-based apps, which includes kauri-dependency-resolver maven plugin, writing a custom conf dir, using module-source-locations, and putting the tests into a separate project from e.g. a kauri module project (unless it needs only that module).
Change History
comment:2 Changed 3 years ago by bruno
I should add that the (second) circular dependency problem has to do with the fact that I wanted to make the project containing KauriTestingUtility? dependent on all of the lily kauri modules.
Depending on what module you test, you might not need to launch all other modules, so maybe this assumption was wrong. It would then be up to the project using KauriTestingUtility? to decide on what other modules to be dependent (and disable the other ones through Kauri's disable-modules features).
On the one hand I'm inclined to think one might soon run again into circular problems anyway because of wanting to use all kauri modules in the testcases of all kauri modules, however Kauri also does not support circular dependencies between the modules so such reasoning is wrong.
Anyway, I'll leave it as is for now.
(In [4230]) Added a testcase for LilyClient?. It launches the server process node and connects to it. It tries to upload a blob to verify the the blob stores config was set up.
To get all this running, I had to decide what to do with some circular dependencies: the test for LilyClient? requires all kauri modules to be built, including thus the rest-module, which depends on lily-import, and lily-import depends on lily-client. I first thought of solving that by splitting lily-import into lib and cli subprojecs. But then I ran into another problem as I had put the KauriTestingUtility? in a separate project, and thought it made most sense to make that project dependent on all the Kauri modules (since you need them to launch Kauri). However, this is impossible as the rest-module also uses KauriTestingUtility?.
In the end, I decided that the most sensible thing to do is to move these tests out of their 'belonging' projects (rest-module, lily-client) and into a project of its own. Since there are not much tests, I put them into one project (lily-process-tests), though that could be split into more projects if necessary.
kauri-dependency-resolver maven plugin: this plugin will fail to read the artifacts of the lily kauri modules if they are not yet present in the local maven repository. It also does not need to, since these modules are built as part of the current project and hence their dependencies will be downloaded by Maven. Made it possible to specify the location of the module-source-locations.properties file, any artifacts in there will be skipped.
Still, not all is good yet: when running "mvn test" Kauri (launched in the tests) does not find the lily-* dependencies as they are not yet in the repository. Since this is only a problem when running "mvn test" rather than "mvn install", I will ignore this for now, re #108.