This hello-world.git repo is created using the native Git for Windows
software.

Various test classes in the GitBlitSuite test suite require the presence
of the hello-world.git repo in github.com/git/ which has been missing,
hence causing many test failures in the suite. This recreation of the
hello-world.git repo aims to conform to the many test cases'
requirements in the suite, and to be checked in as part of the gitblit
repo, thus eliminates the requirement of a remote hello-world.git repo
during the test run. The repo is now stored in the new src/test/data
folder.

The hello-world repo's various commit IDs were hard-coded in various
test classes. These commit IDs, which must now have new values in the
recreated repo, are now extracted out to the
src/test/data/hello-world.properties file. The gitblit's build.xml is
modified to generate the HelloworldKeys.java file containing the
hello-world.properties file's key strings, in similar fashion as the
existing generation of the com.gitblit.Keys.java file. And these key
strings in HelloworldKeys.java are now used in the various test classes,
thus eliminating the hard-coding of the hello-world repo's commit IDs in
the test code.

Most of failures were due to temporary test repos, users and/or teams
being left behind after the test run, and these left-over stuff in
$baseFolder/data/git caused assertion errors in many tests in subsequent
test runs. This fix tries to delete those left-over stuff at the end of
each test, mainly in their @afterclass code blocks.

PushLogTest.java is deleted as it doesn't work, and has been superseded
with better tests in various protocol test suites (GitServletTest,
GitDaemonTest, SshDaemonTest, etc.)

During the test run by GitBlitSuite test suite, some repos from GitHub
were cloned and became part of the test data. These repos are now zipped
to be part of gitblit repo itself, thus eliminating the network fetch at
the start of test run which can be slow, especially with the JGit repo
cloning which is huge and time consuming. The cloned JGit repo is now
zipped and checked in to gitblit, along with the other 4 repos
(hello-world, ambition, gitective and ticgit). They will be unzipped
during the test suite run and be available in the local file system,
thus avoiding the need for some network fetch.

Special note on the zipped JGit repo: this repo is big (and growing all
the time on GitHub), and takes up about 32MB of disk space after cloning
from GitHub. I've made it smaller by resetting HEAD back to a commit of
5 years ago (with git reset --hard <commitId> command), to put it back
to roughly where/when the tests were written for it (which is not quite,
because there are tons of commit history since which can't be removed.)
This local JGit repo is then garbage-collected (with git gc --prune
--aggressive) to reduce its size to about 19MB, then is zipped and
checked in with this commit.

The purpose is for ease of test execution and test failure
investigation:

 * src/test: existing folder, for pure unit tests.
 * src/repoTest: for tests requiring some existing repos but no need for
a gitblit server.
 * src/serverTest: for tests requiring the gitbit server to be running.
The current GitBlitSuite class would go here, plus other test classes
requiring a gitblit server.
 * src/uiTest: for tests of the gitblit UI.
 * src/extServiceTest: for tests requiring some external service to be
available.

Standard Gradle tasks are used in the build.gradle script to compile and
package Gitblit artefacts. Also, custom Gradle tasks are added to the
standard buildSrc folder to achieve complex operations which are unique
to the Gitblit project, and thus are unavailable in standard Gradle or
any plugins.

Gradle itself need JDK8 or later versions to run, and by default the
same JDK is also used by Gradle to compile the Gitblit project's code.
But due to current targetCompatibility = '1.7' setting, the resulting
build artefacts are still compatible with the Java7 runtime.

If the JDK7 compiler is required, some settings to use the JDK7
installation are already in the build.gradle script, but are currently
commented out. They need be made available, with the correct path
to the local JDK7 installation be specified in the 'jdk7home' property.

A Gradle installation is not required to run the build script.
The "Gradle wrapper" is already included in this commit to automatically
download the relevant Gradle software to use, with the "gradlew"
command.

The following commands should be executed in the Gitblit folder where
the build.gradle script resides, to build Gitblit software.

To produce all of the Gitblit artefacts, use the buildAll task:

  gradlew buildAll

The above command will generate all Gitblit software artefacts in
build/distributions folder, which include the Gitblit GO, WAR, Manager,
Federation Client, API client, and the site docs.

To build just the Gitblit GO software:

  gradlew buildGO

and the resulting gitblit-<version>.zip (for Windows) and
gitbit-<version>.tar.gz (for Linux) are produced in build/distributions
folder.

Similarly, to build just the site documentation:

  gradlew buildSite

and the Gitblit html documents are produced in build/site folder.

For the IDE tool such as Eclipse or IDEA development tools, the project
can be imported directly into the IDE, as they should understand and act
on the Gradle build script in the project. For example, in Eclipse, the
Gitblit project can now be imported directly via the File menu:

  Import --> Gradle --> Existing Gradle Project

And thus, all current files in the repository relating to Eclipse and/or
IDEA tools are deleted by this commit, and are added to the
.gitignore file, as they are now just for local development use.

- merged with upstream's 1.9.0 release
- minimum Java version is now 1.8, to suppport
  Selenium 3 and latest Firefox's web driver in UI testing
- Gradle wrapper upgraded to 6.2.2 version
- weblogic.xml fixed to use WebLogic 12's latest schema
- gitblit, authority, manager, fedclient commands can load
  the jar files in the 'ext' folder dynamically
- authority and manager commands now show the splash screen properly
  during the dynamic loading of the jar files from the 'ext' folder
- the dynamic loading of the jar files from the 'ext' folder works
  for all Java 1.7 and later versions

- merged with upstream's 1.9.1 release