This is a deliberate change.
The files in `jetty-home` are to be treated as read-only, and never edited / modified in any way.
Do not treat `jetty-home` in the same way you treated `jetty-distribution`.
The concept / habit of modifying a distribution died when Jetty 9 was released.
Jetty 9 also has a jetty-home. (on Jetty 9, the jetty-distribution was the combination of jetty-home + a demo ${jetty.base} + a warning to not use jetty-distrbution in a modified sense)
All releases of Jetty 9 gave a clear warning on startup if you did that. (This is the deprecation period)
Jetty 10 removed it entirely.
Using the `${jetty.base}` and `${jetty.home}` directory split is the recommended approach.
Example:
# Create a new directory that is not nested around or inside of the jetty-home directory.
$ mkdir /path/to/my-jetty-base
# Configure the ${jetty.base} directory (with files and configuration in `${jetty.base}/start.d/`)
$ cd /path/to/my-jetty-base
$ java -jar /path/to/jetty-home/start.jar --add-module=http,deploy,demo
# Copy your webapp into place
$ cd /path/to/my-jetty-base
$ cp $HOME/projects/petshop/target/petshop.war webapps/
# You can ask to see the configuration ...
$ cd /path/to/my-jetty-base
$ java -jar /path/to/jetty-home/start.jar --list-config
# When it's time to run Jetty.
$ cd /path/to/my-jetty-base
$ java -jar /path/to/jetty-home/start.jar
The way this is setup, you have zero need to modify anything in jetty-home, all configurations can be done in jetty-base.
Anything from jetty-home can be either configured (with properties, see contents of --list-config and start.d/*.ini, or with minimal XML to tweak default behaviors)
This also simplifies the upgrade process between versions of Jetty.
See also:
