Use gradlew -h to see the various options available for running gradle commands.
By default, gradle outputs information related to the progress in building and which tasks it considers as up to date or skipped. If you don’t want to see this, or any other output about progress of the build, you’ll want to add the -q flag:
gradlew -q projects
Set up an alias if you’re a command-line kind of person who can’t abide output to the screen.
If working offline, you will want to use the --offline option to prevent it from contacting the artifact server (You won’t have success if you do this for your first build.)
Or you can toggle offline mode in IntelliJ, as shown in the following screen shot:
If doing development in a single module, there is a command available to you that can be sort of a one-stop shopping experience:
/path/to/gradlew deployModule
This will build the jar files, and the .module file and then copy it to the build/deploy/modules directory, which will cause Tomcat to refresh.
A package of proteomics binaries is available on Artifactory for your platform. When you build from source, they are automatically downloaded and are deposited in the build/deploy/bin directory of your local installation. Once downloaded, they won't be fetched again unless you remove the build/deploy/bin directory, such as by doing a cleanBuild.
If you are not working with the MS2 module and do not need these binaries, you may not want to spend the time to download them. To skip the downloading of these binaries you can set the gradle property "excludeProteomicsBinaries" when building:
/path/to/gradlew deployApp -PexcludeProteomicsBinaries
For convenience, you can also include the excludeProteomicsBinaries property in your <user>/.gradle/gradle.properties file.
If you exclude them and later wish to restore these binaries, first do a 'cleanBuild', then when you next 'deployApp' (without using the excludeProteomicsBinaries property on the command line or in your gradle.properties file) they will be downloaded.
Prebuilt binaries are available for manual download and deployment to your pipeline tools directory:
Build tasks are available at a fairly granular level, which allows you to use just the tasks you need for your particular development process. The targeting is done by providing the Gradle path (Gradle paths use colons as separators instead of slashes in either direction) to the project as part of the target name. For example, to deploy just the wiki module, you would do the following from the root of the LabKey enlistment:
./gradlew :server:modules:wiki:deployModule
Note that Gradle requires only unique prefixes in the path elements, so you could achieve the same results with less typing as follows:
./gradlew :se:m:w:depl
And when you mistype a target name it will suggest possible targets nearby. For example, if you type
gradlew pick_pg
Gradle responds with:
* What went wrong:
Task 'pick_pg' not found in project ':server'. Some candidates are: 'pickPg'.
Gradle provides many helpful tasks to advertise the capabilities and settings within the build system. Start with this and see where it leads you
gradlew tasks
Other very useful tasks for troubleshooting are
Placing the gradlew script in your path is not ideal in an environment where different directories/branches may use different versions of gradle (as you will invariably do if you develop on trunk and release branches). Instead, you can:
There are various things you can do to improve performance:
org.gradle.jvmargs=-Xmx4g
If you don't need the absolute latest code, and would be happy with the latest binary distribution, do the following to avoid the compilation steps altogether.