Question

I’m a contributor to a Java Open Source project which integrates with Hibernate. I’m fairly new to the Open Source scene (as a contributor), and would like advice on how to manage dependencies.

What are the best strategies / approaches for managing changes to the Hibernate codebase within our project?

For example, nestled deep within our code is the following line:

ResultTransformer transformer = new PassThroughResultTransformer();

The default constructor here causes us issues:

• It is fine in Hibernate 3.2.x,
• In Hibernate 3.3.x it was marked as deprecated, and a static member was introduced:
  PassThroughResultTransformer.INSTANCE
• In Hibernate 3.4, the default constructor was removed.

There is a clear fork, where we are unable to support both Hibernate 3.2 and Hibernate 3.4 within the same class.

What is the best way to manage issues such as this within our codebase?

Forking the project for every release of Hibernate seems like a nightmare, especially when layered with our own feature releases.

Answer 1

You have to decide what versions you want to support first. If you absolutely want to support both 3.2 and 3.4, for example, you’ll need to write code that will, at runtime, do the right thing, probably through reflection.

You’ll lose compile-time checks by using reflection, but you’ll support both versions of the library.

Or you can say “starting with version X, we only support Hibernate 3.3 and later”.