Generating multiple java Enums from a single table, using JOOQ -

i have table in database schema contains configuration information application i'm building. i'd generate number of enums based on contents of table. i'm using jooq in build scripts generate other, standard jooq classes same database, , hoping can obtain new functionality through jooq.

for example, if table contained following data

product        component    presentationorder hydroproduct   boat         1 hydroproduct   canoe        2 hyrdoproduct   ship         3 landproduct    car          1 landproduct    bike         2 

then i'd want generate 2 enums

hydroproduct.components { boat, canoe, ship; } 

and

landproduct.components {car, bike; } 

where hydroproduct , landproduct packages, , enums both called components.

the precise details grabs (e.g. i'd fine different naming conventions, suggestions welcome), principal (two enums 1 table, based on data therein) is, @ least question, thing need.

having read jooq docs, see generating enums once part of jooq, , removed. can't see "obvious" way of doing want in jooq, it's pretty amazing library, i'm guessing there might one.

edit

a number of commenters have questioned overall approach, understand. i'd avoid kind of conversation - it's impossible me debate level of design on forum. approach (code generation based on ddl , sql) tested within organisation, , has had large amount of design scrutiny.

just record, here's outline pipeline. i'm putting in because appreciate people have spent time considering original question, , i'd make clear how question fits our overall dev system.

project 1 holds bootstrapping classes, ddl , sql scripts contain data constants our overall system uses. it's output includes (amongst other stuff), .jar files containing compiled versions of classes generated. these comprise core agreed vocabulary rest of our system uses communicate.

project 2 holds java source code, makes use of various artefacts generated project one. before project 2 ever gets compiled, artefacts project 1 can assumed have been generated. so, example, enum generated data held in project 1 can used, @ compile time, in project two.

our build scripts build project one, , make outputs available project two. includes generating eclipse project files users of project 2 can check-out, build, , open eclipse branch of project , "just works".

there other projects (including in different languages, e.g. javascript) make use of artefacts generated project one.

the key benefit of approach that, when data in project 1 changes, , definitions of classes , enums in project 1 therefore change, project 2 reflects change compile-time errors, rather run-time errors. benefits of in practice absolutely enormous. there setup-cost, yes, in our experience tools jooq (which use generate outputs of project 1) have made incredibly more productive used be.

this case ship desktop, in-browser, , j2ee components , need talk together.

this won't exhaustive answer, question bit opinionated, can provide authoritative background on history of feature in jooq:

having read jooq docs, see generating enums once part of jooq, , removed.

yes, reason removal precisely because then-existing implementation far sophisticated enough accommodate, instance, particular use-case.

code generation ad-hoc "science" , extremely difficult maintain configuration api backwards compatibly, can accommodate possible use-cases... instance, fact want map parts of master data onto packages, class names being constant, ordering custom rather particular, not generic.

furthermore, should generated enums referenced from? original implementation replaced foreign keys (e.g. integers) enum references in generated code. might not @ want in cases, want join master data in raw form, not generated enum.

long story short, eagerly added feature in jooq 1.x, extremely hard maintain during major internal refactorings needed create jooq 3.x, which why dropped.

i can't see "obvious" way of doing want in jooq, it's pretty amazing library, i'm guessing there might one.

not out of box. i'd recommend using templating language velocity or xtend , generate code manually part of build. could, in fact, generate custom converter or binding implementations bind enums relevant referencing columns.