We're currently developing a custom API which we're going to be using not only internally, but distributing to customers as well. The API is being build using Spring and Hibernate.

We're trying to figure out how we should go about packaging this product so that it will:

1) require as little configuration as possible
2) be as non-invasive as possible
3) be as self contained (inside of a one JAR) as possible

So, a few questions:

Considering we have the following setup for Hibernate:

Code:
<bean id="sessionFactory" class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
  <property name="dataSource"><ref bean="dataSource"/></property>
  <property name="mappingResources">
    <list>
      <value>foo/bar/Baz.hbm.xml</value>
    </list>
  </property>
  ... more Hibernate set up ...
</bean>
Notice the dataSource property...some user's of the API might already have a suitable DataSource defined in a Spring context - if so, great - our app can use it. But how do we handle this if they're not already using Spring for the rest of their app, and they don't want to start using it just to use our API? Is there another way to set this DataSource?

Also, what if the user's system is already using Hibernate? We'd like to ship a dataAccessContext.xml file which does all of our Hibernate configuration inside of our JAR file...but what happens when the user is already using Hibernate (maybe with Spring, maybe without) in their project?

I think what this really comes down to is: How do we integrate our Spring context definitions with another user's - or for that matter, how do we package our API so that, regardless of the combination of Spring/Hibernate the end user has, our package can drop in gracefully and with minimum inpact?

Any experience or advice would be greatly appreciated!

Jon