A project's module that is subject to be reused has to meet specific criteria. First of all the technology of the shared modules has to match the target project. This sounds obvious, but has quite some implications on the implementation details. Especially used libraries and frameworks will inevitably cause the involved modules to be coupled and dependent on the specific technology. For example, model classes in Java EE typically contain annotations from APIs such as JPA that need to be available in all dependent modules.

Third-party dependencies with specific versions that are required for a shared module to function correctly have even more technical impact. These dependencies then have to be available at runtime and must not collide with other dependencies or versions thereof. This can cause a lot of headache with colliding dependencies that are already available on the server. The same holds true for implementation details that contain implicit dependencies.

A typical example of this is JSON mapping libraries such as Jackson or Gson. A lot of third-party dependencies use these libraries in specific versions that might collide with other dependencies or versions at runtime. Another example is logging implementations such as Logback or Log4j.

In general, shared models should be as self-sufficient as possible or at least contain only stable dependencies that won't likely drift into these issues. A good example for a very stable dependency is the Java EE API. Because of the backwards-compatible nature of the Enterprise Edition, usage of the API and resulting functionality won't break if a newer version is introduced.

But even if the Java EE API is the only dependency of shared modules, it will bind the model to a specific version and reduce the freedom to change.