How do I organize source control for Android projects, including libraries?

Question

I need some help figuring out the best way (or best practice) to organize my Android project. For simplicity, let's say my Eclipse workspace for Android is C:\Android\Projects\ . Inside this folder, I like separate applications from libraries, and I have two other folders, C:\Android\Projects\Applications and C:\Android\Projects\Components .

For one project, I cloned the library from GitHub to the Components folder, say C:\Android\Projects\Componentes\SampleLib (there are two folders TheLib and TheLibExample inside this folder). And my application is created in C:\Android\Projects\Applications\MyTestApp . Then I included the library in the application by following these instructions .

Now let's say that I want to use GitHub to share my application with the open source community. I will create a repository and push everything from C:\Android\Projects\Applications\MyTestApp to some repository.

If someone wants to unlock my application or even help me, he will need a library to compile and run it, which is not included in my project. The default.properties file will have something like android.library.reference.1=../Components/SampleLib/TheLib and that someone will have to manually clone this library and they will need to put it in the same relative path otherwise it will ruin the initial control for my application.

The only way to solve this problem is to organize my workspace as follows:

 C:\Android\Projects\Applications\MyTestApp\TheApp C:\Android\Projects\Applications\MyTestApp\TheLib C:\Android\Projects\Componentes\SampleLib 

And my repository should be populated with content from C:\Android\Projects\Applications\MyTestApp\ .

But what happens when the library is updated? I can’t just pull the new changes, I need to copy them to TheLib folder. In the previous folder organization, this would not have been necessary, as I was referring to the original cloned repository, not a copy.

What should I do then? Should I go with option one, and let someone fork my project with library dependencies as they see fit, or should I go with the second and give everyone more work, keeping the two folders in sync when the original pulls the changes from it ?

Answer 1

Maybe git submodules solve your problem.

Answer 2

Personally, I think the Android library project is a FAIL project. It's funny that the only way I want to reference / use another piece of code is to get another project and set everything up at the IDE configuration level. What is a library? it must be a reusable component compiled and packaged in archive format. According to their important record, The location of archival projects in the library , I do not think that there is an easy workaround that we can disconnect and manage the library as a real library. If your library is not so android, try to write / build as a regular jar library and use maven to control the build / release of the jar library and project dependencies.

Hmmm, it’s reasonable that Google called it the Android library Project , not the Android Library .

Answer 3

I personally think that git submodules do not fully provide a very convenient and powerful system for library dependencies.

Routines

Git is the best alternative. I found a very useful guide explaining how to do this.

Basically, you can create a subfolder containing your dependencies and clone the repositories inside this subfolder:

 $ mkdir vendor $ git remote add -f ABS https://github.com/JakeWharton/ActionBarSherlock $ git merge -s ours --no-commit ABS/master $ git read-tree --prefix=vendor/ABS/ -u ABS/master $ git commit -m "Merged ABS into vendor/ABS/" # Now another lib $ git remote add -f Crouton https://github.com/keyboardsurfer/Crouton $ git merge -s ours --no-commit Crouton/master $ git read-tree --prefix=vendor/Crouton/ -u Crouton/master $ git commit -m "Merged Crouton into vendor/Crouton/" 

Then in this example you get two repositories / libraries inside vendor/ ; you just need to add them to your IDE / build environment.

Git branching and modifications are much simpler and simpler than with submodules.

I even created a small script that automates this process for a list of libs.