Isolated distribution should include the tools/dependencies needed to build Galasa tests

[eamansour]

Story

As a user using the isolated distribution of Galasa, I want to be able to build Galasa tests using isolated out-of-the-box without any additional setup, so that I can develop Galasa tests offline.

Background

The current offline distributions of Galasa appear to only include what is required to run Galasa tests, not what is required to build them offline.

This excludes essential build-time artifacts including the galasa-maven-plugin, maven-bundle-plugin, and a set of parent POMs. If customers intend to build and run tests in isolated/offline environments—which seems like the expected workflow—the distribution is incomplete.

We should also include the mvn and gradle tooling within the offline distributions so that customers can immediately start building with Maven or Gradle, especially as we already bundle the galasactl CLI tool which can be used to generate both Maven and Gradle starter projects.

Tasks

• Investigate and build a list of artifacts required for building tests that the isolated distribution is missing
• Include a version of the mvn tool within isolated
• Include a version of the gradle tool within isolated
• Test that you can build and run a new Galasa test project with isolated
• Documentation/release notes updates

[ideeley]

mavenArtifacts.txt

Attached file is a list of all the missing artifacts for a Maven build. The methodology I used to create this list is:

1. Create a new test project using galasactl with the --maven option.
2. Delete the local maven repository.
3. Update settings.xml to point at the MVP's maven folder first, followed by maven central.
4. Edit the test project's pom.xml to include dependencies on all dev.galasa.*.manager artifacts in the MVP's maven/dev/galasa folder.
5. mvn clean install the test project, piping stdout into a file
6. Extract all lines from the file that include "Downloaded from maven.central: https://repo.maven.apache.org/maven2/", extract artifact information, and sort.

I've excluded instances of maven-metadata.xml from the list - I'm assuming that these will fall out in the wash as part of building the maven folder for the MVP.

One item of note: I couldn't find dev.galasa:galasa-simbanktests-parent:0.45.0:pom which is needed because it's the parent of dev.galasa:dev.galasa.simbank.manager:0.45.0:pom. It's not in the MVP, and it's also not on maven central! In the end, I had to download it from the source, rename it, and manually insert it into the MVP (so it's not listed in the file, but should be). The simbank manager is also not in the galasa BOM, so it's necessary to specify the version on the dependency - not sure if this is intentional.

Now working on doing something similar for Gradle builds....

[ideeley]

gradleArtifacts.txt

Attached is the additional artifacts required for a Gradle build (excluding those that are also required for a Maven build). Gradle doesn't produce output as useful as Maven, so I had to do this as follows:

1. Create a new test project using galasactl with the --gradle option (it's actually the same one I did for Maven - I specified both options)
2. Delete the contents of the .gradle folder. Also deleted the local maven repository, though not sure this was strictly necessary).
3. Edit the test project's settings.gradle to point at the MVP's maven folder ahead of the Gradle Plugin Portal and Maven Central (though not sure this is strictly necessary, considering what I had to do to extract the information). Similarly in the test sub-project's build.gradle.
4. Edit the test sub-project's build.gradle to include dependencies on all dev.galasa.*.manager artifacts in the MVP's maven/dev/galasa folder.
5. gradle clean build publishToMavenLocal. Using gradle 9.2.1, if that's of any significance.
6. Manually construct a list of artifacts from analysis of the contents of .gradle/caches/modules-2/files-2.1, excluding anything that's in the MVP or the maven list attached in the previous comment.

[ideeley]

Following those changes, I manually updated the MVP with all of the missing dependencies, manually updated a few metadata files as needed, then I disconnected from the network and successfully built my test project with both Maven and Gradle. That demonstrates to me that the combined lists are sufficient, though I have yet to prove that they are all necessary (though I'm pretty sure we'll need all of the poms, might not need to have multiple versions of the jars).