Split Configuration Schema Generation

[Samir Faci]

I have a use case where I'd like to use 90% of the same configuration to generate two different libraries.

So, I'm using maven to build our library and I have one large xml files that defines all the settings.  

ie.

 <configuration>

<configurationFile>../jooq_config.xml</configurationFile>

 </configuration>

Now, what i'm running into is that most of that file is all good, but I'd like to create a new library that we can migrate to, that uses a new package name and different settings and uses Java8 Time Objects and so on.

For example:

 <javaTimeTypes>false</javaTimeTypes> should be flipped in the new library.

Forced type like these need to be omitted

 <forcedType>

                            <name>TIMESTAMP</name>

                            <types>(?i:timestamp\ with\ time\ zone)</types>

</forcedType>

but this:

                        <forcedType>

                          <userType>com.fasterxml.jackson.databind.JsonNode</userType>

                          <binding>biz.foobar.mip.PostgresJsonbBinding</binding>

                          <expression>

                                integration\.service_process\.result

                          </expression>

                          <types>jsonb</types>

                        </forcedType>

is needed. 

I was wondering if there was a way of include snippets of XML?   I don't mind maintaining two xml files but there is a lot of common code where we white list database tables in the <includes/> tag 

and <schemata/> that I really want to avoid maintaining two mirror version of each one. 

Is there a recommended pattern to use that allows me to do this without having to duplicate data?

--

Thank you
Samir Faci

https://keybase.io/csgeek

[Lukas Eder]

Hi Samir,

I suggest you look into pre-processing your config from a common base XML file, adding the project-specific parts using e.g. XSLT or any other templating utility. This way, you'll be in full control, regardless of the complexity of XML merging that you plan to implement.

The request of adding something like that to jOOQ frequently pops up, and I do feel that this will just lead to a very over engineered code generation XML management API, which will be hard to maintain, and still not cover all the merging edge-cases that people might have.

Hope this helps,

Lukas

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Samir Faci]

Okay.  

Thanks Lukas, that's fair enough.  It makes sense to have a pre-post process task rather then complicating the Jooq code base.

Sorry for the late response on this.  Not sure I'd want to use XSLT, but we'll figure something out.

--

Samir