Gradle and ShootOFF

phrack edited this page Feb 3, 2016 · 3 revisions

Due to bug fixes and performance improvements in recent versions, we suggest you always use the latest version of Gradle.

Tasks for contributors:

  • Create an Eclipse project: gradle eclipse. You should run this task periodically to ensure you have any new dependencies that have been added and that all dependencies are their current versions.
  • Build and test the project: gradle assemble.
  • Build, test, and package the project (no code signing): gradle fxJar. This places all of the data and code necessary to run ShootOFF in build/dist.
  • Run a task without running unit tests: gradle fxJar -x test. Adding -x test to the end of a gradle command is useful if you want a task to do its job without incurring the time penalty involved in running the unit test suite.

Tasks for collaborators:

Collaborators have the ability to push code directly to the canonical ShootOFF repository belonging to this wiki.

  • Create a zip release: gradle zipRelease. This does not include the ShootOFF-diagnostics tool in the zip created in build/dist. This is the task Travis-CI uses to create the nightlies. To update the version number, alter the contents of src/main/resources/version.properties.
  • Push a zip release: gradle pushZipRelease. This creates the zip release, automatically adds the latest version of the diagnostic tool, creates a draft GitHub release for the version, uploads the zip file, and updates version metadata on gh-pages.
  • Push a webstart release: gradle pushFxRelease. This essentially runs fxJar, updates the manifests in all of the dependency JARs, signs all JARs, creates the writable resources JAR, creates the JNLP file, and pushes all of these changes to gh-pages.
  • Do a full release: gradle release. This currently doesn't update the website or publish the GitHub release.

Compiling code outside of a cloned repo:

It is highly recommended that you work within a cloned version of our repository. We do not accept code changes via any mechanism but GitHub. If you are not working in a cloned repository you will end up really annoyed with yourself when you go to contribute your changes and have to do a bunch of extra work to get us to accept them.

The build script assumes it will be run from a cloned version of the repository because some tasks make changes to version metadata or release files within the repo (e.g. on the gh-pages branch). If you are building from, say, a zip snapshot of the code you will get errors related to the grgit plugin and will have to remove this code to proceed. We will not work around this issue for you because you should be contributing your changes to the community. This means you should always work on ShootOFF within a cloned repository.

Using the Gradle daemon:

If you have the Gradle daemon enabled, running tasks that require user input will result in the following error due to incomplete features in the daemon:

Cannot invoke method readLine() on null object

The tasks fxSignedJar and fxWebstartSignedJar require the user to input a password for the keystore containing the signing keys. The tasks pushZipRelease, pushFxRelease, and release require the user to input a GitHub account name and password that has collaborator rights to the ShootOFF repository. You can run these tasks with the --no-daemon switch to work around this issue. For example:

gradle pushZipRelease --no-daemon