What is the best way to share common code (such as domain classes) between two or more projects?

Question

We are developing a Web application consisting of two Eclipse projects. One project is an HTTP-based RESTful Web service; the other project is a Web site. Both

Answer 1

there are several possible ways to do this, and depending on your specific situation and requirements, some might be better than other.

in all cases, i would strongly recommend a system that understands version numbers.

a classic way to do this would be to use maven. also, it is very well integrated in eclipse and you can structure your modules as part of one parent project, such as:

project-parent
    project-website1
    project-website2
    project-controllers
    project-model
    [...]

internally, these modules can then depend on each other. you can go as far as separating interfaces from the implementation:

project-parent
    project-website1
    project-website2
    project-api
    project-api-impl
    [...]

and then depending on the api module most of the time. maven also has a few mechanisms for dealing with WAR files.

this (single-project) approach is probably ideal for a very small development team. the main drawback is that it is quite unpractical to release things separately - a bugfix in the implementation that only affects website2 would also require a release of website1.

also, the separation tends to be less clear in this, making it potentially too easy to move stuff into the shared modules that shouldn't really be there.

another pattern would be:

 project1-parent
      project1-webapp
      project1-specifics
      [...]

 project2-parent
      project2-webapp
      project2-specifics
      [...]

 common-parent
      common-api
      common-impl
      common-model
      [...]

this makes the separation a bit clearer, and you can release things separately. also (although this is probably not recommended under normal circumstances), project1-webapp could depend on an older or newer version of the common module than project2-webapp. maven can be found here:

https://maven.apache.org/

another toolset that might help you deal with versioning is:

https://gradle.org/

to make the most of these, you might also want to look into using git with gitflow:

http://git-scm.com/
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/

and understand how to use this to deal with versioning and releasing.

personally, i found it VERY confusing when i first started out - but it all makes a lot of sense now.

Answer 2

Separation of concerns

Actually creating a third project and adding project dependencies is the best way, because Separation of concerns isn't only a principle for classes but also for software modules. It creates some advantages:

• Less code to read to learn the ropes of one project.
• Better dependency control, because you could leave out some inter-project dependencies, so that using classes of the wrong module isn't possible.
• Duplicating code is awful.

Project Structure

Make sure you're not creating one big "utility" project, but rather domain-specific projects, like user management or addressbook.

In your case, it could be

• user-api contains User transfer object
• user-service provides CRUD operations
• webapp (or user-client) calls user-service.

Other Build Systems

When moving to continuous integration you'll need to use a better build system than Eclipse, but the principles are the same. You'll create small modules with minimal dependencies.

The most popular Build Systems for Java projects are Maven, Ant and Gradle. Each has its own way to define module dependencies.

Project references in Eclipse

To tell Eclipse about project dependencies, right click on the project, open the properties and switch to the project references. Here you could mark dependencies, so that code changes will take effect immediately without copying a JAR file manually.

Answer 3

You need to create another project (i.e. shared). All of my SERVER-CLIENT app i do like that.

Basicaly, shared module has the EJB interfaces that are used by client and implemented by ejbModule

Answer 4

If you are sharing domain classes between a client and server in a RESTful system you are defeating the point of REST. The REST constraints are designed to allow a client and server system to independently evolve by ensuring that the only coupling between the two systems is confined to media types and link relations.

If you need to share domain objects, forget about REST, it is going to me more trouble than it is worth.

Answer 5

How do you use third party jars? Think about your common code to be third party jar and apply the same rule to your projects. You can use dependency management tool like maven in order to keep versioning in order.

If you want to upgrade to an Application Server where you can deploy EARs you can put the common code in a jar which is a dependency of your EAR... so other WAR projects in your EARs can use the common code.

You can also give a try to OSGI.

Answer 6

Usually you create a third project (e.g. core or shared) which contains the shared code. Just depend on it from both your projects.