Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jenkins build #17

Merged
merged 4 commits into from
May 28, 2014
Merged

Conversation

datalogics-bhaugen
Copy link
Contributor

Required this pull request in readium-sdk, to be in the readium-sdk submodule in this repo but, overall this adds :

  • a generated build.xml for building through jenkins

There is a jenkins plugin that will generate this script but I was not sure if/how it could be modified after it was generated so I opted to just generate it now and get it checked into the repo to avoid that problem.

Running ant debug with this build.xml will actually find the dependency on readium-sdk and run off and compile that as well. The project name in the build.xml needs to be updated but that can be done at anytime.

@rkwright, this can wait until the develop branch is ready to be modified again.

"android update project --path ." will generate a
build.xml that can be used to build the Launcher
from the command line. It even picks up the dependencies
and builds those first, so this will go off and
build the Readium SDK first and then build the Launcher.
This makes it so the .apk that comes out is named
SDKLauncher-Android instead of MainActivity.
summary of changes from ‘git submodule summary’

* readium-sdk f76c31a...8fdbfd7 (13):
  > Merge pull request readium#55 from datalogics-bhaugen/jenkins-build-android
  > Fixed issue related to JNI static jclass pointer initialisation (ERROR "accessed stale local reference"), observable in Android ICS+ (>= Ice Cream Sandwich 4.0) because of the new garbage collector which moves memory allocations. This was needed on my KitKat device despite targetSDKVersion set to 11 in project properties (which should normally ensure JNI compatibility mode with post-4.0 garbage collection ... I'm not sure why the compatibility mode did not kick-in though, I observed this bug in both Dalvik and ART runtimes). Future uses of the jni::Class wrapper (defined in jni_class.h) should be double-checked, to ensure that the initialisation macro from helpers.h is used to create the correct persistent jclass memory pointer! (behind the scenes: (jclass)env->NewGlobalRef(tmpPtr)). Perhaps INIT_CLASS_RETVAL() should be called directly inside the jni::Class constructor that takes a string parameter (the class qualified name, used to lookup via end->FindClass()). This would make the API transparent to the JNI garbage collection subtleties?
  > BUG 74: Added some more logging to help verify paths
  > Remove unneeded file
  > added flow froperties to the split properties lookup table
  > Updates to RDSpineItem to bring in line with the version used by the OS X launcher.
  > Update copyright strings for RDServices classes.
  > Merge branch 'develop' into feature/rdservices-apple
  > Bring over another change from SDKLauncher-iOS develop (from April 14).
  > Small change to previous commit.
  > Bring over recent additions from SDKLauncher-iOS develop, which isn't using RDServices from readium-sdk yet.
  > Merge branch 'develop' into feature/rdservices-apple
  > Initial commit of RDServices classes for Apple platform.
datalogics-bhaugen added a commit that referenced this pull request May 28, 2014
@datalogics-bhaugen datalogics-bhaugen merged commit 12e768b into readium:develop May 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant