Collectible Card Game Headquarters

drdev wrote:What's the process for signing it?

I'll have to look that up again, but it involves a little extra work in the pom.xml for the android build (I think).

drdev wrote:Do you have another recommendation?

Nope! Just wanted to make sure I could fit my high res card images on my phone.

Looks like it's choking on loading textures and can't access the javax.xml package used by CardPreferences. Could you look into that if you manage to get the res/ folder on your device? Otherwise I should have time later to investigate. Also if you can figure out the signing thing, that would be cool.

Note that I added the method Forge.debugPrint to aid in printing messages to LogCat in case that helps with debugging.

Lastly, I'm finding that I have to manually run mvn clean install on any module that's modified, otherwise the changes aren't pulled in when I build forge-gui-android. Is there a way to make a Maven build that first rebuilds the dependencies that have any changes?

drdev wrote:Lastly, I'm finding that I have to manually run mvn clean install on any module that's modified, otherwise the changes aren't pulled in when I build forge-gui-android. Is there a way to make a Maven build that first rebuilds the dependencies that have any changes?

I've got stuff to do before I can have a look at the rest of the stuff, but for this one, try running:

Code: Select all

-U -B clean -P android install

Also, are the package-info.java files necessary for anything? I can get the whole thing to compile a .apk without them, but with them I get conflicts.

I don't know what that file is for. I'll have to try it out later.

EDIT: The goals you specified built and ran without issue, but didn't pull in changes made to forge-gui-mobile. Thoughts?

EDIT2: So I'm addressing the xml reference issue by switching all XML parsing in forge-gui to use XmlPullParser instead, which works on Android and Desktop. Using javax.xml.stream is not an option, or at least not an option without some serious hacking and ignoring the recommendations I read. So bottom line don't worry about that reference issue.

EDIT: All issues with running resolved, as I can now run the app successfully. It'd just be a matter of whether you add support for signing at this point. Thanks.

I'll work on adding support for signing and I'll also clean up some of the pom.xml tomorrow. Signing is relatively simple to add, but I do want to make sure I get it right and I'd like to wait til after version 1.5.18 is released so there's time to fix things if they don't work right.

For those building signed .apk files, you'll need to follow the instructions here and obtain the following:

• Keystore
• Alias
• Keypass
• Storepass

As for resolving the dependencies so that "mvn install" won't have to be run on other modules, that's going to take a bit of work to get running, I think. The problem is that making the Android module a real module makes the desktop version of Forge try to build an Android version when running the desktop build process. This is a problem for those without the SDK and other tools installed. I'll have to figure out how to separate the two.

I got sucked into Path of Exile (which I almost call Path to Exile every time I say/type it) for a little while there, so that's why I've not been around to work on this.

Alright, I've just added the full build process for the Android version of the game including signing.

To create a debug build of the game, run:

Code: Select all

mvn -U -B clean -P android-debug install

To create a full release build of the game, run:

Code: Select all

mvn -U -B clean -P android-release-build,android-release-sign install -Dsign.keystore=<Path to Keystore> -Dsign.alias=<Alias> -Dsign.storepass=<Store Password> -Dsign.keypass=<Key Password>

If you're running Maven from within Eclipse, just omit the starting "mvn".

To avoid having the passwords in your command line, you can add the following to your Maven's settings.xml:

Code: Select all

<profiles>
    <profile>
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <sign.keystore>pathtokeystorefile</sign.keystore>
            <sign.alias>aliasname</sign.alias>
            <sign.keypass>somepassword</sign.keypass>
            <sign.storepass>somotherpassword</sign.storepass>
        </properties>
    </profile>
</profiles>

Then run:

Code: Select all

mvn -U -B clean -P android-release-build,android-release-sign install

Does the debug build include the res/ directory? And can this be hooked up to automatically publish the full release build to a folder in http://cardforge.org/android/ which I have ftp access to?

Also, what's the password for signing and where is this keystore located?

drdev wrote:Does the debug build include the res/ directory? And can this be hooked up to automatically publish the full release build to a folder in http://cardforge.org/android/ which I have ftp access to?

Also, what's the password for signing and where is this keystore located?

You'll have to generate your own key/store by following the instructions here.

The debug build does not contain the res directory, but I can set it up to do that. I'll also look at getting it to publish the build. I've never done that before, so it may take a little time.

The release currently creates a .zip file that contains the .apk, changelog, license, readme, and .zip file containing the res directory. It also has all of these files in an uncompressed folder. I'm assuming you'd want to upload the .apk and res folder separately?

No, please do not set up the debug build to contain the res/ folder. I'd rather be able to build and deply those .apk files more quickly for testing. I was just asking to make sure you didn't.

I want to upload them separately if that makes sense, although however is easiest is fine for now. To be clear, it sounds like I still need to add logic to download the res/ folder on startup, correct? Or is it possible to make an Android install script that handles this easily for users?

drdev wrote:No, please do not set up the debug build to contain the res/ folder. I'd rather be able to build and deply those .apk files more quickly for testing. I was just asking to make sure you didn't.

I want to upload them separately if that makes sense, although however is easiest is fine for now. To be clear, it sounds like I still need to add logic to download the res/ folder on startup, correct? Or is it possible to make an Android install script that handles this easily for users?

There's not really an easy way to build an install script that I know of, however I'll poke around and see what I can find. Downloading the res/ folder on startup might make the most sense, though. That way the user only has to download the .apk and then it'll take care of the rest on its own.

I'll do that then. Thanks. I'd still want the publish maven script to handle packaging and uploading the .apk and res/ folder though.

Any preference for folder structure on the server? And would you like the res folder to be compressed? It seems like it'd be faster to upload/download a single file, then decompress it to the correct spot.

Edit: I've got it all running. Once you let me know how you'd like it organized, I can set up the directory structure for you and then it's all good to go!

Edit 2: Here's what I've got so far. It puts each build into a timestamped folder so it's easy to figure out which is the latest.

Yes, I'd like the res folder compressed if you haven't already. Just make sure it's a file compression type that's easily decompressed using Java.

Alright, then it's all good to go if you like the folder structure on the server. The res folder is a standard zip file, just like the cards folder.

Run:

Code: Select all

mvn -U -B clean -P android-release-build,android-release-sign,android-release-upload install -Dsign.keystore=<Path to Keystore> -Dsign.alias=<Alias> -Dsign.storepass=<Store Password> -Dsign.keypass=<Key Password> -Dcardforge.user=<ftp user> -Dcardforge.pass=<ftp password>


That builds, signs, and uploads everything in one go.

It'll all be put on the cardforge server under http://cardforge.org/releases/releases/forge/forge-gui-android/.

I haven't managed to get it to build the other modules yet without causing problems with the desktop builds.

Looks like I was not as set up as I thought. I've been trying to figure out how to switch dependencies and change subprojects in maven. I have read through all of this thread and it's not clicking for me, so I'd appreciate some assistance.

Edit: Ok, finally I've got it working for both the desktop and Android versions after a lot of trial and error. I am not certain why this is the case but pulling the Maven project in to Eclipse directly causes the project and dependencies to have a weird structure. If anyone else has a similar issue I would recommend cloning the SVN repository via the command line and importing each submodule manually through Maven in Eclipse.