Eclipse Log4j.properties trick

If you are moving towards using agile in developing ant build scripts and need to use Log4j to log build errors(see Log4nt) than you run into the problem of how to enable the eclipse AntClassLoader to pick up the log4j.properties file.  There is a trick to it.

Take and make a global log4j.properties file for all your projects and save it. Now zip that file. Now rename the zipped file to a jar. Now in Eclipse ant preferences run-time add the external jar into the same place as where the ant plugin is showing all the lib entries. Now when you run ant builds that use Log4j.properties and Log4j it will execute correctly and pick up the log4j.properties file to have Eclipse AntClassLoader recognize the log4 appender.

Can I shoot the M’Fers?

Yes, I really am saying that …Can I shoot you M’Fers? Do a search on java techniques and android. For example, search for aspectj and android. Now, notice how many howtos state that in an ant build you run acj or iacj after the android javac compile step. Now pick up the damn gun and shoot your M’fer ass! Why?

Because lack of knowledge of advance java techniques and java tools is a sign that you should not claim that you are a java developer. Okay, for those that do not know you set the iacj to run in the javac task or just use ant4eclipse ant task adapter to make the process easier as there is no need to run two effing compiles on the main project or a test project when using aspectj in an android project!

And really if you are already using an ant build or the IDE builder running an ant build than by god dammit the ecj is an incremental builder which can sped up an android build especially if you are using instrumental testing. Also you can set more verbose feedback options using ecj instead of the javac that comes with the Oracle JDK.

Obviously, the other component of Agile development in systems that have broken or very decoupled anti-patterns such as android is in fact Aspect Oriented Programming due to the fact that you can separate concerns, etc. Specifically TDD and BDD only affect the agility or speed of development in the test process itself not the full development process itself. Dependency Injection also affects agility of the full development process rather than just testing if you apply it to the full project rather than just testing.

Unfortunately, most firms get stuck with java developers who happen to be android developers that replace java expertise and agile expertise with knowing only  the TDD/BDD buzz words.Please can I shoot those MF’ers? Yes, there is even on the market right now one Android Developer Testing Book that makes all these mistakes. Yes, really one publisher got their head up the ass and actually gave someone money to produce such  trash.

Agile Android Dev with a Vengence

So now I am at this step of integrating/tying everything together in one dashboard. The codeqa reports, the javadoc, the unit tests, emma reports, etc.And I still get the heavy impression that design firms do not know how to do agile android development. Everything from hiring those who do not know how to develop java applications on mobile(they are puzzled over my talks of modified singleton patterns for mobile) to repeating errors in hiring in that it worked so well for finding that outside design firm that we now have to re-start the app dev process and clean up the mess that we will rather repeat the process to find someone who is a conformists not willing to rock the boat as opposed to someone who has to change dev culture to implement agile.

Some of these are well-known firms in Chicago, for example one sounds like Voccal Interactive. Some of them are Chicago start-up incubators that should certainly know better by this period in time. You cannot just wave a magic wand and expect that piling up of technical debt to be paid by a one-hour consultation or even a one day one.

Hopefully, by completing my tool and talking about its use I can persuade more firms to use best practices in android agile development rather than pay lip service.

How to make AndroidMock work with adt14 onwards

I have put some directions on how to get Androidmock working with adt14 on-wards with eclipse here. Not too hard, you have to change two folder locations to bin/classes in your annotation processor settings in eclipse and make sure if using Android Project Libraries to add the source(bin/classes) as an extra source input in the sources tab. You should have no changes with the sdk supplied build.xml except making sure that AndroidMockRuntime.jar is in the test project bin/classes folder.

Android build.xml corrections

With every android build.xml comes a little pain. It still seems that they do not test the android application build.xml over at Google given the errors I am finding. Your first correction will be to change the path jar.libs.ref to what is in this gist. It prevents the path from bombing out due to the project.libraries not existing if you do not have project.libraries, just imagine that concept!