The way that different object stores handle fixtures depends on
their implementation. The in-memory object store always loads fixtures,
the XML object store loads fixtures only if they haven't been run but
(by detecting the xml directory that it creates)
ignores them second time around.
JPA Objects though is more conservative: it never loads up fixtures in runtime. The rationale is that seeding the database with initial data is an activity that you/your DBA should have visibility over.
Most likely though, you will have some fixtures (those for
immutable reference data/static data objects) which should be loaded in.
To support this, you can run the fixture manager tool
(org.starobjects.jpa.tools.FixturesManager) that
comes with JPA Objects. It takes the following
arguments:
-g <config directory containing nakedobjects.properties>
Depending on where you run the utility from, this is typically
something like ../commandline/config. This is
used to bootstrap Naked Objects and to run in the fixtures. (It sets
a special flag which instructs JPA Objects
object store to read in the fixtures.
After this, you should have a populated database. If you mess up, you can always recreate the database using the schema manager (see Section 7.3, “Run the Schema Manager”).