[LOGGING-173] remove Apache Avalon, defunct for over a decade

[elharo]

[elharo]

CI appears to need attention:

Error: Unable to process command '::set-env name=JAVA_HOME_16.0.0-ea.24_x64::/opt/hostedtoolcache/jdk/16.0.0-ea/x64' successfully.
Error: The `set-env` command is disabled. Please upgrade to using Environment Files or opt into unsecure command execution by setting the `ACTIONS_ALLOW_UNSECURE_COMMANDS` environment variable to `true`. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
Error: Unable to process command '::set-env name=JAVA_HOME::/opt/hostedtoolcache/jdk/16.0.0-ea/x64' successfully.
Error: The `set-env` command is disabled. Please upgrade to using Environment Files or opt into unsecure command execution by setting the `ACTIONS_ALLOW_UNSECURE_COMMANDS` environment variable to `true`. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
Error: Unable to process command '::set-env name=JAVA_HOME_16_0_0_EA_24_X64::/opt/hostedtoolcache/jdk/16.0.0-ea/x64' successfully.
Error: The `set-env` command is disabled. Please upgrade to using Environment Files or opt into unsecure command execution by setting the `ACTIONS_ALLOW_UNSECURE_COMMANDS` environment variable to `true`. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
Error: Unable to process command '::add-path::/opt/hostedtoolcache/jdk/16.0.0-ea/x64/bin' successfully.
Error: The `add-path` command is disabled. Please upgrade to using Environment Files or opt into unsecure command execution by setting the `ACTIONS_ALLOW_UNSECURE_COMMANDS` environment variable to `true`. For more information see: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
creating settings.xml with server-id: github; environment variables: username=$GITHUB_ACTOR, *** and gpg-passphrase=null
writing /home/runner/.m2/settings.xml

[garydgregory]

This won't happen until master switches to 2.0 and changes the package name which will break this PR. Until then, we could split up this project into a multi-module component, needs thinking...

[garydgregory]

@elharo Please rebase on master.

[elharo]

When is that likely to happen?

[garydgregory]

Well, I have no plans ATM to do so. But... if we release a new version that breaks binary compatibility, then we will have to change the package name and Maven coordinates, so that will be a source code change for call sites, which should/could be as simple as changing a package import from foo to foo2. Then, if we are going to bother going a major release, we should IMO break up this component into a multimodule project, which means that each module will be in its own package to make JPMS happy. If we did such a Maven modularization in 1.x while keeping the package names the same, then this would cause Java 9 and up to complain and maybe not even work since all the implementations are in the same package today. Any thoughts from you or the community?

[elharo]

My personal thoughts are that this project has run its course. java.util.logging and SLF4J between them seem to serve the market. If it's not moving forward, then it's probably best to archive the repo and close the project.