I am working on a couple of minor tweaks for the [tado] binding. But before I open a PR, I need to resolve the MVN error in the screenshot below (“the pom for jar is missing no dependency information available”)
Background: the tado binding depends on a helper JAR which is built using Swagger from a YAML file. The dependency is listed in the binding’s POM file. And the helper JAR does have its own POM file (in another directory), but evidently MVN can’t find the helper POM file to build the helper JAR before building the binding main JAR. Or something like that.
It used to work last summer, so apparently something has changed in the build system whereby this now does not work.
You don’t need to fix it per say as long as api-client does not have any dependencies which should be promoted back to the binding.
Primary role of maven POM is provision of dependency information for a build so library developer can declare what he needs to compile and run what he provided.
If you have a control over api-client then you can try to generate a proper maven artifact (with pom attached) or simply run maven swagger plugin with your own build instead of relying on external dependency.
It seems that the main error was because the dependency artifactId was wrong in the pom.xml. (it was “api-client” but it should have been “tado-api-client”. I can create the “tado-api-client” jar locally via swagger and save it in the binding’s /lib folder. And then (after correcting the name in the binding pom.xml), I can locally build the whole binding jar now without any more errors.
But now I have a second question: is there a way to extend the binding’s pom.xml file so that MVN will do both of the above operations in one go? – namely 1) build the “tado-api-client” jar, and then 2) build the binding jar based on that…
If you generate api-client youself locally then you need to copy appropriate resources such as openhapi.yaml/swagger.yaml to binding (ie src/main/resources) and necessary maven plugin configurations from pom.xml your api-client project.
Once you complete this the additional dependency will be unnecessary as plugin will generate client code which will be pulled into final JAR. You can check the api-client project if it has anything under target/generated-sources cause this is primary location used for transforming service descriptors into Java client code.
I don’t know what plugins you currently use in maven build thus I can’t tell you more than above.
Yes, there are two pom.xml files, one of the pom’s (call it pom#1) is used to build the api-client.jar file from the yaml file with swagger, and the other pom (call it pom#2) is used to build the binding itself, and indeed pom#2 does cause the api-client.jar to be built into the binding jar file.
The way it works now, is that one must manually execute pom#1 before manually executing pom#2; otherwise the api-client.jar file does not get built, and this therefore causes pom#2 to fail due to the broken dependency on the missing api-client.jar file.
=> So my question now is if it is possible to combine pom#1 and pom#2 into one single master pom file so that when MVN tries to build the project, it will execute both sets of tasks sequentially? Apologies but my degree of knowledge of MVN pom syntax is very low
To quickly address your concerns and let you continue - the relation between poms you have is intentional and it is called a dependency. I believe you can successfully combine both POMs as long as you don’t have much logic in tado-api project. Normally clients generated by Swagger are rather basic and require no additional wrapping. If whole goal of having tado-api is its use in tado binding then you can safely merge both into binding.
Maven POM files allows you to plug multiple plugins under build/plugins/plugin XML node so you can move plugin nodes from first project to second as long as you also copy necessary resources which I suggested in my earlier answer.
Maven executes plugins in semi deterministic order. First of all plugins declare build phase (such as prepare-resources, compile, test-compile, test, package etc), you can also override it in POM inside executions/execution/phase node of plugin. This makes first level of sorting - so sources are generated before actual compilation is made. Second level sorting is done based on plugin declaration order in the POM. If you have plugin node B as a first under build/plugins and A as a second both attached to same build phase maven will first execute B and then A. There is no inter-linking between plugins so you have to sort them in the pom file or by using valid execution/phase combinations.
That’s pretty much it if it comes to plugins.
Enjoy!
