What is the best approach to prevent redundancy of code when packaging up Hibernate pojos / mapping files? The following may be describing the wrong design approach, so all recommendations are welcome.

Example:

I reverse engineer some tables (perhaps even the entire schema) for a customer maintenance application. Some of the tables are read-only access (such as one or more look up tables, let's say a zip code look up table), and some of the tables are for update (let's say the customer table). I package the pojos/mf into a jar. ** I set my zip code lookup table as mutable=false in the mapping file because I don't want the table to be updated in this app. **
My customer maintenance application updates the customer table.

The following month, I need to write a maintenance application for the zip code table. I can't reuse the mapping file that I reverse engineered for the customer app because the mapping file specifies mutable=false.

Thanks in advance for your suggestions.

Well, if you work with svn repositories you may view your mapping files for the different applications as different branches and merge changes from one branch to the other if necessary.

The base path should contain a rather straight-forward mapping of your db structure, while the other branches contain the application specific modifications.

It could be argued if your base branch is the trunk branch.

The same method can also be used for the beans.

The base would contain the plain objects and the branches the beans with additional functionality for the different applications.

[EDIT] I would strongly recommend to use Interfaces for the model beans.

The best would be a kit of interfaces which will be implemented by the actual beans, so you have the greatest interchangability for your DAO methods.

For example, if you use a table containing the logical data (t1), and one which contains the localized data (t2), create an interface for t1, maybe two or three interfaces for t2, one containing the fields which are allways required (e.g. name), one which includes the rather verbose fields (e.g. description), and one containing the localization information (e.g. locale code and translation state). Then you create different classes for the different use cases in the different application, each implementing a subset of the interfaces.

Clearly, you need a different set of mapping files if you want to use mutable=false for the first scenario. However, you could/should reuse your pojo.
I somewhere, in the Hibernate docs, read that best-practise is to keep the mappings and the pojos together. I personally, out of a designer's perspective, don't see the greatness of this and your scenario shows this as well.

I would keep the pojos in one jar and the mappings somewhere else (if you use annotations this will not be possible). OR, you skip the mutable=false (if you see your two use cases as part of the same application).

My two cents.

Thank you for replying. So just for clarity, let's say there is a directory structure set up on a server for different projects. Would you place the pojos on a root (trunk) directory, say called /dbObjects, and then have subdirectories for each project that contain mapping files that are specific to those projects underneath this root directory?

So:

/dbObjects
----/custMaintMappings
----/zipCodeMaintMappings

etc...

And in saying this, does this mean that we eliminate redundancy of the pojos by keeping them central all of the other projects, but the mapping files themselves will vary in each project subdirectory, so we wind up with multiple copies (I think this is what you are saying).

Of course the mapping files wind up being implementation specific.

Is this a correct summary of what you are suggesting?

I guess your clarification question is for me.

Using your naming and your decribes scenario, I'd like to clarify that "custMaintMappings" includes all mappings (where zip codes are not mutable) while "zipCodeMaintMappings" only includes the zip code mappings (being mutable).
Depending on what app server you're using and the approach, I would suggest using a (jmx) service registering session factories for each of these two mapping cases. I wouldn't bundle the mapping files in a separate jar, but keep them under /classes in the .sar (using JBoss AS).

However, reading your post again I have a basic questions:
* You state that it is a customer maintenance application. Is performance critical? If not, the simplest solution would (probably) be to not configure "mutable=false". The you can use the same mappings for both scenarios, saving some pain.

Thanks for replying. Actually, my clarification question was for Thompson, but your reply is very helpful...

The customer maintenance app that I mentioned was just an example I pulled out of thin air. I am actually working on a completely different standalone application at the moment that is not running inside of a container. What would you do from a desing standpoint in the case of an application that is not running inside of an app server?

In the first project where I used Hibernate, I found that in certain cases the look up tables were being updated unless I specified mutable=false in the mapping files. This is the reason that I am using this setting. But of course I am concerned with the redundancy issue that I have described.

You also brought up a great argument against using annotations with Hibernate :)

If we're talking about two (different) standalone applications I would definitely not see an issue with two different mapping configurations. It is, well, two different applications working against the same database. However, the transaction strategy on database level will be very important in this case.

In this case I think it would be easier to keep the SessionFactory in a local static variable and not use jndi.

Well you got it quite right, this is one of the multiple ways to do it.

We currently use a common repository for our beans and interfaces, and use derived classes for our applications.

However, for the mappings there is either the way you described, and which I think is the most simple one or you could use an approach pretty similar to a vendor branch.

You practically view your application unspecific mappings as a kind of 3rd party product and apply the application specific changes within your application. If you change your data base and the mappings you put it back to your applications and re-merge the application specific changes.

While this may be a very beautiful way, it may be a impractical if the data base structure changes a lot.