Add tests to check packaged transport client / test framework dependencies

[ywelsch]

For the transport client as well as for the test framework it would be nice to have tests that check whether the dependencies can be properly consumed (from Maven/Gradle/SBT) when using a local maven repo with all dependencies properly packaged. This would consist of a simple build file and a sample class file that connects to an Elasticsearch instance running locally and executing a few commands. We could then have assertions on the exact output we expect. We could then publish the same code as part of the documentation.

Relates to #21119

[rjernst]

I think these would be better as "unit" tests on the generated pom, which could be done just using gradle (since we know gradle is installed). Since some of our jars depend on others of ours, I think we would need a single test for the repo, which would generate a fake maven repo (I don't think we should use or depend on mavenLocal). Then create a single build.gradle file which has a separate configuration for each artifact, and set that artifact as the sole dependency of the configuration. Then just try to resolve dependencies with gradle dependencies.

Testing other build systems should be within the unified build process, so that other projects can benefit (eg logstash has jars which will eventually be published to maven I believe), and then the additional tools necessary for each build system can be automatically installed. We could still generate the build files for each system based on the configured artifacts, and we can have it configured to point to the staged maven repo (and when releasing, we can run the same test but with real mavenCentral as a check that the release worked).

[ywelsch]

I like your suggestion @rjernst. I care mostly about the end-to-end test where we have a minimal example for each build system that is compiled (and ergo dependencies successfully resolved) and that runs a simple test against a real cluster. This gives us an example that we can link to from our documentation that is always tested to work.

[dadoonet]

I agree.

I used to have such a maven project which I was using to document our Java API. Was a way for me to easily see regressions and see what I have to change in our docs.

May be I can create a new repo based on that work which we can reuse in the unified build? Is that what you have in mind @rjernst?

[rjernst]

No, I was not thinking of a new repo. I think we should have something that can give feedback when running gradle check. My thought was a new task at in the root project, which would depend on assemble tasks for poms, dynamically create a build.gradle, dynamically place those poms and associated jars in a fake maven root, which the build.gradle points to, and then run gradle dependencies.

For the higher level integration tests in the unified build system, again, I think build files should be generated so we automatically cover all of our maven artifacts. As for documenting for users, I'm not sure of the best approach. I don't think a separate repo will help there, as it will require manually updating once the build is released. Something that is generated as part of the release process would seem better to me.

[alpar-t]

I think https://github.com/elastic/elasticsearch/blob/master/buildSrc/src/test/java/org/elasticsearch/gradle/BuildExamplePluginsIT.java now mostly covers this use case. It build example plugins as stand alone projects using a locally generated maven repo . The example plugin runs integration test so it exercises both build tools and the testing FW. The missing bit is that we may have artifacts in the local repo that are not actually published.

[mark-vieira]

Essentially this is what these tests now do. We build our example plugins (which consume the test framework) ensuring they can resolve any and all dependencies.