Support for tool dependencies

[aBega2000]

As a devonfw-IDEasy user, I want to have tools being setup with their correct dependencies so that it just works and I do not have to worry.

E.g. several tools have java as dependency:

• mvn
• eclipse
• intellij
• jenkins
• sonar
• tomcat Implement ToolCommandlet for Tomcat #36
• ...

However, they may all require different versions of java ending up in an inconsistent situation that devonfw-ide currently cannot resolve. As a solution I see the following ideas:

• In ide-urls in each tool/edition version folder we will introduce a new (optional) dependencies.json file.

• This file will contain a list of 1-n tools with their required version or version range (similar to a dependency in maven, gradle, or npm).

• We can still discuss if that should be in JSON format (and then being named dependencies.json) or just a plain file with one dependency per line (TBD)

• If no such file is present, there are no dependencies required. Otherwise these dependencies have to be setup as well to launch the tool.

• In order to avoid conflicts between different versions of the same tool, we make the shared software repository the new default.

• The default java version for the build (e.g. for maven or gradle) will still be found in software/java but as a symlink to the configured JAVA_VERSION.

• However tools like eclipse/intellij/jenkins/sonar/... can require their own Java version via the dependencies file. If the default Java (JAVA_VERSION) does not match, then an additional java version is found or installed in the shared software repository and used instead by setting JAVA_HOME to it and adding it to the beginning of the PATH but only locally in the commandlet before launching the java based tool.

• We will analyze if we can find ways to automatically determine dependencies for specific tool versions. Where not possible, we will simply put the latest default into the according UrlUpdater class for that tool/edition and have to change it whenever a new version comes out that has different dependencies. If we notice too late (what might be the regular case), we have to change existing dependency version file(s) manually and also change the UrlUpdater then for future versions.

• All existing dependencies will need to be added via manual crafting what can be quite some effort.

[aBega2000]

3 Options how a Json file could look like to match the versions between tomcat and Java:

Option 1:
{
"tomcat 7*": "Java 7*",
"tomcat 8*": "Java 7*",
"tomcat 9*": "Java 8*",
"tomcat 10*": "Java 11*",
"tomcat 11*": "Java 21*"
}

Option 2 (nested Objects) :
{
"Tomcat 7": {
"javaVersion": "Java 7"
},

"Tomcat 8": {
"javaVersion": "Java 7"
}
}

Option 3 (Array of objects):
[
{
"tomcatVersion": "Tomcat 7",
"javaVersion": "Java 7"
},
{
"tomcatVersion": "Tomcat 8",
"javaVersion": "Java 7"
}
]

[aBega2000]

Since the tomcat versions work with the matching java version or LATER, I suppose we just need to check the minJavaVersion that the actual tomcat version matches. Because if tomcat version 10 works with java 8 or later, it means that if we have java 17 in our system, then everything is fine. So just a suggestion would be:

{
"7": {
"javaMinVersion": "6"
},
"8": {
"javaMinVersion": "7"
},
"9": {
"javaMinVersion": "8"
},
"10": {
"javaMinVersion": "8"
}
}

This still needs working, but I just want to know if this is a good foundation for writing the JSON file.

Another question would be, how to construct a range or an array of versions for tomcat, in the case of tomcat version 9 and 10 for example, so that I don't repeat code, since both of these versions need javaMinVersion 8. And also what other options can I add in each tomcat version except javaMinVersion?

[hohwille]

My suggestion would be something like this:

{
 "«version-number-or-range»": [ { «dependency» } ]
 ...
}

So we define a selector «version-number-or-range» that is either a version range (e.g. 1.0---3.2.7 using a separator such as --- that does not occur in a version number itself, could also be < instead of ---) or just a version to define a range relative to the previous entry (so we define an implicit range starting from the max of the previous range).

We then go through this and find the matching selector for the version to be installed.
For this we apply the dependencies. This is defined as a JSON array containing dependencies as JSON objects («dependency»). Most obvious syntax would be:

{ "dependency":"java", "version":"21*" }

The entire object is actually the dependency and the property name dependency could also be named tool. But by naming it dependency it might get more readable.
Optionally a edition property could be specified in such a dependency.

The remaining question for me would be how to handle selector versions to be inclusive or exclusive (<= vs. <). Maybe looking at your example with tomcat, it would be more natural to define the semantic of the selector so that single versions are rather the minimum version up to the next

{
 "11":[{ "dependency":"java", "version":"21*" }],
 "10": [{ "dependency":"java", "version":"11*" }],
 "9": [{ "dependency":"java", "version":"8*" }],
 "7": [{ "dependency":"java", "version":"7*" }]
}

This would mean that we check our tomcat version to be installed from top to bottom:

1. if tomcat version >= 11 then use java 21* as depedency
2. else if tomcat version >= 10 then use java 11* as depedency
3. else if tomcat version >= 9 then use java 8* as depedency
4. else if tomcat version >= 7 then use java 7* as depedency
5. else no dependency defined, log info message but nothing to do additionally

For other use-cases, we would also need to implement and support a version range as well and one could even specify something like

"1.0---1.0":  [{ "dependency":"dotnet", "version":"2.1.526" }],

so if the version to be installed is exactly 1.0 we then would have a totally different dependency and as we can see from the example the version may also be without a *.

The alternative and more explicit form for the JSON would IMHO be too verbose:

[
{"selector":{"minimumVersion":1.0", "maximumVersion":"1.0"}, "dependency":{"tool":"dotnet", "version":"2.1.526" },
{"selector":{"minimumVersion":10", "maximumVersion":"11", excludeMaximumVersion: true}, "dependency":{"tool":"java", "version":"11*" },
{"selector":{"minimumVersion":11"}, "dependency":{"tool":"java", "version":"21*" },
...
]