Posts Tagged ‘Build Management’

This is not the tool itself but the Gradle build GUI showing the tool itself.  Because the gradle build lifecycle is tdd based we get that as a foundation and I am just integrating some tools on top of the gradle android plugin such as code analysis tools robolectric, etc.

How much dev time are we saving?  The typical round trip of compiling the parent project, dx-ing, and installing and compiling the instrumented test and than dx-ing it and installing it can be anywhere from a minute for small project to several minutes per a large project and in the TDD process you would  be doing that perhaps a 100 times on typical coding day. That is over 1 to 2 hours in development time savings. That is not counting the savings of not having to fully mock test an android project and thus it is a substantial amount of development time saved.

To those firms in Chicago looking for Android Developers, I am only 43 minutes from downtown Chicago.

Enhanced by Zemanta

If you visit most android developer forums you find android developers from all areas of development. Some are web developers, some are MS.NET developers, some are java developers, some are JavaEE developers, some are CS students, etc.

Among those many groups there is not a common thread of using a continuous integration build server.  With one exception, if you count the IDE as incremental compiler as the continuous integration server. and why not its small enough to run on a laptop with the android emulator and still have room to run a dev environment dash-board using jetty.

Thus, my philosophy is integrate pmd, checkstyle, classycle, jdepend, javaNCSS, doxygen for native c, jGrouseDoc for javadocs of javascript in assets, and cppcheck reports into one small build system package that is easy to set-up and use along with your favorite IDE for android development.

With some ease of usability in that you should only have four or less files to change per project amounting to less than 6 properties to change per project. Maybe even go further over this next week-end and code a groovy installer that auto-installs everything in a new project with no-mess no-fuss.

Not set as default incremental builder as we want developers to feel that they can run that one target to compile and doc the whole project whenever they want or they can set the whole thing up in their IDE as an incremental builder.

Not all polished all at once but I will get rest of the tools integrated this week and a full common look/feel to the reports that are generated so I can use it my own projects and see where rest of the improvements need to be made.  I did find how to do customizable headers and footers using CSS without having to change or insert new html  elements in the html generated in each report.

If you have not downloaded the corrected add-proguard-release.xml that was corrected from the android dev blog Sept 21st post than visit my github account link at the bottom of this blog and click on AndCooperANT and download that file at the project root folder. Of course no one paid attention to my bug submission yet, maybe I needed to have a bug title that stated Sept21st Dev post wrong?

But, oh well..towards weekend two more alpha and usable releases of AndCooperAnt with me starting to upload zipped copies to github for you to download.

Enhanced by Zemanta

So I am on the last part of the AndCooperANT journey of adding Android NDK support that set of android application build scripts. So I am using Eclipse 3.5 and Android NDK r4b and need to set up a sample project to test my build scripts.

Here is how I accomplish that so that I have an Eclipse CDT nature within an eclipse Android SDK application project that actually uses the NDK build system and also gets rid of that annoying CDT no gnu makefile at project with all target error…

1. Right click on project root and New Project->Other->C++->Convert to C++

2. check C++ project choose Makefile and choose other toolchain

3. Say yes to open C++ perspective.

4. In C++ perspective create new folders of libs, obj, and jni

5. In C++ perspective under C++ General set output folders under paths to libs and obj and set source folder to jni.

6. In C++ perspective right click project root and select properties than choose builders:

un-check everything on the CDT builder

create a new builder type of program

If using Linux than its

First box ndk-build script location

Second box is project location

Third box is these args: -C ${build_project}

If using Windows the settings for that builder wil be the ones this blog post covers:

Now what you should see is after that go to Eclipse project menu and choose Build Project and you should this in your console:

Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: /home/fredgrott/my35ws_github/AndCooperANTNDK/jni/
make: Entering directory `/home/fredgrott/my35ws_github/AndCooperANTNDK’
make: Leaving directory `/home/fredgrott/my35ws_github/AndCooperANTNDK’
/home/fredgrott/opt/android/android-ndk-r4b/build/core/ *** Android NDK: Aborting…    .  Stop.

Android NDK: Your APP_BUILD_SCRIPT points to an unknown file: /home/fredgrott/my35ws_github/AndCooperANTNDK/jni/    make: Entering directory `/home/fredgrott/my35ws_github/AndCooperANTNDK’make: Leaving directory `/home/fredgrott/my35ws_github/AndCooperANTNDK’/home/fredgrott/opt/android/android-ndk-r4b/build/core/ *** Android NDK: Aborting…    .  Stop.

Now click on the problems tab in Eclipse and you should see no pesky CDT no makefile with all target error in that at all in fact you should see an error count of exactly zero.

Enhanced by Zemanta

Android App Build number

Posted: February 1, 2010 in Android
Tags: , ,

Okay, detiails tonight as far as what ant tasks details to use. But here are the steps:

1. use xpath to read in Andorid.manifest vaules

2 Use propertyfile task to set new build number in a property file

3 read that value and use ReplaceRegEx to change it in the andorid.manifest.

If you want you can eliminate step 2 as you would still be using the xpath values to update your api doc to app version etc.

Reblog this post [with Zemanta]

Now I have an integration decision with AndCooper Android Java Application ANT based build tool. With the webview web code suport in the build tool my diea was at some point to swtitch to Goolge GWT compiler support and keep the non GWT  web tooling support there for those who wil not use Google GWT. The key question is do I make a separate project just for GWT and feed it in or a new set of directories and ANt script code to support GWT JS  generation in the main Android project.

Seems to me that is should be part of the overall Android Project structure and plus if I were say secretly working on a an Android application using Motorola CLiQ-Motorola Blur APIs and the Google Maps APIs it would seem that the Google GWT tooling would be an ideal component in that development work-flow.

Reblog this post [with Zemanta]

When working with new innovative technologies you often have to take apart old tools and gleu them back in new ways to deal with new issues. If you have worked in JavaMe(j2ME) before you might have used something like JReleaseInfo to adjust and collate different manifest items to add to the manifest before you jar’d it such as the build number. However, in the Adnroid Java Application development world the manifest is no longer an *.Mf file but an XML file and thus the version number we have to change upon calling an ANT task such as build number is in that file.

I came up with:

<!-- Set build number -->
<condition property="">
<available file="build.number"/>
<equals arg1="${}" arg2="false"/>
<!-- We know build.number will set to 1 at <buildnumber/> call
<!-- Set var build.number.initial to build.number-1 -->

<equals arg1="${build.number}" arg2="1"/>
<!-- do not change AndrodManifest -->
<!--- okay do our repalce thing on AndoridManifest.xml -->
<property name="android.version.code" value="android:versionCode="/>
<property name="" value="android:versionName="/>
<replaceregexp file="androidManifest.xml"
<replaceregexp file="AndroidManifest.xml"

The way I came up with is:

1. check to see if build.number file exists, rember the build.number property is incremented from zero to 1 on first <buildnumber/> ant task call.

2. if false than cal <buildnumber/> task

3 if true than check to see if build.number is 1 and if so do not change AndroidManifest.xml and if not change to relfect new build number.

Reblog this post [with Zemanta]
Looking downriver from the Circle Line sightse...
Image via Wikipedia

First, thanks to my blog comment posters.  Yes, I can see why the desire to run AndCooper in Hudson Continuous Integration Server as its easy to set up and get started. While we do not have Hudson plugins for JSLint, Jdepend, Classycle, JCSC, DocCheck, and etc I can set up AndCooper specific items so we should be able to be able to run AndCooper right in Hudson almost right at the first AndCooper project releases.

For example, if I do a separate hudson-project-docs sub-directory and put html forms of all reports in there than  you can do post-build project links  with relative urls to those documents and thus stil have them in some form of dashboard like. Than as hudson plugins appear make a new andcooper-hudson-build.xml script that accounts for that set of features. That way we can use Hudson CI server right away. Which means I have to write a project sample config.xml for Hudson CI server integration.

Reblog this post [with Zemanta]

I am in the final phases of refactoring the reports look for AndCooper and the 0.1 release of AndCooper should be shortly. Looks like this before the final adjustments such as company logo, reports.css, and etc:
Plus, the reports should have a similar look to them to guide the developer as easy to read analysis reports. For example, adding summary explanations to some reports telling the viewer how to use the report.

I have choose to use a Continuous Integration Server as the platform to allow me to extend it beyond the first few versions to enable the easy on-the-fly-analysis. Basically, two modes. One mode allows the AndCoooper tool to run as a JavaBuilder in your IDE. The other mode allows you to run AndCooper in the Hudson Continuous Integration Server.

Reblog this post [with Zemanta]
Image representing Android as depicted in Crun...
Image via CrunchBase

While I adjust the code reportts to display information in the Android Application Development Context such as Classycle:

I better explain how AndCooper fits into things. AndCooper, although it can be used as a mini-continuous integration server, is not a CI server itself. Its just a build tool with a lot of features for the Android Application Development Process. If your CI server can use ANT than you should at ome point be able to integrate AndCooper with the CI server you use.

Reblog this post [with Zemanta]

I am now on the Report Writer code portion of AndCooper development. On one hand I could easily state that it should  be in groovy and a separate project. The problem is that fragments it in certain ways that I do not like.

If I choose to embedd the groovy code in the ANT script than I can re-use the code in the Android Mobile Build Continuous Integration Server project and everything is right there ready to test rather than run ant scripts from multiple projects. Which means I should set every report to xml and have that as an undelrying requriement that each code analysis/metric tool has to output reports in xml form so that I can transofrm that into an Android Developemnt specialized structure and format.

Reblog this post [with Zemanta]