Support building Tantalum through Gradle (1.4)

[kaiinkinen]

Having only an 'IDE-enabled' build, we're restricting the number of potential people who might be interested in using the library. By providing a structured almost-out-of-the-box build system, people are able to build the library with all the examples and unit tests to verify that the build is sane. Using e.g. gradle is also almost mandatory for setting up some form of CI system for the library, as one cannot depend on an interactive build in the automated process. Gradle has quite nice support in the various IDEs (Netbeans, IDEA, eclipse?), so it should also allow for easier setup of the dev environment.

In order for the build to run, one needs to:

• Install the WTK toolkit from Oracle
• Define the env variable JAVA_ME_HOME to point to the wtk home
• Install standard Java SDK, either 1.6 or 1.7
• Install Gradle. I've tested it with Gradle-1.4, add the path to it
• Trigger the build through 'gradle build'

I've tested the vanilla setup to work on on OS X (Mountain Lion, Java 1.6, WTK 3.0) and Windows 8 (JDK 1.7.0_17, WTK 3.2), so running it from Linux, given that WTK is available, should be feasible. The only caveat is that the user needs to create a symlink on OS X for this to work ('ln -s /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/{classes,rt}.jar'). I've documented this case in the build files. The default setup works as it is on Windows, since I'm assuming this is where the most of the audience is, anyway.

Other changes in the pull request:

• There's a J2SE-test project, which is used to run unit tests against the library. The number of tests is still quite small, but using J2SE for testing we have a much wider array of tools at our disposal. E.g. unit test coverage is currently already enabled on the build.
• Various quality tools and metrics have been enabled for the build. Currently the library code is analyzed with pmd, findbugs and jdepend. The thresholds for the metrics have been turned off, so builds will not fail, but it might make sense to configure some minimum standards, if accepting changes from externals.
• Not all of the example projects are being built at the moment, as they would introduce dependencies to LWUIT and the Nokia S40 SDK. Having those be a default part of the library code is probably a bit too heavy-weight.

Some glitches still need to be fixed 1) Static tests run twice. Once for the original sources, once for the preprocessed release sources. 2) IDE-setup is not fully automatic 3) General build-file cleanup. Now there are a few custom things in them, which should be standardised if possible

Please review and merge, if you find this acceptable. Any feedback would be welcome. .kai

[paulirotta]

Excellent, thanks Kai! Will go through this and looking forward to it.

[vivainio]

Looks interesting, have to read up on Gradle

[vivainio]

Since this has to be done anyway, let's rather it do it sooner than later.

+1 on merging this in ASAP.

[vivainio]

Also, what is the WTK used for exactly? If we run unit tests in J2SE, will WTK be used just to ensure it compiles and is "legal" JME code

[kaiinkinen]

The actual application is being built using WTK+JME, so the app in itself will be valid JME. Since JME is not a true subset of JSE, some magic is required to run the tests properly. However, all of this magic is restricted to the single J2SE project, so by turning that one off, we should have more or less a standard JME-build in place.

[vivainio]

Fair enough. Where does this J2SE <=> JME magic happen? Link to changeset?

[kaiinkinen]

Not changeset, but file :) The magic is to execute the unit tests in the J2SE context, and include the JME-compiled classes. Since there are some differences in the environments, the j2se test runners needs the correct bootclasspath to be set up during execution.

The bootclasspath is configured in the main gradle build file (./build.gradle) and called 'bootclasspath'. I'm referring to Java framework classes, not Tantalum. I also define a jreBootClasspath, since I will need to make sure that these are included in the correct order. I.e. JRE-classes need to be found before JME-classes, but we should resort to the JME-classes when necessary. The test execution part is handled by Gradle, but in order to have the correct env, I set up the correct bootclasspath for the test execution in ./TantalumJ2SETests/build.gradle like this: /**

• The ordering of the elements is significant. The JRE-classes must come before
• the midp and cldc classes, or the J2SE unit tests will fail. */ project.tasks['test'].bootstrapClasspath = configurations.jreBootClasspath + configurations.testBootClasspath

This sets the environment for the test execution, and maintains the order correctly. Please ask more questions, as spreading the knowledge means someone else can deal with potential problems in the future, besides me.

[vivainio]

So after installation and succesfull "gradle build", should "gradle test" run the unit tests? I don't get any "test case" output from running it, but rather:

...
:Examples:GeocodeExample:compileTestJava UP-TO-DATE
:Examples:GeocodeExample:processTestResources UP-TO-DATE
:Examples:GeocodeExample:testClasses UP-TO-DATE
:Examples:GeocodeExample:test UP-TO-DATE

BUILD SUCCESSFUL

Total time: 16.368 secs

v6vainio@4FIL61176 /c/p/Tantalum (kaiinkinen-gradle_build)
$

[vivainio]

Copied part of the instructions to https://github.com/TantalumMobile/Tantalum/wiki/Development-environment-setup

[vivainio]

I'm merging this in, because we need to get up to speed early next week. If something breaks, it must break now.

[kaiinkinen]

One final comment to this thread, since it's the best place to keep the information. The current setup assumes that the J2SEUnitTests are all passing. In other cases the build will fail. I.e. in order to get a successful build all the existing tests need to pass. The test report can be found in the file: TantalumJ2SEUnitTests/build/reports/tests/index.html

The other report files are written in TantalumLibrary/build/reports/... Findbugs and jdepend reports are meant to be mostly consumed by the CI, so they're only written in xml-format. We could change that if we want to. We can configure the build to fail also for these failures. This will require us to really put our mind into a set of rules that make sense on a global level. But, let's get the build going first, and then fix this as soon as we can.

Cobertura also writes a report under TantalumLibrary/build/reports/cobertura. This report is based only on the J2SE tests, so the coverage is currently quite low. Let's work on improving it.

.kai

[vivainio]

@kaiinkinen Can you add this information to the wiki https://github.com/TantalumMobile/Tantalum/wiki/Development-environment-setup

I can see the reports, but indeed coverage seems to be at zero.