IDE Integration for Classpath of Maven Coordinates

[rwinch]

When using gh-10, if there is a module foo that depends on maven coordinates example:bar and both projects are loaded in the IDE, then the classpath of the CommonsExecWebServer should be updated to point to the IDE's build output folder rather than downloading the dependency.

Then users could easily spin up a project and it's dependent projects. All getting quick feedback with the use of devtools on both the main project and the services that it consumes.

For any Gradle/Maven artifact in the workspace, the IDE would expose an environment variable named TESTJARS_ARTIFACT_${group}_${artifact}_${version} which points to a file location of a standard Java properties file that contains the following information:

# the main class to invoke
main=example.Main 
# the classpath to use delimited by the OS specific delimiters
classpath=/home/rwinch/workspaces/project/out:/home/rwinch/.m2/repository/example/foo/1/foo-1.jar:/home/rwinch/.m2/repository/example/bar/2/bar-2.jar

The environment variable will need to be sanitized for characters that are not allowed in ENV variables.

[BoykoAlex]

@rwinch IDE should only be setting the env variable for the tests launch, correct? Not for the main boot app execution, right?
Wonder if it is necessary to store main class and classpath entries in a file... Wonder if 2 env vars would be okay, i.e. TESTJARS_ARTIFACT_MAIN_${group}_${artifact}_${version} and TESTJARS_ARTIFACT_CLASSPATH_${group}_${artifact}_${version} or pack these into one env var... For example first entry in the classpath is the main class FQN and then classpsth entries...

[rwinch]

IDE should only be setting the env variable for the tests launch, correct? Not for the main boot app execution, right?

I think that sounds correct. We can always relax this later on if we got it wrong.

Wonder if 2 env vars would be okay, i.e.

I'd prefer it be a file because I think that this could expand to include system properties, arguments, etc. I'm also not sure about the limitations of the length for ENV variable values.

[BoykoAlex]

@rwinch I think I have IDE part ready for testing for the Maven projects. How shall we proceed with letting you to try it? Are you okay trying it from an STS branch? Or would you prefer having the support in a snapshot build of STS?

Gradle would require a bit extra work computing GAV on the LS side, not complicated, requires moving some things around which I'd rather postpone until we are happy with the overall TestJars support in the IDE.

[rwinch]

@BoykoAlex That is very exciting! I'd prefer not to have to build anything, so if there was a SNAPSHOT of STS that would be helpful.

Gradle would require a bit extra work computing GAV on the LS side, not complicated, requires moving some things around which I'd rather postpone until we are happy with the overall TestJars support in the IDE.

Makes sense. Thanks

[BoykoAlex]

@rwinch I pushed in the TestJars support for Eclipse and VSCode (maven projects only for now). Gradle projects is work in progress...
Here is the STS nightly builds page: https://cdn.spring.io/spring-tools/snapshot/STS4/nightly-distributions.html - it has Eclipse distros, update-sites and vsix files for vscode.
Once you launch your unit tests in Eclipse or VSCode for a project having TestJars on the classpath you should be able to see the env vars for artifacts pointing to property files with main class and classpath