Add auto-env setup

[rmannibucau]

Goal is to be able to reuse the common package managers and inherit from them the needed setup (like sdk use java xxx and sdk use maven xxx for sdkman, xxx being guess from a quick pom/build.gradle review - compiler plugin/task for ex).

Goal is literally to have gum build working without anything else while everything is installed and explicitly fail if something is missing/not found.

Note: a gum.properties can enable to add path locations to find the executable (higher priority than defaults which are appended in terms of test order), should just support $HOME or equivalent to not be hardcoded per user.

[aalmiray]

Hmm interesting. Gum already has a gm.toml config file that may be placed local to the project and/or globally at the user's home directory.

Given that there's more than on way to install a build tool (sdk supports Maven, Gradle, Ant, JBang, but not Bach; Hoembrew, Scoop, etc) the configuration file might need to specify a preferred choice to install a build tool (sdk, brew, etc)

[rmannibucau]

@aalmiray well, this issue is not about installing - it is fine to assume it is installed - but auto-switch the env of the execution (and support at least sdkman by default ;)). For ex, if I have sdkman and the needed version for project1 (java 11, maven 3.6) and project2 (java 17, maven 3.8) then gum build in project1 or project2 works without any tuning and switch the MAVEN_HOME/JAVA_HOME/PATH variables accordingly when forking. Being able to auto install requires more careness since it can download and create folders in locations you can not want too but would be nice later.

[aalmiray]

Hmm, how would gum know that Java 11 is needed? Or a particular version of a build tool for that matter?

Even using a more regular syntax like pom.xml instead of build.gradle[.kts] there's no way to find with 100% confidence which version of Java should be used. There are popular properties like maven.compiler.[source|target|release] but you might as well configure the java version directly on a compiler configuration block, or leave it completely out.

With regards to the build tool version, that's precisely why the wrappers exist, to fix the version of the build tool that should be used with that particular project. If a project does not make use of the companion build tool wrapper, how would gum know which version should be switched to? There could be a "preferred" version found in gm.toml but there's a percentage of times where that version will be the wrong one. If instead the developer decides to use a custom gm.toml on the project to say: this version of Java and this version of maven, wouldn't then be better to set those properties directly on the pom.xml?

Bottom line is, I'm not saying this is a bad idea, just trying to figure out the spread and how things could play out.

[rmannibucau]

Here are the points on my side - does not mean somebody can not see it differently is what i want to emphasize:

1. duplicating anything (java version for ex) -> make gm superseeded by a shell script
2. if gum can't find it then use the current env and let the user doing the setup (with a log info?) but in 99% of project the root pom parsing gives this info and gum has access to that
3. for maven it is just about checking a min requirement in enforcer if present else use the env

Hope it clarifies the idea/goal

[aalmiray]

for maven

Yes, kind of, again there are more limited options to define Java versions than there are in Gradle and Ant. Bach doesn't have that setting, and JBang doesn't neet it as it's baked into the script if you really need a explicit version of Java to run it.

So, this could be done for Maven and would leave Gradle support unmodified. Alternatively a set of predefined check points could be defined for both Maven and Gradle (say use these and that properties) so that Gum has an easier way to find the requirements. If you happen to use a different option then well, too bad.

FWIW I'd rather not parse the pom.xml as even with single file you'll get in trouble if you need to resolve the POM hierarchy to find the correct version of Java to be used. If so, that would require duplicating the Maven Model parsing code with Go.

[rmannibucau]

@aalmiray you don't need maven model - which wouldnt being you anything but the fact you have a plugin with an XML in it. A lot of java and C tools around maven parse the pom as a text file with indexOf or regexes to match opening/closing tags (if a single tag is multiline you can ignore it, it is rare enough to not be an issue), it is not hard to do the same in go and would solve that to extract target/release compiler value if present IMHO.

[aalmiray]

There's no way to parse the Maven model unless it's done from scratch. Any "reads" done to pom.xml, build.xml, build.gradle[.kts] must happen with brand new code, regardless of partial or full parsing.

Yes, regexes could be used but there are not 100% fool proof.

[rmannibucau]

Agree, my point was just it is a trivial task at the end since it is not a strict parsing (even if the file is invalid for the build tool, gum does not care since it just wants to extract some info to run the tool which will validate it). It is also not a 100% impl - exactly as gum tool discovery does not cover 100% of project but 95%, the proposed algorithm should cover most projects so think it is an option.