Posts Tagged ‘Build automation’

There is now a download of the AndCooperANT Android Java Application build tool. Its still alpha with the most tested area being the build.xml script. Of course if you find errors report them in the issues section.

Some of the docs are still in flux at the moment let me know in an issue/bug report of the instructions are unclear.

Enhanced by Zemanta
Advertisements

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

One of the obstacles lately that I have run into is how do you describe an Android Agile Enabler Build System such as AndCooper. Usually, i am communicating with managerial people that already have some exposure to such code review items as unit/mock test code coverage, code comment coverage, code correctness measurements, and etc. Thus, you would think in explaining that currently only have of that is supported in that build systems have yet to be built supporting the other half I get this blankness in the conversation on their part and that is after I explain that because unit/mock testing and code coverage testing occurs on device it requires a more integrated build system than just throwing together a few lines of ANT XML scripting.

In other words usually in most code review processes focus around a continuous build process producing code analysis reports used in the code review process. While EMMA reports can be generated off EMMA data produced, the unit/mock test data is not in report form yet as its in either the IDE stdout/console, or the device/emulator. Now you could make the project manager have to know how to start up an emulator and run the build to get the data manually but most managers are busy and thus it should be automated. And quite frankly automating the process so that the developer can use that feedback daily catches errors before they hit the code review process thus saving the whole team development time.

It is quite simple. If you put the right infrastructure in place so that the developer as part of his or her hourly activity can run an automated code review process to use as feedback than there are less items that require correction after the project manager end of day code review. It is not that I do not like explaining it, it is that I am somewhat tired of running into non-caring managers as it has an immediate value to both the costs and that impact on costs towards profits something most project mangers should care about.

Of course it would be nice to encounter a manger that ‘gets it’. Onward, the next few days refactoring the Android Build Life Cycle than the final sequences of testing tasks and than a full preview release.

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:
andcooper3

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]

So how do we detect the Android SDK version so that the AndCoooper build tool can be used if the SDK is updated? Goolge/OHA through the SDK provide us with a ANT target property located in default.properties that is generated by the SDK. Normally, ANT does not support conidiotnal logic to hook into this but if you use a differnet optional task library such as ANTXtras you can integrate with this target property to determine not only the SDK version by adjust the classpaths for the tools and apis such as:

<!-- SDK Version setup -->
		<emit message="target: ${target}">
		<domatch property="target">
			<equals value="android-6">
<property name="android.sdk.version" value="android-3.0">
			</property>
			<equals value="android-5">
<property name="android.sdk.version" value="android-2.5">
			</property>
			<equals value="android-4">
<property name="android.sdk.version" value="android-2.0">
			</property>
			<equals value="android-3">
<property name="android.sdk.version" value="android-1.5">
			</property>
			<equals value="android-2">
<property name="android.sdk.version" value="android-1.1">
			</property>
			<!-- 1.0 is no longer supported in SDKs and thus not needed -->
		</equals>
		<emit message="android.sdk.version: ${android.sdk.version}">
		<!-- Set aidl framework location based on android.sdk.version value  -->
<property name="android.aild" value="${sdk.location}/platforms/${android.sdk.version}/framework.aidl">
<property name="android.jar" value="${sdk.location}/platforms/${android.sdk.version}/android.jar">
        <domatch property="mapapi">
		    <equals value="yes">
				<domatch property="oem">
					<equals value="no">
<path id="sdk.apis.classpath">
<pathelement path="${sdk.location}/platforms/${android.sdk.version}/android.jar">
<pathelement path="${sdk.location}/add-ons/google_apis-3/lib/maps.jar">
						</pathelement>
<property name="android.target.classpath" value="sdk.apis.classpath">
					</property>
					<equals value="yes">
<path id="sdk.apis.classpath">
<pathelement path="${sdk.location}/platforms/${android.sdk.version}/android.jar">
<pathelement path="${sdk.location}/add-ons/google_apis-3/lib/maps.jar">
<pathelement path="${sdk.location}/add-ons/${oem-vend-add-name}/${oem-vend-add-jarname}.jar">
						</pathelement>
<property name="android.target.classpath" value="sdk.apis.classpath">
					</property>
				</pathelement>
			</pathelement>
			<equals value="no">
				<domatch property="oem">
					<equals value="no">
<path id="sdk.apis.classpath">
<pathelement path="${sdk.location}/platforms/${android.sdk.version}/android.jar">
							</pathelement>
<property name="android.target.classpath" value="sdk.apis.classpath">

						</property>
					    <equals value="yes">
<path id="sdk.apis.classpath">
<pathelement path="${sdk.location}/platforms/${android.sdk.version/android.jar">
<pathelement path="${sdk.location}/add-ons/${oem-vend-add-name}/${oem-vend-add-jarname}.jar">
					    	</pathelement>
<property name="android.target.classpath" value="sdk.apis.classpath">

						</property>

					</pathelement>

				</path>

			</equals>
			<emit message="android.target.classpath set to:${android.target.classpath}">
<property name="sdk-location" value="${sdk.location}">

I also included some alpha code to integrate with OEM add-ons.

Reblog this post [with Zemanta]