02:39:30 pm on August 6, 2012 |
The new 0.4.2 version of the Android Connector for M2E (m2e-android) has been released. The Android Configurator is a plug-in for Maven Integration for Eclipse (m2e) that adds support for the Android Developer Tools (ADT) and the Maven Android Plugin. It brings the power of Maven dependency management into the ADT.
Updates for this release include:
- Fix: Support for ADT 20
- Support for Android “apklib” Libraries (not fully completed, waiting on support for multi-module libraries)
Special thanks to Anthony Dahanne for infrastructure support and help getting the integration tests running, Benoit Billington and Jason van Zyl for their pull requests, and all the githubbers who reported bugs and provided feedback. Any problems, please report them here.
- Fix: Support for ADT 20
06:35:42 pm on March 31, 2012 |
The new 0.4.1 version of the Android Connector for M2E (m2e-android) has been released. The Android Configurator is an Maven Integration for Eclipse (m2e) plug-in that adds maven support for the Android Developer Tools (ADT) and the Maven Android Plugin. It brings the power of Maven dependency management into the ADT.
Updates for this release include:
- Fix: Support for ADT 17.
- Fix: JRE classpath container no longer added to Android projects.
- Minor bug fixes.
08:23:49 pm on November 8, 2011 |
The new 0.4.0 version of the Android Connector for M2E (m2e-android) has been released. The Android Configurator is an Maven Integration for Eclipse (m2e) plug-in that adds maven support for the Android Developer Tools (ADT) and the Maven Android Plugin. It brings the power of Maven dependency management into the ADT.
Updates for this release include:
- Support for ADT 15.
- Support for the android-maven-plugin rename.
- Minor bug fixes.
01:41:12 pm on October 22, 2011 |
As part of a work spike we recently looked at cleaning up some technical debt within our application performance monitoring. Through previous iterations our existing monitoring is all over the place, with metrics captured at multiple points including Spring handler interceptors, exception resolvers and annotation-aspects.
While our team differed on the exact approach, we all agreed the current situation was unacceptable and we needed to unify our approach. At my company we have many internal APIs, including one for monitoring. However, in our experience many of them suffer from Not Invented Here syndrome: symptoms including idiosyncratic coding standards.
But the biggest problem is that internal APIs are often stale, with unfixed bugs, no obvious means to push upstream changes, and often using outdated dependencies (such as Spring 2.5.x). We simply lack the resources to keep them up-to-date.
With this in mind, we decided it would be better to use an open source monitoring library. The main benefit being that public, open source libraries tend to attract more developers and are, so the theory went, better supported. So I took the responsibility to review the current Java, open-source monitoring libraries. To keep the spike time-limited, we specified a check-list of possible features we’d like to see:
- Counts or hits
- Timings (including average timings)
- Standard deviations
- Distinguish timings and counts between success and failure
- Spring support
- JMX support
- SPI for customising monitoring if some of the above aren’t fulfilled
So here are our findings:
Jamon is probably the most established monitoring framework, so it was one of the first ones we looked at. While it certainly covers all the metrics we wanted (and then some) there was no JMX support and limited Spring support. With poor documentation and no obvious means to customise its functionality, we decided not to go with it.
Another contender is perf4j, which takes an interesting approach to monitoring by extending logging frameworks. It has support for many familiar logging APIs, including log4j, slf4j, commons-logging and java.util.logging. This makes a lot sense and with helpful documentation and out-of-the box Spring/JMX support this seemed like a good candidate.
However, while it covered most of our timing metrics (as you would expect) it didn’t seem to support counts/hits at all. What is more, you have to extend the framework via various logging framework SPIs which seemed like a lot of work.
The new kid on the block, Java Simon, seemed like the likeliest candidate: it comes with Spring and JMX support, handles all the required metrics and has a clean, simple API that is easy to extend. There also appear to be some performance gains over Jamon, although these are probably marginal at best.
Even though we settled no Java Simon, none of the above really met our exact requirements. But Java Simons long-term support (version 3.0 was released this month) and easy to extend SPI made it the likeliest candidate for us.
09:36:42 am on August 13, 2011 |
The new 0.3.0 beta version of the Android Configurator for M2E (m2e-android) has been released. To install please see the new Getting Started guide:
Note: Please uninstall the old 0.2.x alpha version of the m2eeclipse-android-integration plugin when you update.
This new version improves build performance thanks to new incremental builder. Your Android builds will be faster as they no longer run a Maven shell and only rebuilds when relevant files have been modified. Slow builds was the number one complaint about the old alpha line.
I’d like to thank Anthony Dannane for getting the Tycho command line working so that we could run the m2e-android build through continuous integration. Also thanks to Felix Dahlke and Jeremiah Johnson for their contributions, and Igor Fedorenko for his valuable advice on the m2e-dev mailing list.
Please report any bugs to the issue tracker.
09:22:40 am on August 13, 2011 |
This web-site has moved to my new company domain at:
Please update your subscriptions accordingly.
11:35:48 am on July 25, 2011 |
The Maven Integration for Android Development Tools plugin has had a move and rename and becomes the Android Configurator for M2E in anticipation of the alpha release next weekend. The old Google Code site is being phased out and there is is a new site hosted at Github:
Please update your links to point to the new location.
12:37:22 pm on April 16, 2011 |
So you’re building your typical database-driven web application. You turn to your story board and see that your business analyst has raised a story to allow your testers to stub some of the services you call. It’s a reasonable request so off you go, writing your stub code.
But how will your tester modify your stub settings? They need some interface to hook into the application and pass in stub test data so they can perform their testing. You figure ‘I’ve already got a web interface set-up, I’ll leverage that and create a secure web console for my application’.
Right? Well, I think you might be wrong and you should use JMX instead. Here are three reasons why:
- Security: Most web application frameworks start with the assumption that your web resources are publicly available and you have to put security in after the fact. By default JMX usually has to be explicitly switched on. What is more, JMX is served off non-standard ports that won’t be open on your firewall unless you explicitly request it.
- Less code: JMX managed beans are lightweight and don’t have the overhead of controllers or front-ends.
- Separate security model: Inevitably, the security requirements for your web application will be different to those for your console, so using JMX makes sense because it has a completely separate security model.
In reality, the main problems stem from mixing user-facing front-ends with internal web console interfaces. For example, you might sensibly block all access to your test console on production. However, you may find yourself forced to work around production configuration copied on your staging configuration.
Of course, there are disadvantages to JMX over web consoles. For example, JMX requires specialist software to be installed and users need to be trained with this software, whereas a web console can be operated with a common web browser. What is more, most test frameworks like Selenium are designed to work with web interfaces automatically.
01:29:43 pm on February 12, 2011 |
Released new beta version 0.2.5 of Maven Integration for Android Development Tool. Maven Integration for Android Development Tools is an Eclipse plug-in that adds support for M2Eclipse/Maven integration with the Android Developer Tools (ADT) and the Maven Android Plugin.
This update is a bug-fixing release for issue 40 which was forcing a full build for incremental changes for non-Android projects. User’s should see performance improvements for their non-Android projects.
See Releases for a full list of changes in this release. See GettingStarted for how to install and start using Maven Integration for Android Development Tools or install from the update site. Alternatively Maven Integration for Android Development is available via the Eclipse Marketplace.
This is also the first update release of Maven Integration for Android Development Tools so please raise a ticket for any install/update issues.
11:23:46 am on February 3, 2011 |
This is a copy of an email I sent to the m2e-dev mailing list, reproduced here for visibility and because I used wordpress.com to draft this. The idea came out of a twitter discussion and a desire to create a list of dependencies appropriate for Android apps, and where the best place for such a “catalogue” of dependencies would be.
Problem: Thanks to the indexing remote repositories dependencies can be quickly searched and added to projects through M2Eclipse. However, normally developer’s still need to be aware that a particular dependency exists first before they can search for. It would be nice if developers had the ability to discover new projects or APIs in the Central repository.
Solution: I propose a Maven Catalogue GUI based on the iPhone App Store or Eclipse Marketplace. In addition to being able to search dependencies based on tags, descriptions, titles, etc., users could also order searches based on ratings. Alternative panes for “just in” dependencies, or “best rated” could also be included, allowing developer’s to find alternatives or discover new dependencies through the Eclipse IDE.
Other metrics for Maven dependencies could be included, such as file size and number of dependencies, etc. to encourage developer’s to minimise their dependencies.
Sub-catalogues: For example, while Android apps can use regular JAR files, there are now many Android-specific APIs packaged with fewer dependencies and minimalist coding. It would be nice to present an Android/Mobile sub-catalogue from which Android developers could select dependencies in the confidence that they would not bloat their apps. Other sub-catalogs could include reporting plugins and archetypes.
The Eclipse Marketplace points the way towards achieving this: we could leverage the UI code they have already written. Similarly the back-end web service/site was put together very quickly and simply using the Drupal content-management.
The last bit of good news is that many websites such as Ohloh, freshmeat.net, etc. already have ratings and comments/reviews for the various projects hosted in the Central Repository. Most of these sites already provide APIs. And of course there is lots of catalogue-friendly project meta-data already included in POM files.