[feature] get rid of appassembler-maven-plugin

[dizzzz]

Context

Until now, eXist used the outdated appassembler-maven-plugin to create the startup code the application. It created a set of shell scripts, each invoked a boot loader, which read an XML file to find the relevant JAR files, created its own classloader and invoked the class org.exist.start.Main to get eXist started.

As a drawback it was difficult to add an extra jar file or to apply an hotfix by updating one jar file.

Since java 8 or so the 'java' commands allows an * in the classpath. This PR effectively make use of this feature.

@duncdrum I think this might be useful for our docker deployments.

---

old content of etc directory:

old content of XML file:

<?xml version="1.0" encoding="UTF-8"?>
<daemon>
  <id>client</id>
  <mainClass>org.exist.start.Main</mainClass>
  <classpath>
    <dependencies>
      <dependency>
        <groupId>org.exist-db</groupId>
        <artifactId>exist-distribution</artifactId>
        <version>7.0.0-SNAPSHOT</version>
        <relativePath>exist-distribution-7.0.0-SNAPSHOT.pom</relativePath>
      </dependency>
      
	  <!-- 1000's of generated lines -->
	  
      <dependency>
        <groupId>stax</groupId>
        <artifactId>stax-api</artifactId>
        <version>1.0.1</version>
        <relativePath>stax-api-1.0.1.jar</relativePath>
      </dependency>
    </dependencies>
  </classpath>
  <commandLineArguments>
    <commandLineArgument>client</commandLineArgument>
  </commandLineArguments>
  <configurationDirectory>etc</configurationDirectory>
  <repositoryName>lib</repositoryName>
  <licenseHeaderFile>/....../LGPL-21-license.txt</licenseHeaderFile>
</daemon>

[dizzzz]

• check build log, directory "log" is missing, probably more
• make JAVA_OPTS configurable
• introduce EXIST_OPTS

[duncdrum]

very cool, a bit too much to think about for the comments here. Yes wildcard works even with J8, been running it for 4 years now. We would need to keep an eye on the backup, recovery, etc workflows on all three OSs to make sure they still work. We have no integration tests for this, so we need to do it manually.

The Dockerfiles here and at duncdrum/existdb will need adjustments.

I really like the idea of improvements to modifying JAVA_TOOL_OPTIONS and introducing EXIST_OPTS. Note that for java 21 you can use JDK_JAVA_OPTIONS to get some compostability going see tp-app as far as I understand it JAVA_OPTS is not a thing.

[dizzzz]

I have seen 'JAVA_OPTS' mostly in old scripts, it looks like it was a pattern once used in the tomcat scripts.

setting this details in an environment variable will will make the scripts more clean and readable.

I will revise the PR with the ideas.

[adamretter]

Since java 8 or so the 'java' commands allows an * in the classpath. This PR effectively make use of this feature.

That could open up a security issue, as an attacker can just drop a jar file into a folder.

I have seen 'JAVA_OPTS' mostly in old scripts, it looks like it was a pattern once used in the tomcat scripts

JAVA_OPTS is pretty much defacto for all Java applications these days, and has been for many years. Users and developers have come to expect it.

JAVA_TOOL_OPTIONS
JDK_JAVA_OPTIONS

You should avoid these as they have much wider implications.

[dizzzz]

I considered the potential security issue already. When the variables are locally defined, and the java command is the last one in sequence, there should be no side effects IMO. If one has access for writing access anyway, an existing jar file (or the xml) can be updated any way. The security risk is merely changed not different.

I checked a bit more on 'JAVA_OPTS' it seems to be originated from the Catalina scripts, hence an implementation decision? I will check a bit more though. I will follow this pattern.