One further alternative is if you have annotations in your classes, you provide JDO XML Metadata (package.jdo), and also
ORM XML Metadata (package-{mapping}.orm). In this case the annotations are the base representation, applying overrides from JDO XML Metadata,
and then overrides from the ORM XML Metadata.

When not using the MetaData API we recommend that you use either XML or annotations for the basic persistence information, but always use XML for
ORM information. This is because it is liable to change at deployment time and hence is accessible when in XML form whereas in annotations you add an
extra compile cycle (and also you may need to deploy to some other datastore at some point, hence needing a different deployment).

JDO XML Metadata

JDO expects the XML metadata to be specified in a file or files in particular locations in the CLASSPATH.
For example, if you have a class com.mycompany.sample.MyExample, JDO will look for any of the following
resources until it finds one (in the order stated) :-

You could define the metadata for these 5 classes in many ways -- for example put all
class definitions in com/mycompany/package.jdo, or put the definitions for D and E in
com/mycompany/app1/package.jdo and the definitions for A, B, C in
com/mycompany/package.jdo, or have some in their class named MetaData files e.g
com/mycompany/app1/A.jdo, or a mixture of the above. DataNucleus will always
search for the metadata file containing the class definition for the class that it requires.

ORM XML Metadata

You can use ORM XML metadata to override particular datastore-specific things like table and column names.
JDO expects any ORM XML metadata to be specified in a file or files in particular locations in the CLASSPATH.
These filenames depend on the javax.jdo.option.mapping persistence property.
For example, if you have a class com.mycompany.sample.MyExample, and the persistence property is set to "mysql" then JDO will look for any
of the following resources until it finds one (in the order stated) :-

If your application doesn't make use of ORM metadata then you could turn off the searches for ORM Metadata files when a class is loaded up.
You do this with the persistence property datanucleus.metadata.supportORM setting it to false.

XML Metadata validation

By default any XML Metadata (JDO or ORM) will be validated for accuracy when loading it.
Obviously XML is defined by a DTD or XSD schema and so should follow that.
You can turn off such validations by setting the persistence property datanucleus.metadata.xml.validate to false when creating your PMF.
Note that this only turns off the XML strictness validation, and not the checks on inconsistency of specification of relations etc.

Metadata discovery at class initialisation

JDO provides a mechanism whereby when a class is initialised (by the ClassLoader) any PersistenceManagerFactory is notified of its existence,
and its Metadata can be loaded. This is enabled by the enhancement process.
If you decided that you maybe only wanted some classes present in one PMF and other classes present in a different PMF then you can disable
this and leave it to DataNucleus to discover the Metadata when operations are performed on that PMF.
The persistence property to define to disable this is datanucleus.metadata.autoregistration (setting it to false).