Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle conversion #1314

Open
wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Conversation

chirontt
Copy link

@chirontt chirontt commented Jul 1, 2019

Conversion to Gradle build tool, replacing Moxie.

As this is a big pull request, it is recommended that this should be accepted into a branch so that it doesn't disrupt work on the master branch. And a branch allows other people to safely experiment with.

In this Gradle conversion, the current structure of src/main/java of the Gitblit source code remains intact, and the whole Gitblit folder is just one (big) Gradle project. Future work may re-organize it into Gradle sub-projects (similar to the Maven modules).

This commit uses Gradle to replicate most (not all) of the build targets of the old build.xml Ant script which made use a lot of functionalities of the Moxie toolkit. The targets being left out are the ones to do with Maven and Bintray uploads, which can be done at a later time.

Even when Moxie is removed to be the build tool for the Gitblit project, some of its functionalities are still used where required, e.g. where the 'releases.moxie' file need be parsed to produce the 'releasenotes.html' and 'releases.html' files for the site documentation. Moxie is needed here because the 'releases.moxie' file format is specific to Moxie and requires Moxie code to parse it. In these scenarios, Moxie is used as a dependency library to some of the custom Gradle task classes residing in the buildSrc folder.

To build all of Gitblit software artefacts, here's the Gradle command:

gradlew buildAll

And the build artefacts would be produced in build/distributions folder, which would contain the Gitblit GO files, the Giblit WAR, Gitblit Manager, Federation Client, Gitblit API Library, and the site documentation.

Further Gradle info are in the commit's message.

An added bonus is that the Gitblit software now can be run by Java 7 and up, to Java 12 version, due to modifications made to various 'Launcher' classes in the dynamic loading of library jars at runtime, which used to fail to work when running Gitblit 1.8.0 with Java 9+.

The test classes in src/test/java have been split into many separate folders for ease of test execution and failure investigation:

src/test: the original test 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 goes here, plus other test classes requiring a gitblit server instance.
src/uiTest: for tests of the gitblit web UI.
src/extServiceTest: for tests requiring some external service to be available e.g. Redis.

As a result of the above re-org, tests in the original src/test folder can take part in an automated build process by a CI server, while other test folders are considered 'integration tests' and can be executed in a manual way, like in Gradle command:

gradlew serverTest

would run the tests in src/serverTest/java folder via the GitBlitSuite test suite class, while the command:

gradlew test

would just run the 'pure' unit tests in src/test/java folder. Similarly for other test folders.

Gradle can start a Gitblit server instance with the runGO task:

gradlew runGO

chirontt and others added 7 commits April 27, 2019 14:51
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.
@flaix flaix self-assigned this Nov 16, 2019
Tue Ton added 2 commits April 21, 2020 19:20
- 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants