Hi Christopher, I'll CC this to the user group if you agree? I think this is of interest to a broader public.
> I recently written a DDL-to-"custom-domain-model" > converter for our model-driven web framework. It > only supported the domain-model to ddl approach > until I implemented the jOOQ codegen. That's a nice use case. How did you experience the jOOQ-codegen functionality for that use case? If you have any suggestions, feel free to let me know. I focus my developments on the main use cases (using jOOQ as a database abstraction). But of course, there might be room for improvement in the schema browsing and code generation API... So if you have any ideas, please drop a line on the jOOQ user group. > I'm not sure about your checkin policy. I can fully understand that > you need time to trust me. I propose that I can do the steps 2), and > 4) completely on my own and send you the results later. For 1) and 3) > I can send you a patch or instruct you with the neccessary changes. That would be a good plan. You can always add attachments to the ticket: https://sourceforge.net/apps/trac/jooq/ticket/104 Or send them by email to this thread. > The first steps requires some project layout changes. If you don't > like this we can adjust maven to obey your configuration over his > conventions but I wouldn't recommend that. The changes are for example > "src" to "src/main/java" and "test" to "src/test/java" and so on. I can live with that. > My experience is: It's a lot easier to > completely detach from ant and replace with Maven. I'm sure you'll > appreciate this step after a while :-) (This doesn't mean losing > support of your Ant integration (jOOQ-taskdef)). I trust you on that. As long as the code generation still works with Ant after a Maven integration, I'm happy, even if this would mean some restructuring of the ant task. I can put instructions in the release notes and on the documentation wiki, if anything needs to be changed. > Step two consists on two smaller steps: Analyzing the current > dependencies of jOOQ replacing them with the matching dependencies of > maven jOOQ doesn't really have any dependencies. The only "light" or "hidden dependency" that might be worth talking about is log4j. If jOOQ finds log4j on the classpath, it will use that for logging. Otherwise, the java.util.logging package is used. I might add further abstraction on that in the future, but right now, I wouldn't consider it to be a dependency: https://sourceforge.net/apps/trac/jooq/ticket/139 So I think you could consider jOOQ a leaf in the Maven dependency tree. > [...] I hope you get the point! Yeah, I'm a dependency-maven too, just not with Maven :-) I've written an XSL transformer, that generates ant build scripts from Eclipse .classpath files. This was much easier than starting to use Maven for that one project. But for jOOQ, Maven is the way to go, of course. > Step 3: [...] You have to decide. I would heartily recommend > the folder structure, and trying to get into the official maven repo. > I don't now much about the proposal of getting into the maven central > repo, but maybe we find out together :-) The best solution is the most general one and the one that's most easy to maintain. I'm guessing, this would be the maven central repo...? > Step 4: This will be the easiest step. I'll write a MOJO which can run > out-of-the-box, based on the zero configuration approach (except > connection providing). But also completely customizable > (includes/excludes, master-data, we can discuss the configuration > later). Sounds good to me > What do you think about the steps? Are you willing to change a few > things like project layout and ant build system? You can try this a > few weeks offline and then decide if you like it. Looks like you're right on track! Thank you very much for your detailed feedback. I'm eager to learn something about Maven and to see that being integrated into jOOQ. Cheers Lukas
