doc: Cleanup Google Code links and obsolete design description
Replace the links in NOTICE to the closed down Google Code
(code.google.com) with their Github counterparts where the projects
moved to.
Gitblit used to download dependencies upon first start. This has since
long been changed and everything is bundled with Gitblit now. So reflect
this in the design.mkd document, which still said they would be
downloaded.
site: Old packages moved from Bintray to Cloudsmith
Since Bintray seized operation, the packages for versions 1.4.0 - 1.8.0
have been uploaded to Cloudsmith. Adjust the links appropriately.
An attribution is added to comply with Cloudsmith's OSS hosting policy.
Update the URL to the Gitblit docker image to point to the
`gitblit/gitblit` repository, which I now consider the official
Docker repository.
Also link to the Docker images on the main page.
Fix 1150: Use external link instead of internal wiki link for tickets_setup
The `tickets_overview` page links to the `tickets_setup` page using a
wiki style internal link: `[[tickets setup]]`. Whatever library is
interpreting that is creating a link under the assumption that the
resulting page will be called `tickets-setup.html`. But that is not the
convention used by Moxie, which will use the source file name and thus
create a file called `tickets_setup.html`.
I was not able to find out which of the many libraries included is the
one that parses this file and creates the link. Messy.
There are two solutions. One is to configure the Moxie site build to
generate the file as `tickets-setup.html`. But this would break any
links to that page that might exist somewhere on the Interweb. So I
opted for the other option, which is to not use wiki syntax for the
reference to the local page but normal markdown syntax. This is not
a wiki, afterall.
While most systems will not need the class path passed to the JVM with
the `-cp` parameter to be in quotes, apparently some exist where that
will not work without the quotes, e.g. FreeBSD.
So always use quotes for the class path in all scripts.
Issue #1333
Add Ant tasks and macros to deploy binaries to GitHub,
using GitHub's releases.
Adds an Awk script to extract GH flavoured markdown release notes
from the release.moxie file.
Adds `ok.sh` to the repository so that it is readily available.
This is a Bourne shell GitHub API client, used to create a release
on GitHub and upload the binaries.
For Java 9+ define the classpath instead of using a Launcher.
The (moxie and other) Launcher do not work with Java 9 and later anymore.
It used to dynamically extend the classpath, misusing an internal
interface of the `URLClassLoader`. This is no longer possible since Java 9,
which closed that path and does not offer any way to dynamically extend
the classpath during runtime.
So the choice is between providing one large Jar with everything in it,
providing a Jar that has the Jars in `ext` listed explicitly in its
manifest, and specifying the classpath on the command line where
the `ext` directory can be added and all contained jar files will
be put on the classpath.
The motivation for the Launcher class was to be able to simply drop
new jar files into a directory and they will be picked up at the
application start, without having to specify a classpath. We opt
for solution three here. This way jar files can still be dropped
into the ext directory, albeit the directory needs to be added to
the classpath on the command line. Unfortunately using a wildcard
is not possible in the manifest file. We change the calls in the
script files accordingly. This seems like a good compromise,
since no one will run the application manually typing the whole
commandline anyway.
This also does away with the splash screen, by the way. Again,
doesn't seem like a big loss, as I don't think it was ever shown
for the Authority.
Personally, I am not convinced that it is the best way, because
I don't really think that the use case of dropping whatever jar
files into the `ext` directory is a valid one that happened a lot.
This does not yet fix the client programs, which still use a
Launcher. Maybe for them a all-in-one Jar is a better solution.
Fixes #1262
Fixes #1294
Integrate the `PasswordHash` class and subclass in the user
and password editing and authentication. Replaces the old code and
the previous `SecurePasswordHashingUtils` class.