Just some high level comments for right now.
In order to mirror the xml metadata, you would need to start with a top level metadata root, corresponding to the jdo element. You could construct this from the JDOHelper, e.g. public JDOMetadata newJDOMetadata();
Then, JDOMetadata would have methods newPackageMetadata(String name), newQueryMetadata(String name), and newFetchPlanMetadata(String name).
PackageMetadata would then have methods newInterfaceMetadata, newClassMetadata, and newSequenceMetadata.
If you use method chaining instead of constructors, then you could change this example to be more self-describing:
ClassMetaData cmd = dmdf.newClassObject(pmd,"Client", IdentityType.DATASTORE.toString(), null,
Boolean.TRUE.toString(), Boolean.TRUE.toString(), Boolean.FALSE.toString(),
ClassPersistenceModifier.PERSISTENCE_CAPABLE.toString(), null, null, null, "CLIENT", null);
Using the newClassMetadata construction would enforce the rule that a class can be a member of only one package, so you can neither forget to assign the class to a package nor add the class to more than one package.
If you want to enforce setting the required metadata, the newXXX could do this, e.g. for sequence metadata, the name and strategy are required:
But most metadata is optional with reasonable defaults.
For boolean properties, you might use Boolean as parameters/return values instead. Java 5 will automatically convert the setXXX parameters for you, but the getXXX will return a tristate value which is needed to distinguish between the user setting a value and not. A boolean return type doesn't allow this.
Finally, note that in the javax.jdo.annotations package we already have enums for the metadata. So there's no need to repeat them. The only awkward thing is that they would be referenced from the metadata package. But repeating their definitions in multiple packages seems worse.