Thanks for the replies. Sorry, I should have highlighted the fact that the only reason I solved the PG/mySQL one is because the app server provides the ability to have a connection pool setup to the database - aka a managed pool. In Glassfish, setting up this pool is like this (domain.xml):
<jdbc-connection-pool driver-classname="" pool-resize-quantity="10" datasource-classname="org.postgresql.ds.PGSimpleDataSource" max-pool-size="20" res-type="javax.sql.DataSource" steady-pool-size="10" description="" name="pgsqlPool">
<property name="User" value="inv_usr"></property>
<property name="DatabaseName" value="invoice_db"></property>
<property name="LogLevel" value="0"></property>
<property name="Password" value="xx_yy_zz"></property>
<property name="ServerName" value="localhost"></property>
<property name="Ssl" value="false"></property>
<property name="ProtocolVersion" value="0"></property>
<property name="TcpKeepAlive" value="false"></property>
<property name="SocketTimeout" value="0"></property>
<property name="PortNumber" value="5432"></property>
<property name="LoginTimeout" value="0"></property>
<property name="PrepareThreshold" value="5"></property>
<jdbc-resource pool-name="pgsqlPool" description="" jndi-name="jdbc/pgsqlPool"></jdbc-resource>
So, the persistence.xml (for postgres), would look as (using eclipse link)
<persistence-unit name="invoicingTxUnit" transaction-type="JTA">
<property name="eclipselink.logging.level" value="INFO"/>
So, if ObjectDB had a 'PGSimpleDataSource' equivalent class that the whole issue could be delegated to the container?
I'm concurrently developing actively with ObjectDB but also using PostgreSQL warehousing bulk data that is perceived to be seldomly used. Also, I'm using it to ensure my domain model is also relevant in the relational world - as ObjectDB makes it so easy to progress quickly without getting bogged down without relational considerations (e.g. foreign keys and join column names etc etc). So, as I progress from testing locally to my test environment in Glassfish 3.1 - the environment already is set up with the Postgres jta-data-source, so the persistence.xml is environment agnostic (the persistence-unit just references the JNDI name for the pool). The only difference is that I have to modify my main persistence unit in persistence.xml which point to my shared object db development instance. I do this manually but I have a half-working maven script that I use to create my artifacts.
Erick, thanks for your suggestions. I'll look into that now. I'm using EJB3.1, JPA2 on Glassfish 3.1. The solution you mentioned is something I'll look into - my maven resource copying is a little flaky and I'd prefer a build independent way of resolving the DB instance. I didn't realise we could have placeholders in persistence.xml and have the container resolve these!