I have a requirement to create a component which can be used stand-alone or within a larger application. When used stand-alone, it should not require a database, nor any database/ORM related dependencies. When used as as part of a larger app, some of the classes will indeed be persisted to a database via JPA/Hibernate.
I was thinking the domain objects in the component would not have any annotations (due to the requirement to not have any ORM-related dependencies). In the larger app, I would then sub-class those domain objects…which is about as far as I’ve made it.
Typically, I use field-level Annotations. Is it possible to due with with the scenario described above? I’m thinking it’s not.
The other thought I had to switch to annotating the properties. In which case, I’d extends the non-annotated domain object, override all the properties, & annotate those. The child would just be a delegate with the required annotations. This just seem like a lot of work/code.
Ironically, I think this would be more easily doable if I was using hbm.xml, which we’ve recently moved away from. Am I missing something with annotations?
The JPA annotations are really your only dependency. If somebody is using your object in a POJO (non DB) way that all they will need is the JPA annotations jar, which for a most application servers is actually on the classpath anyhow.
Surely just having the annotations as a dependency is pretty reasonable, it’s no like you need to drag in the whole of hibernate and it’s many friends.
The alternative is as you’ve worked out is to use hbm’s for this entity. It’s not that bad, as hibernate is quite happy mixing annotation and hbm style entities in a single SessionFactory and you can still use field access so don’t need to compromise the public interface to your class.