Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Gradle Workflow and Migration Document
At the time of writing, we are using Apache Ant to build the Umple project. However, the goal is to gradually migrate to Gradle. For additional motivation and context, see the following discussion thread.
Files used and generated by Gradle are generally located in ./dist/gradle. A brief listing is as follows:
./dist/gradle/libs/- jar files and other library dependencies
./dist/gradle/src-gen/- Java files compiled from Umple
./dist/gradle/bin/- Java class files
./dist/gradle/test/- test files
./dist/gradle/test/bin/- test class files
./dist/gradle/reports/tests/test/index.html- jUnit test report summary
Gradle tasks should ideally be executed using the embedded wrapper scripts so that the correct gradle version is used:
gradlew.bat <TASK 1> ...
./gradlew <TASK 1> ...
Task cheat sheet
corebuild: builds only the core project jars
quickbuild: builds only the core umple jar with updated cruise.umple source, requires that template library classfiles have already been generated
fullbuild: builds the entire Umple project
testall: executes all unit generator, testbed and jUnit tests
Current state of affairs
Mono-script. Generally it is a good idea to outsource build logic to subprojects in Gradle; however, Umple has many intra-project dependencies for the submodules and as such all build logic is maintained in a single
build.gradlefile. That said, the subprojects closure is still used to artificially inject tasks into the subprojects (the subprojects only need to define properties such as the default Umple generation location).
- Not using the plugin. As is, the plugin has a number of issues when building Umple. Firstly, there are issues when specifying paths (even if they are the same as the default generation location specified in a Master.ump file) as well as in specifying language (even if it matches the intended type) - files will be generated incorrectly. Secondly, the plugin does not currently support switching to a different compiler jar. Thus, for simplicity and atomicity it was preferred to avoid the plugin for the build script. Should the above issues be resolved though, it would be a great idea to use the plugin instead.
- Build aliases. A convenient way to describe a sequence of tasks using a single task without generating artificial dependencies. See the definitions for the tasks mentioned above.
- Copying files. To have a better understanding of the files that the build is using, many directories are copied directly into the working directory for the Gradle build. If tests have local/relative file dependencies (which ideally should be resources), those need to be copied over as well.
Known issues / TODOs
jUnit tests. CPPCodeGenValidatorTest seems to have some issues with resolving the generated header files. The error messages (presumably from eclipse.cdt) are of form
Unresolved inclusion: <HEADER_FILE>. The tests have been excluded for now, but should be fixed and re-added.
- path and general build.gradle cleanup. There are currently some dist/gradle references sprinkled in various areas which should be removed. The intent is that we can modify the path and Gradle operations still work as before.
- java.lang.NoClassDefFoundError for first test run. the exception occurs when attempting to run tests in the same configuration or execution context as a first build. This leads to the natural concession of moving tests to a separate task. My suspicion is that the classpath for the tests needs to be made a closure somehow (deferred evaluation) so that it can get all the classfiles generated by the main Java source.
- sandbox. the sandbox project is only being compiled to Java at the moment, though it should probably be doing more (at least Java compilation).
- qaLandingPage. the qa landing page is being generated, but it's likely not showing anything useful at the moment
- testUnitGeneratorAndParser. the .ump files in these directories are being compiled, but it's not clear what the original ant scripts had intended to do (a lot of empty tasks with simple prints), and these were simply transcribed over
- testbed tests. The Rake task seems to be attempting to use the old jar location for testing. Also need to make sure that the other tests are doing the correct thing after compilation (no errors, but verify behaviour).
test: default test command to run jUnit tests
jar: default jar command to build the Umple compiler jar
updateLatestVersion: writes the latest version to build/umpleversion.last.txt
deploy: deploys latest jars to umpleonline and to libs
allUserManualAndExampleTests: compiles manual and other examples