Add jline support - Githubissues

In our conversation with Marcus, he argues that the best way to deliver the libraries separately. Markus wrote:

I think you should consider not having the jline.jar expanded in the javatools.jar ... If you look inside the jar, does it only contain the jline contents or does it contain all manners of transitive dependencies from jline and other parts of the world too? And because the javatools.jar is exactly what Maven means with an "application". An "application" is something with a main entry point (the Launcher) in main class, with dependencies. (in this case the only third party one is jline). Normally you would do a two liner to create a useful application distribution. You would apply the build in application plugin in the plugin section. Then you would declare an implementation dependency in the dependencies section to the jline artifact. Then you would run the install dist. Then you would end up with two start scripts, one for windows and one for unix in a bin dir, a lib dir with the javatools.jar and the jline.jar as separate files, and a resolution mechanism to run this as a single classpath through the init scripts. This plugs directly into things like creating a binary exe distribution with jlink/jreleaser or creating releases, using a very standardized layout. If you apply the application plugin, it automatically applies the distribution plugin. The default distribution which is e.g. what goes into the default distTar and the default distZip tasks will contain bin/javatools (a launcher script, which also is understood by Gradle, so that you don't need to use it explicitly if you use javatools elsewhere), lib/javatools.jar and lib/jline.jar. I even think it adds whatever the java key for "here is a classpath to other jars dependent to me, the javatools.jar and my manifest" so that if you just run -jar javatools.jar, it will automatically figure out it has a sibling jar file that it needs as a dependency. When you do shadow jars, you may end up with a HUGE amount of extra stuff that you don't need. And it becomes more bloated to more dependencies you add. I would opt for using the existing mechanisms for applications and distributions, which includes manifest code that uses the "Class-Path:" attribute in the javatools.jar mainfest. I think it's automatically written by the aplpication plugin, and you don't even have to override anything or write any code. In that case, the xdk distribution would contain the javatools.jar and the jlink.jar (possibly under javatools/lib to avoid cluttering up the xtc specific javatools directory). The javatools.jar would just refer to the relative Class-Path attribute in its manifest, with "Class-Path: ./lib/jline-verison.jar", or whatever it looks like, and anyone starting java -jar javatools.jar ... will automatically get the jline jar loaded. The good thing about this if it works like I think it does, is that you need to write very little code for it. You would enable the application plugin, add a jline dependency by alias in the libs.versions.toml file, and add an implementation(libs.jline) to the dependencies in the javatools project. And likely a slight weak to the xdk distribution contents so it also brings the libs with it. The XDK should actually be the main application class, which is what andres was talking about before. Anyway - I recommend strongly that if we have dependencies, we distribute them outside the jar, use the application plugin to avoid having to manually do much , including adding the manifest entry, and that an unpacked xtc distribution has a libs directory under the javatools directory, where all the dependencies for our javatools.jar reside as separate jar files.

xtclang / xvm

Add jline support #193