How should I organize source control for Android projects including libraries?

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

For one project I have cloned a library from GitHub into the Components folder, let's say C:\Android\Projects\Componentes\SampleLib (inside that folder there's two folders TheLib and TheLibExample). And my app is created into C:\Android\Projects\Applications\MyTestApp. Then I included the library into the app by following these instructions.

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

If someone wants to fork my app or even help me, it will need the library to compile and run it, which is not included in my project itself. The default.properties file will have something like android.library.reference.1=.开发者_运维知识库./Components/SampleLib/TheLib and that someone will need to manually clone that library too and he would need to place it in the same relative path, otherwise it would mess up source control for my app.

The only way I can think of solving this issue is to organize my workspace like this:

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

And my repository should be filled with the contents from C:\Android\Projects\Applications\MyTestApp\.

But what happens when the library is updated? I can't simply pull the new changes, I need to copy those into TheLib folder. In the previous folder organization this would not be needed as I was referencing the original cloned repository and not a copy.

What should I do then? Should I go with option one and let anyone forking my project deal with the library dependency as they see fit, or should I go with the second one and give everyone more work by keeping two folders in sync when the original one pulls changes from the it's repository?

Maybe git submodules will solve your issue.

Personally I think Android's library project is a FAIL design. It is ridiculous that the only way I want refer/use other piece of code is to get another entire project and set everything up at IDE configuration level. what is a library? it should be a reusable component compiled and packaged in a archive format. According to their important note Library project storage location, I don't think there is a easy workaround that we can break the tie and manage the library as a real library. If your library is not so androidized, try to write/build is as a plain jar library and use maven manage the jar library build/release and project dependencies.

Hmmm, it is reasonable that google call it Android Library Project, not Android Library.

I personnaly think that git submodules don't entirely provide a very easy to use and powerful system for library dependencies.

Git subtrees are a better alternative. I found a very useful guide that explains how to do that.

Basically you can create a subfolder containing your dependencies, and clone repositories inside that 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, you'll have the in this example two repos/libs inside vendor/; you just need to add them to your IDE/build system.

Git branching and modifications are much easier and more straightforward than with submodules.

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