You really mix Hibernate and JDBC (or Jooq) stuff within the same unit of work? This didn't work too well for us; it's all too easy to have cross-pollution between Hibernate and JDBC data (mostly caching problems, but sometimes issues with JDBC data sent to helper functions that invoke Hibernate). I have mixed feelings about your use case; I can see that it is desired, but I'd rather push people towards completing the migration, and having the ugliness of full qualification in the code helps with that.
>> my recent experience with Maven indicates that >> sooner or later, you'll be forced to use a >> repository manager anyway. > > true. but we should not force people, when they > consider switching from e.g. hibernate to jOOQ > (which is *good*), to first setup a nexus repo > in the company, You should already be using Maven because you have Hibernate. Or at least something that uses Maven repositories. Either way, importing Jooq should be just as easy or complicated as importing Hibernate. > convince the security team (optional), That should be easy. It's essentially just part of your set of build tools. > then install some tiny one-liner-payload naming > strategy using a separate project, run "mvn deploy" > with the proper account --> just to show off to the > team how great the migration to jOOQ would be :-) That's the "Maven way": if something doesn't fit into its (rather narrow) definition of build lifecycle, fragment the project into mini projects that each deploy to the repository. If you don't want to go that route, Maven is not the right tool for your situation (I got that straight from the horse's mouth when I asked about exactly that issue on the maven-users lists). I switched my freetime project to Gradle and found that accessing Maven repositories from there was entirely painless. Maven Central also lists Buildr and Ivy as alternatives for building Java projects (plus Groovy Grape, Grails, and Scala SBT - funny how build tools have become so language-centric nowadays). Our conversion to Gradle isn't complete yet, but we did find that it has zero issues with including a binary jar in a build. No need for an extra project, no need for a repository (we're keeping the Maven Repository Manager we set up as a cache, but it's inessential to the build process now). -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
