I was looking for some answers in SO or here, but without any results, that's why I would ask you.

Let's assume I have a two different projects - for example server part and client part of an app. I'm developing my own part, while my friend is making the second one. But both of us should use some common interfaces like User or AccountInfo or ChangableAccount... whatever in order to ensure a compatibility. For example if a clients send a User data to server, then the server should operate on the same class. The same with interfaces etc. Moreover, if there are any changes in a common interface, both projects should adjust its code to the new situation.

The only solution I can see now is, to create a one extra project in which all common things are defined. We, me and my friend, should add this project as a dependency to a main project (client or server). Shared project can be managed by some version control system, so we have always the most up-to-date state.

What other solution would you suggest? How such problems are solved in professional apps?

  • 1
    You should version control whether you share something or not. Are you saying you're not using version control for the client and server projects? If so, remedy that immediately. Mar 4, 2014 at 15:23
  • Or If you are using eclipse you Can just do Link source in build path and point to external project packages Feb 23, 2021 at 14:56

4 Answers 4


create a one extra project in which all common things are defined

This is the exactly first step to share reusable parts - and its the easy part. The more challenging part is to decide if the two projects which are using the shared library shall have independent release cycles (or not), and if it should be possible that "project A" uses version 1.0 of your shared lib, whilst project B uses version 2.0 at the same time.

If you want the latter to be possible, you need to have a strict versioning scheme and release management for your library (and version numbers as part of the library file name, like suggested by @RoryHunter). You should also take care about backward compatibility in your lib in this situation. Your library should be managed as a separate product, adding unit tests to it to make sure the different versions in production will be a good idea, and a tool like Maven can make sense, too.

If, however, you want prevent that situation, you should manage "project A", "project B" and your lib as a common project, with a combined development, build and release process. This will allow to change the common interface of the shared library much more and often than in the first scenario. And you won't need something like Maven or version numbers in the library file name. But the tradeoff is that A and B cannot be developed independently any more.


Your solution is the right one. Put the shared code into a another project that builds its own JAR file, and use it in both projects. When building the JAR file, you may want to include the version in the name, e.g. in Debian style;


It doesn't prevent versioning trouble, but it should help. I've never used Maven, but I understand it can help in this situation.


create a one extra project in which all common things are defined

That's exactly the way that .Net expects you to do it.

Abstract these objects into a third Assembly, and reference this from both projects. I'd suggest doing so as Interfaces, which is cleaner, but ...

Watch out for Serialisation:

  • The only way I could directly serialise/ deserialise objects between the two programs (admittedly this was a while ago using Framework 2.0) was to install the "shared" assembly into the Global Assembly Cache on both client and server machines. If the assembly was "local" to each project, then the Framework saw them as discrete Types and refused to [de]serialise the one into the other.
  • And [de]serialising objects Typed as Interfaces is a bit of a "challenge". The original, non-Interface Type didn't seem to "make it" through the Serialisation "pipe" so the receiver didn't know what concrete Type to "build" from the incoming stream.

As others have suggested, your thought process is accurate. Professionally, most would use something like Maven or Gradle to manage these dependencies efficiently.

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.