Gunnar Morling I do worry about putting the onus on each and every SchemaManagementTool implementation to parse and interpret the plethora of config options for JPA-schema-gen and hbm2ddl. Maybe its better if we defined a "parameter object" that represents the parsed configuration information and passed that into the calls to SchemaManagementTool to get the delegates.

So today we parse all that config outside of SchemaManagementTool (in JpaSchemaGenerator, SchemaExport, etc) and then use that to drive how we interact with SchemaManagementTool to get certain delegates and to build the things we pass into those delegates (Target, etc). I think the first part still needs to be true : whatever drives this process needs to know that the user wants to drop and recreate the schema or validate the schema etc; so it needs to at least parse and interpret hibernate.hbm2ddl.auto, javax.persistence.schema-generation.database.action and javax.persistence.schema-generation.scripts.action to understand what actiosn (if any) need to be run.

From there we have a few options We could let each delegate configure itself. So e.g. we'd call SchemaCreator#doCreation passing the Map/ServiceRegistry for SchemaCreator to be able to configure itself. Like I said above, I worry about each and every SchemaCreator implementation (and the other delegate implementations) having to do this on their own since 90%+ of these config options are the same. The other option I see is to have the "driver" do that all parsing/interpretation and passing a parameter-object representation of that into the SchemaCreator, etc.