Posts Tagged ‘XML’

I do not  think any of us are Apache ANT experts, but here is the PMD task that I am using with an Android setup:

<pmd  >

              <ruleset>rulesets/andcooper.xml</ruleset>

				          <formatter type="xml" toFile="${inreports-folder}/${project.name}.${DSTAMP}.${TSTAMP}.pmd.xml"/>
		        	<auxclasspath>
<pathelement location="${android-jar}"/>

		        	                <fileset dir="${project.home}/libs">
		        	                    <include name="*.jar" />
		        	                </fileset>
		        	            </auxclasspath>
			<classpath refid="reporttools.classpath" />
		        	<fileset dir="${source-location}" includes="**/*.java" />

				      </pmd>
		    	<xslt basedir="${inreports-folder}" destdir="${outreports-folder}"
		    	    	         includes="${project.name}.${DSTAMP}.${TSTAMP}.pmd.xml"
		    	    	         style="${pmd.home}/andcooper.pmd.xsl">
<param name="rulesets" expression="${rulesets}"/>
<param name="project" expression="${project}"/>
<param name="today" expression="${today}"/>
                  </xslt>

Of course you will have to define your own ANT properties. It is assumed that the PMD ruleset is in the PMD.jar and thus you will include again with classpath refid
so that the PMD task can find the ruleset. Also notice to use the PMD xslt provided stylesheet you should provide two xslt parameters to the xslt task

Reblog this post [with Zemanta]


Weird title, huh? Okay, let me shed some light.  I have worked in the Enterprise and Mobile areas in startups. Although, searching for better code methods does not solve the management problems you still search for them because its what you can control to solve the problems. In Enterprise we have Injection and IoC, Object Relational Mapping(ORM), Object Serialization via XML, and etc.

Now, picutre this. You start with a non AOP injection/inversion container framework such as Guicev2. Remmber, the main benefit of using IoC frameworks is no longer any factory code. It is not that the factory model is wrong in separating the client class from the implementation class its that we have a hidden dependencies that miss testing. Now, that works  on small J2ME MIDP 1.0 application, might even work on a small J2ME MIDP  2.0 application But, that will not work on the large Andorid applicatiosn we wnt to have maintainable and manageable within the code development process.

Thus, that fixes the factory model problems. we have similar prolem on the SQL-ORM side in tha tif you use an adequate ORM say AndroSQL, than you have java object classes that match how you use that SQL data in an object oriented way thus reducing the code requried to implement the data relationships and stil avoid the factory model call class problem of having depnencies hidden and thus hidden from testing and etc.

Than of course we come to the UI code. If we use a UI widget framework that autot-inspects back-end code at runtime to do some of the setup than we redcue UI code. Metawidget framework popuplates the UI at runtime and has some Andorid UI widgets.

We do not have suffer through brittle J2me?java code any longer. You see the same move away form the Vendor-Old blood approach into such thngs as Spring, Hibernate, Wicket, and etc. The Android OEMs that understand how much development time can be saved and etc in adopting IoC, ORM, and UI widgets in Androdi Application development wil disrupt th eothers both in the time they can push out handsets and push out new innovative Android Applications that integrate with Mobile Operator Services.

Those OEMs that decide to do  just J2me the Andoroid way will be left behind. This is the other motivation behind the AndCooper Android Application  Build Tool as to teach thse new techniques we haev to see how brittle it is done the old way and than the new way through code anaylsis, testing, and than a set of wiki notes per projectto follow along with and take notes with.

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]