Practice for ensuring Android projects build right after SVN checkout in Eclipse

Question

Problem:

When a project is checked into SVN, and someone else checks it out, there is an exclamation mark on it and build path errors need to be resolved. How to fix it?

As an example, I have a project and following is it's structure:

It has 3 libraries in libs folder:

* android-support-v4.jar
* bugsense3.2.2.jar
* gcm.jar

Android Dependencies folder has:

* annotations.jar

Referenced Libraries has:

* gcm.jar

Android Private Libraries has:

* bugsense3.2.2.jar
* gcm.jar
* android-support-v4.jar

Google APIs [Android 2.2] has:

* android.jar
* maps.jar

So it seems like that whatever we place in the libs folder is automatically added to the Android Private Libraries, is that accurate? So they can be checked in to SVN and when someone else checks it out and builds it, the .jars in Android Private Libraries will simply point to his local workspace so that's not an issue.

However, annotations.jar in Android Dependencies and android.jar and maps.jar in Google API are referencing the android-sdk folder on my C:. So when someone else checks out my entire project, they have build issues that they have to resolve via the Java Build Path.

What is the standard practice to have all the libraries kinda stored in SVN in such a way that when a new developer comes in and checks out the project, he simply builds without fiddling around with the settings? I suspect we're going in the territory of using a build management system, continuous integration, build server, etc etc. So I know of it slightly but have never actually used it in practicality as I've never worked in a large enough team. If anyone would be so kind to give me exactly what they use (the actual tools like Maven, Gradle, etc), then it would be much much appreciated!

Thank you,

-V

Answer 1

There is nothing special about the libraries that the ADK adds to the class path. If you want to be able to check in all of your project's dependencies, you can copy the referenced jars to a local directory and then point the class path to those instead of using the provided library groups. Because the android plugin has that new wacky system that automatically adds stuff in the libs directory to your path and to your apk, I wouldn't recommend putting these other jars in there. Normally what we'll do here is create a separate folder in svn named third-party or something like that, and then use svn:externals to reference the necessary jars. Having one common place to store third-party jars makes versioning and configuration management easier.

To illustrate things a little more clearly, this is what an example subversion repository would look like:

repo
    -android_project
        -trunk
            -your other project stuff (src, etc)
            -libs
                -android-support-v4.jar
                -bugsense3.2.2.jar
                -gcm.jar
            -third-party
                -annotations.jar (external)
                -android.jar (external)
                -maps.jar (external)
third-party
    -android
        -v_X.XX
            -annotations.jar
            -android.jar
            -maps.jar

In your actual Eclipse project, you would add the stuff in third-party to the path manually, and the adk will add the stuff in libs to the path automatically.

EDIT

On the topic of this method vs. Maven, the first thing I'll admit is that I don't have an enormous amount of experience with Maven. From what I do know about it, I don't think it quite meets your criteria. When I used Maven, by default it would download your dependencies to a machine specific location, instead of to your workspace. To get Eclipse to pick up these dependencies, you then had to add an M2_HOME property to your workspace so it could resolve all the paths properly. It was pretty easy to set all this stuff up because there were mvn commands to automate the process, but to someone unfamiliar with the system it could cause a lot of confusion and slow things down when a new developer is starting on a project. Additionally, a big issue that we ran into was that it requires that dependencies be stored on some sort of central repository which made working in non-connected areas very difficult.

Again, I'm no Maven expert so take what I've said with a grain of salt, but from my experience Maven works great in an open-source environment where connectivity is welcomed and almost guaranteed but not so much in a closed-source environment. It seemed like it caused more problems than it solved for us and therefor never really caught on. The nice thing about the system I described above is that after checkout, you have a single folder that contains everything (except eclipse) that is required to develop and build the project. That makes things very easy to get up and running on a new machine or unfamiliar environment.

I will say that a big benefit provided by Maven is consistency. With the system that I described, the developer is in charge of every aspect of setting up a project. This means that between developers and projects you can get variations in how your svn repository is layed out. One developer could name a directory "third-party" while another could call it "open-source", or some developers might not use a trunk in their projects. Over time these little things can build up and leave your repository a mess. Since Maven is in charge of project's layout, you can be assured that your repository will stay consistent.