CI for Tantalum

[kaiinkinen]

@vivainio, @paulirotta One of the promises of using Gradle for building Tantalum was that we would have a repeatable build, and also be able to have a CI for the project. Unfortunately I've found no OSS CI providers that would support JME/WTK-builds out-of-the-box, and now that the new WTK:s are only running on Windows, it's not very likely they will in the future either.

In order to make this happen, I've experimented with building TantalumCore in Standard Edition context, and including it as a library in the JME/Android builds. My branch 'java_se_build' is pushed, and seems to pass all tests, but I have yet to test it on a JME-device. However, since it is SE, I have now been able to enable CI for TantalumCore on this branch over here:

https://travis-ci.org/TantalumMobile/Tantalum

Currently Travis builds all branches, and also all pull requests, but the only builds that will actually succeed are the ones on the java_se-branch, as it's the only one that has the required config (a .travis.yml-file in the root). Also, since all the other builds depend on WTK, they will not work properly even if this config is added. There are some caveats, which I'm not sure we'll be able to fix, but let's see.

1) Only TantalumCore is built now. TantalumJME would require either stubbing of JME-classes, or some other magic to happen 2) Only the Tantalum-enabled branches will currently succeed in building. 3) We currently don't have a way to pull the artifacts of the CI-machine, so e.g. findbugs- or cobertura. reports would have to be generated locally. This should be fixable, though (http://about.travis-ci.org/blog/2012-12-18-travis-artifacts/)

Could you please have a look at this, and give me comments on it. We naturally still need to verify that everything works as expected, but I would hope we could merge this to master as soon as we've dealt with any issues we might have.

[vivainio]

So the end result will be that only JSE compatible stuff will have unit tests runnable in CI, right?

That's ok for me, please proceed. cc @tompaana

[kaiinkinen]

Yes, unless we have some form of stubs to compile the JME with the normal JDK rather than the WTK. Since the latest WTK:s only get released for windows we're really going to make life really hard for us if we're going to have a CI with everything installed. @paulirotta had the idea of including the required WTK-jars in the repository, in which case we have the actual classes available to compile against, but I'm not sure how that goes with all possible EULAs for these libs. Stubbing would mean we'd have to keep the stubs up to date somehow, but this does apply to the class files as well

[vivainio]

Let's take the lighter road of only CI-testing the JSE parts. We have big gaps in coverage in that area as well, so let's worry about 100% coverage once we have 70% coverage :)

[kaiinkinen]

For test coverage I agree with you. let's not set the bar up in the skies shen se varely know how to jump. I'm more worried about the fact that in the worst case we don't even catch compilation issues in the JME-project, since we can't build it without the stubs. I'm going to have a look to generate those automatically of our sources or something like that.

Another notice I forgot in the initial text. I could not find a good preprocessor for java, to replace antenna. Antenna son't run withot the WTK, so we need to do something about it to have the real prod build again. I'm thinking about forking antenna, but let's see if gradle+groovy would be faster for this. It would be just a few lines of perl ... :)

.kai.inkinen +49 176 3678 4021 kai.inkinen@gmail.com

Sent from my iPhone

16 maj 2013 kl. 17:12 skrev Ville Vainio notifications@github.com:

Let

— Reply to this email directly or view it on GitHub.

[vivainio]

How about using microemulator jars to ensure it builds for jme?

[kaiinkinen]

Seems to work fine, at least what comes to the build. Yesterday we tried the JSE-compiled (TantalumCore JSE, TantalumJME WTK) lib in our project, and it ran without any problems. Compiling TantalumJME with SE is one step further, but the end result should really be no different. I don't have a device to test this on now, but once I've verified it tomorrow, I'm merging this to master.

[paulirotta]

TantalumCore is now JSE. Merged into master, tested on a big app and device- no issues