Andmore 0.5-M1 RC1

We are getting close to having a 0.5-M1 p2 site ready for the general public.  There is a p2  release candidate available for testing:

The most important change is the implementation of bug 463598.  This allows you to convert existing ADT projects so that Andmore tooling can work with them.   To do this, select an existing ADT Project, and open the context menu.  Then select Configure->Convert to Andmore project.

This will update the project with the new nature and container ids.

Some users have started to submit some other bugs that will be addressed before we make 0.5-M1 official.  In the meant time, please try Andmore out, and report any usability bugs, or even consider providing some patches.

Posted in android, eclipse | Tagged , | Leave a comment

Importing existing Android Code into Andmore

Wayne raised a bug about importing existing Android Development Tools projects so they work with Andmore.   The problem arises because the various nature and builder ids have been renamed when we moved to Eclipse.  If we didn’t and you had ADT and Andmore installed in the same instance (this is just crazy talk why would one want do such a thing), then both Andmore and ADT would both be trying to control the project along with trying to build it.   Mass chaos would occur, and dogs and cats would be sleeping together.  Mass hysteria would occur.

To avoid this world ending situation, the ids were renamed.  It’ll be ugly but you could technically install both into the system, however I don’t recommend it.   You are better off just installing one or the other.  We hope it is Andmore.   If you do, how do you get your existing code brought into the system.

Luckily, there is an Import Wizard that can do the vast majority of the heavy lifting for you.  I’ve created a FAQ entry that outlines the steps.

This will take a project that is in the existing ADT format, and bring it into an Andmore workspace and set the builder and nature ids appropriately.   It does not work too well yet with Android Studio and Gradle related projects.   We need to make it a bit smarter in this area.

There are a couple of new bug reports to add support for these formats.

There is also a need to deprecate the APKLib format but still be able to import the appcompat_v7 libraries until AAR support is added.

Long term, APKLibs and the legacy project format need to go away, so that build tools like m2e-android, buildship, and others can add the necessary support and configuration for their project structures.   Andmore should provide the extension points where necessary so that you can plug in your own providers for these situations.

If you are looking for something to help out with, consider contributing a patch for bug 463610 and 463598 to help people migrate to Andmore from ADT.

Posted in android, eclipse | Tagged , | Leave a comment

Andmore Nightly p2 Repository

Andmore now has a nightly p2 repository available for Adopters and third party tool providers to start making use.

This site should contain everything you need to install Andmore into an eclipse environment and start developing android applications.  It can also be used by add on providers to build off and extend Andmore to other tools.   As with all nightly sites, this could be unstable at times, but should be useable to help provide feedback to the project.

Please help kick the tires and provide feed to the project about what is working and what isn’t working.  We need and want your involvement to help improve eclipse android tooling.

Posted in android, eclipse | Tagged , | Leave a comment

Andmore Planning for 0.5-M1

Finally unwinding from attending EclipseCon, and presenting the Andmore Project to the folks that are in attendance.   It is nice to see that there is still interest in having a first class set of tools that allow Android development.   I got to meet a lot of great people, and help get some pointed in the direction for code contributions.

One thing that is clear, is that we need to get you the community a p2 repo soon so that you can start kicking the tires and also start migrating tools that have been developed for ADT to also work with Andmore.   To this end, I have set myself the goal to get a 0.5-M1 build ready for you to use before the end of April.    This I believe should be doable and I will look at starting true nightly/integration builds for those that need them as well or just like to live on the edge.

To help those that are interested in contributing to Andmore understand where the dependencies with other eclipse projects come into play.  Below is a PDE Visualization of the dependency graph.


Andmore in particular is dependent on the platform, jdt, and the wtp projects.  Indirectly it pulls in other projects as well.   The org.eclipse.andmore project is the main plugin that many of the supporting plugins that andmore’s features depend upon.


Andmore itself is made up of a number of other plugins that provide additional functionality beyond just the base android project creation.    While the Android Core provides you with the basics of what you need, the additional plugins enhance the user experience.

Anyways, be looking for an 0.5-M1 build within the next month, and please consider forking the repository on github and providing some pull requests.

Posted in android, eclipse, eclipsecon | Tagged , | Leave a comment

Tracking Pull Requests on your HIPP instance

In a prior entry, I wrote about getting your HIPP Instance at Eclipse to run GitHub Pull Requests.  One thing that is missing from that is, the ability to identify which of the jobs that ran, ran which pull request.   By default, Hudson only outputs the job number,  so if you have multiple pull requests that are being run, there isn’t an easy way to identify which job number is associated with which pull request.

With Jenkins this would be pretty easy, as the Set Build Name plugin has been updated so it can accept Jenkins variables, unfortunately the equivalent plugin in Hudson is way behind and doesn’t understand variables besides it’s own.   There is a work around though.

Install the Set Env Plugin, which allows you to inject before the build begins system environment variables.   You can then, use the Set Build Name plugin to have it use the injected environment variable.

The setup looks similar to this:

Screen Shot 2015-02-19 at 10.02.55 AM

The PULLREQUEST_NUMBER is the Build Parameter to identify which pull request should be run.  When the job now runs you’ll get the following output in your build history.

Screen Shot 2015-02-19 at 10.04.12 AM

The job number and the Pull Request Number will be displayed for easy and quick access to the results of a particular pull request.

Posted in android, eclipse, release engineering | Tagged , | Leave a comment

Rolling a 1 when you needed a 20

So for at least the last week I have been battling trying to tame the savage Integration tests that we inherited from forking the Android Development Tools.   I’ve re-captured in the last couple of years my passion for Role Playing Games and Boardgames in general.  Working on these tests and trying to get them to run outside of their original intended environement, has been like rolling a D20 die, and rolling a 1 when you really needed a critical hit 20.  Time and Time again.

However, I finally, managed to roll that 20 last night, and the vast majority of the tests are now running.   I’ve created a wiki page that documents most of the setup requirements in order for you to run the tests as part of your build locally.   It was important to get these running, as during my investigation it didn’t appear that Google had any of these tests running together as part of their old basebuilder build.  There were only the unit tests, and then an ApiDemo test that were set to run as part of the build.

The problems mainly came around the fact that you needed to have certain Android Platform APIs installed along with there sample applications.   You also need to setup a special environment variable ADT_TEST_SDK_PATH that points to the location where you have your Android SDK installed.    In addition for the CI server at Eclipse we needed to set the ADBHOST environment variable to point to the local machine so that DDMS that starts up as part of plugins during integration tests does not toss a dialog up on the screen.

I do want to point out a very handy set of classes that can be used along with the Integration Tests in case you get UI dialogs that pop up during your tests.  DialogMonitor is a class from eBay’s Turmeric project.  While that project is pretty much dead, grabbing the DialogMonitor and it’s supporting classes is worth while.  It will basically monitor for any Dialog that pops up on the screen, and dismiss it to keep the UI thread available for your tests if they need it.

The other thing that was happening, none of the tests were isolated from each other.  They were leaving dirty workspaces behind, and re-using the same project.   So, now, all the tests create their projects, and then remove the projects and files.    Also the tests have been converted to use JUnit 4, and if they needed temporary directories or files, the TemporaryFolder rule is being used to provide that.   The boy scout motto applies when you are writing tests….leave your camp site in better shape than you found it.   For tests, always clean up after yourself.

With the tests now running, we have a bit of a safety net going forward for any code change.  Code coverage is still not good, but at least we have some sort of net even if it has holes to at least try and catch breaking changes in functionality.    We will need more tests and more code coverage, but I’m more comfortable accepting contributions now that we have these tests running.

If you are looking for areas to contribute to the project, and want a good way to learn about the various plugins, we can use help getting the rest of the unit tests running, as well as getting tests in place for the existing code that is not being covered.   Andmore will be at the Eclipse Hackathon, so these types of things are great opportunities for those wanting to contribute to the project but don’t want to start with a big feature.  Also we have lots of FindBugs reports to address as well.

Andmore is really going to succeed or fail based on the user community it attracts.   Our goal is to make it as open and easy as possible for people to contribute.   Getting the tests running was one small step in that process.

Posted in agile, android, eclipse, testing | Tagged , | Leave a comment

Running Pull Requests from Hudson

Since the Andmore Project is using GitHub for our central repository, we needed a way to at least manually verify that a given pull request can build and not fail any existing tests. Unfortunately, unlike Jenkins, there currently is no GitHub integration plugin for running pull requests and then posting back the results to the particular pull requests.

However, you can setup a job on your HIPP instance so that you can run the pull requests manually and verify the results. To start with you’ll need a parameterized build on your HIPP instance. I suggest setting up a Parameter like PULLREQUEST_NUMBER as shown below.

Screen Shot 2015-02-12 at 2.54.50 PMThis will allow you to enter the Pull Request number when you manually or remotely trigger the job.

The next thing you need to do is to tell the git plugin how to find the pull request branches. You also need away to tell git what branch from those pull requests to check out when building.

Screen Shot 2015-02-12 at 2.55.15 PMThe keys here are the Refspec entry and the Branch Specifier.   When you kick off a job, it’ll use the Pull Request number you specified, and build that particular branch.

There is an existing bug report asking for enhanced and integrated support for Hudson and Pull requests with GitHub.   As more projects at the Eclipse Foundation start to use Git as the central repo, working with Pull Requests is going to become even more critical.  This at least gets you part of the way there so you can verify the requests with Hudson.

Posted in android, build, eclipse, release engineering | Tagged | 5 Comments