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

Andmore Tests are Alive

After battling for the last couple of days, the Andmore’s projects Integration and Unit Tests are now running.   Well, let’s say they are at least not failing.   The unit tests are pretty self contained.  However the tests that are more Integration tests, are pretty brittle.  In fact some are so brittle that they needed to be ignored.

The main culprit is that none of the tests that are Ignored, are cleaning up after themselves.  They leave a dirty workspace, and cause Dialogs to be displayed.  This tends to hang the tests in a state that just locks everything up.

So, with this said, we do have about 400 good tests that play nicely together.  This is better than no tests at all but is a long way from having any type of good code coverage.   Which will be my next item to work on, getting JaCoCo to run along with the tests so we have an idea of what is being executed and what currently is not.

We could use some help with getting these tests to run nicely.  I got them to work well for the most part on a Mac, but when they started to run on a Linux headless system they would lock up at different points.   I have no idea how well they work on a Windows machine.    So if you feel like lending a hand, please clone the repository, and start submitting pull requests to to the project.   We’ll gladly take any help you can provide.  You can see the latest test results here:

Also for those that are really brave and like to test bleeding edge builds, you can install Andmore directly into your running Luna environment (may work with older versions as well).  Just use the following url in the Install Software of your IDE:

That should contain everything you need to install Andmore and start playing around.  I do not recommend installing ADT and Andmore into the same environment.

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

Andmore Project Update

It has been a while since the announcement that Andmore had passed trademark review.   So thought I’d give a status update of where things stand currently.

  • All code from the former Motodev Studio plugins and the Android Development Tool plugins have gone through package and bundle renaming.
  • The source code has been sent to the Eclipse for IP Review and approval for parallel code review.
  • I’m in the process of submitting all the third party dependencies for code review, this includes the libraries and utilities from the AOSP project that are leveraged by the plugins.
  • Submitting CQs for re-use of existing third party code that is already in orbit.
  • Removing deprecated plugins that no longer fit as they were either very Motodev specific, or duplicate existing ADT functionality.

The source code is available to download from the current GitHub repo.

Once we get initial approval for parallel IP, we’ll turn the repo over to eclipse.  Our plan is to continue to host the repo at GitHub, allowing potential contributors that are comfortable with pull requests to use that mechanism to submit bug fixes and features.

We still have lots of work to do, including making sure our Eclipse related websites are setup.  We are hard at work to get you something to start testing and kicking the tires on before EclipseCon but no promises.

In the mean time, if there is a feature or something you would like to see, please open a bug or feature request on the projects bugzilla.

Please feel free to checkout the code and build it, provide feedback, or just submit feature requests.

Posted in android, eclipse | Tagged | Leave a comment