-
Notifications
You must be signed in to change notification settings - Fork 671
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
chirontt
wants to merge
9
commits into
gitblit-org:master
Choose a base branch
from
chirontt:gradle_conversion
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Gradle conversion #1314
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
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:
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:
would run the tests in src/serverTest/java folder via the GitBlitSuite test suite class, while the command:
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: