cpurdy
commented
7 months ago I've been talking with Gene about this. It does seem likely that we would regret retaining a "fat jar" as Marcus refers to it, so please consider the "fat jar" approach to be temporary. The reason that this is fairly obvious, is that we are already aware of several dependencies (including some jakarta libs), and that number is expected to grow over time. The likelihood of version disaster (conflict with other people's library versions) is almost 100% if we have more than zero users, and we do intend to have many users. Therefore, we accept that there must be a more standardized approach to the library linking and dependency management, that will fit with existing industry practices.
Currently Javatools.jar is a manually created fatjar that includes javautil_utils classes, third party dependencies (currently jline online) and an implements.x
javatools_utils doesn't really have to be a separate root level project. It can live under javatools and be used as a project (non included build) to get the build output.
The more third party dependencies we want to add to javatools, the more of a monolith it becomes. The chief concerns are
FatJars are generally not recommended. There are various complexity and debuggability issues.
Teaching intellij and gradle that the javatools.jar isn't just a standard IDE Java project requires some hacking (e.g. stealing the lib_ecstasy resource directory), needing to make compile time dependencies runtime dependencies etc. Any Run/Debug. configuration that wants to execute JavaTools as a java app needs some special configuration to make that work. This would work automatically if it explicitly referred to all its dependencies.
The javatools.jar is a build bottleneck and even the slightest change to the independent components it is woven from will create a completely new jar artifact which invalidates all caches, even though a dependency wasn't affecting the use locations of javatools.jar
The Gradle standard for distribution layouts requires writing no extra code, processes dependencies separate already, and could make sure that we ship the dependencies as jar libs (with licenses) under e.g. javatools/libs in the distribution. This will remove the need for a lot of build system logic that we currently rely on handling the javatools.jar as a "normal" project, when it is in fact implicitly depending on several other things
The application plugin for gradle does exactly what we want for distributions.
The user would still be able to use the binary launchers or call javatools with the -jar flag just as before. It is completely transparent and invisible that it's not a fat jar, if it instead e.g. uses its Class-Path manifest entry to point out the dependencies.