[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>

[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.

[dizzzz]

note 1: to myself: as symlink alternative

<echo file="${assemble.dir}/bin/backup.bat">@echo off
call "%~dp0template.bat" %*
</echo>

note 2: eXist-db.app does not start

[line-o]

I am in favour of this change. It might be good to have a look at the code analysis warnings to see if there is a useful improvement to be made.

[duncdrum]

much cleaner I like it. not sure how it would affect docker though, there is no shell in our base images.

[dizzzz]

I think that for Docker there are no differences, like you Said

[reinhapa]

@dizzzz there seems to be some warnings from static code analysis left. Could you look into these as well?

[line-o]

@reinhapa at this point as @dizzzz already did go the extra mile and addressed the ones he found to be important to be fixed I would like you to go through the remaining ones and point out which you think should be fixed.

[line-o]

[line-o]

the following two codacy warnings must be ignored

[line-o]

2 of those warnings have to be itgnored as we cannot put double quotes around them

[line-o]

That leaves one warning about the Darwin property never being used. Is that so @dizzzz ?

[dizzzz]

Right :) but maybe we should report the detected modus in debug mode?

Interestingly the original scripts have the same unused item. I decided to leave it in :)

[line-o]

Then @dizzzz either remove it or expose it as you choose. I suspect that we will not stop here to further improve exist-db's startup.