I have written a small Java Swing desktop application. It seems like a natural step to port it to Android since I am interested in learning how to program for that platform. I believe that I can reuse some of my existing code base. (Of course, exactly how much reuse I can get out of it will only be determined as I start coding the Android app.)

Currently I am hosting my Java Swing app on Sourceforge.net and use Git for version control. As I start creating the Android app, I am considering two options:

  1. Add the Android code to my existing repository, creating separate directories and Java packages for the Android-specific code and resources.

  2. Create a new Sourceforge project (or even host a new one) and creating a new Git repository.

    a. With a new repository, I can simply add the files from my original project that I will reuse. (I don't particularly like this option as it will be difficult to modify both copies of the same file in both repositories.)

    b. Or I can branch the original repository. This adds the difficulty of merging changes of shared source files.

Mostly I am trying to decide between choices 1. and 2b. If I'm going to branch the existing repository, what advantages are there to hosting it as a separate SF project (or even using another OSS hosting service) as opposed to keeping all my source code in the current SF project?

  • 1
    In a .net windows/web app, we split it into common, web, windows -- and used branches for purpose, not splitting the code. Separate repos sounds very annoying, because you cannot track code changes that relate to each other together.
    – gahooa
    Commented Sep 11, 2012 at 22:22

3 Answers 3


I'm actually working on the exact same thing at the moment. Personally, I find it easiest to keep everything in one repo, one branch. I use separate java packages for common, swing, and android code. I have interfaces for all the calls from the common package into the GUI packages, so the common code has no idea which GUI it's running against.

The advantage to this approach is it forces you to keep your code bases synced up, sort of like a personal continuous integration. If your versions aren't isolated from each other in source control it's a lot easier to keep them from diverging.

Don't think about what you might need later. Think about what works best for you right now. The most important thing is to make your code modular. If you do that, putting it into a separate library, separate branch, or separate repo if and when you need it later is trivial.

  • Thanks for the info. This seems to go along the same lines as what other's have suggested. I'm glad to hear that it works for you. I'm definitely going to give this a try to manage my source code.
    – Code-Guru
    Commented Sep 11, 2012 at 23:19

The correct way to go is to divide your code in three parts: common, Swing-desktop, Android. Whether you use one repo or three is up to you; three repos might make sense if their nature is going to be different: different committers, different branching/versioning policies, etc. or perhaps the repos are going to be huge and you don't want to burden Swing-desktop developers from downloading the Android code and the other way round.

  • So far this project is less than 5k lines of code, which doesn't seem very large to me. The Android code shouldn't double that, I don't think. Is that small enough to be manageable in a single repo?
    – Code-Guru
    Commented Sep 11, 2012 at 18:38
  • I would think so; it is a small project and performance shouldn't be an issue under any VCS. I would keep a single repo and be done with it unless you need to. I'd also clearly split the three parts: org.foobar.common, org.foobar.swing, org.foobar.android or something like that.
    – alex
    Commented Sep 11, 2012 at 19:48
  • That more or less what I have in mind. I developed my Swing project in NetBeans, and so have all the files for a NetBeans project in Git. I am considering moving thos to a "swing" subfolder and creating "android" and "common" subfolders for the other two parts.
    – Code-Guru
    Commented Sep 11, 2012 at 23:17

The best way to accomplish your code reuse would be to take the common functions of the apps and extract them to an external library that is linked in both projects which are each in their own repository. This eliminates duplicating code through branching or having a single complex repository. It would likely be a lot of work to accomplish this depending on how your desktop app is designed, the amount of effort involved to get everything set up this way may be to large of an investment because the returns are mostly in long term maintainability.

The next best option would be to put both projects in the same repository, this could get a bit tricky to manage if your project grows in scope. This option would also be a bit difficult to manage if you ever had more people involved, though this could be a non issue for you.

I would avoid branching to create the android app you will run into problems maintaining a single correct version of your shared code, and you will have sizable portions of each branch that are separate distinct code that should never be merged together. That isn't how branches are designed to work and it will cause headaches for you.

  • I like your third option of having a separate library of shared code. At the moment this is a fairly small application, I don't think it's even 5k lines of code. But I would love to keep working on it and add features, fix bugs, etc.
    – Code-Guru
    Commented Sep 11, 2012 at 18:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.