Help

Per HHH-2412 and its design discussion I have been working on supporting JDBC4 in Hibernate. Initially I had planned on adding this in 3.6, but now leaning toward 3.5 Anyway, as outlined on the design wiki, I initially thought to add this support as separate modules. However, I quickly came to the realization that using separate modules would actually require users make an explicit choice wrt an extra jar. Especially considering that I could make Hibernate code make this determination programatically, I really did not like that aspect to using modules here. So I started looking for alternatives.

As I normally do, I started by thinking of just the ideal outside of any build structure or tool. So to my mind the best option here seemed to include compiling JDBC4 support targeting JDK 1.6 and JDBC3 support targeting JDK 1.4 and then bundling all that code into a single jar. The code which decides which feature-set to use uses reflection anyway, so there is no issue with having both in the same jar as long as only the correct classes actually get loaded (and anything else would be a bug in this determination code).

Well unfortunately it turns out that Maven does not really support such a setup. In the common case I think you'd set up multiple source directories within that main module and run different compilation executions against them with different compiler settings (source/target). This Maven explicitly disallows (see MCOMPILER-91 and its discussion for details).

Two workable solutions were presented to me (workable in that Maven could handle these):

  1. Use a single source directory, but configure 2 executions of the compiler plugin taking advantage of includes/excludes to define what to compile targeting 1.6 and 1.4. The issue here is that this is not good fit for IDEs.
  2. Split this into 3 modules (one each for JDB3 and JDBC4 support plus another for commonality to avoid circular dependencies with core). Core would then pull the compiled classes from these 3 modules into its jar. Seems overly complicated to me just to work around a self-imposed limitation of Maven. And sorry, I just don't see how this constitutes a messed up system as indicated in that Maven discussion.

Anyway, I really hope someone has other suggestions on better ways to handle this with Maven. Anyone?

9 comments:
 
22. Sep 2009, 14:46 CET | Link
Elias Ross

As a third option, I was thinking you could always build the patched version of the compile plugin as described on the mailing list. Build with that. Then send out a notice to everybody and tell them to use your version. Watch chaos ensue. ;-)

Maven really wants you to create lots of little bitty projects, which drives me crazy, but I suppose works out okay most of the time. So if I were you I'd go with 2.

ReplyQuote
 
22. Sep 2009, 15:08 CET | Link
Christoph Brill | egore(AT)gmx.de

I've used multiple source directories using the build-helper-maven-plugin. It was more or less the same than you want to do.

Another option is merging jars multiple jars into one executable jar using the maven-shade-plugin. This would enable you to develop the jdbc3 and jdbc4 as separate jars and generating a hibernate.jar which contains either of it (depending on the profile you've chosen).

I'd go this way: Build a jar containing both jdbc3 and jdbc4. At startup check which java version is running and load the appropriate jdbc classes. The core itself would only work against a common interface shared by the jdbc3 and jdbc4 classes.

Anyway, I really like to see that you ask for opinions from the community. Keep it up!

 
22. Sep 2009, 21:42 CET | Link
Christoph Brill wrote on Sep 22, 2009 09:08:
I've used multiple source directories using the build-helper-maven-plugin. It was more or less the same than you want to do.

Actually it does not from what I have been told because you cannot define separate compile settings for the various added source directories.

Christoph Brill wrote on Sep 22, 2009 09:08:
Another option is merging jars multiple jars into one executable jar using the maven-shade-plugin. This would enable you to develop the jdbc3 and jdbc4 as separate jars and generating a hibernate.jar which contains either of it (depending on the profile you've chosen).

The issue here imo is that really it is the hibernate-core jar where all this should go. But its a chicken-and-egg issue in regards to these jdbc3 and jdbc4 jars since they would depend on core, but core would need to depend on them in order to bundle their classes. This is essentially option number 2 I listed above, and as stated is way over-complicated for this situation imo.

Christoph Brill wrote on Sep 22, 2009 09:08:
I'd go this way: Build a jar containing both jdbc3 and jdbc4. At startup check which java version is running and load the appropriate jdbc classes. The core itself would only work against a common interface shared by the jdbc3 and jdbc4 classes.

Well this is largely what is being done (did you see the design wiki?). The problem is how to present this to the user in terms of jars they need to load into their environment.

 
03. Oct 2009, 03:28 CET | Link
Jaikiran
The #1 approach of using 2 separate compiler executions with include/exclude sounds easier to me. Any idea, what kind of issues does it causes with IDEs?
 
06. Oct 2009, 05:30 CET | Link
Jaikiran wrote on Oct 02, 2009 21:28:
The
  1. 1 approach of using 2 separate compiler executions with include/exclude sounds easier to me. Any idea, what kind of issues does it causes with IDEs?

IDEs use different terminology, but I'll use IntelliJ's as it matches pretty closely with Maven's here though the issue is the same in Eclipse as well. In IntelliJ, a project is made up of modules; it is in the modules where you define the JDK to use. Even though you can define multiple source directories within a module in IntelliJ, they all share the JDK assigned to that module.

So say you were to have JDK 1.4/1.5 (JDBC3) and JDK 1.6 (JDBC4) targetted code in the src/main/java directory. Aside from being a Maven hack, this is not the correct way to model this build. And an attempt to load that into an IDE is going to complain (if the module targets 1.4/1.5, the 1.6 targetted class will not compile, and visa versa).

 
06. Oct 2009, 08:05 CET | Link

So the second option sort of works using the shade plugin. You just have to be willing to accept some minor annoyances such as the fact that 3 modules (common, jdbc3 and jdbc4) are indeed needed, that these 3 modules still make there way into your local repo (and you have to explicitly configure the deplpy plugin to skip these modules or else they show up in the deploy repos too) and that this generally seems a bit more complex then it outght to be.

The verbiage I came to after discussing this with numerous folks is that we really have a 2-way set of dependencies here, but that the dependencies are isolated to phases. That is ideally JDBC3 and JDBC4 would have compile-time dependency on CORE, while CORE would have a package-time dependency on both JDBC3 and JDBC4 in order to package those classes into its jar. However Maven does not allow limiting dependencies to phases and even if it did it actually performs every lifecycle phase on each module before moving on to the next module.

 
21. Jun 2014, 16:08 CET | Link

Drones can be controlled manually on the ground or pre-programmed to run on their own to fly in the air like small airplanes. Theyre currently used for bombing attacks in Pakistan by the U.S. military and for entertainment. growing drone These days the market is filled with all types of bad credit car loans as well as deals in which enable individuals with bad credit to get a car. Most individuals however believe that many of them are only slick marketing strategies attempt to benefit from unsuspecting those who have credit car

 
12. Jul 2014, 18:19 CET | Link

A team is nothing without teamwork, and teamwork is hard to achieve when you can't get along with your team mates Crystal x tegal

 
29. Sep 2014, 04:41 CET | Link
jenny bolton

I have seen your awareness about this theme when you post it and it really gives an informational message to us readers. I am hoping that you will continue writing this kind of blog. Thanks for sharing this information. breast enlargement without surgery book

Post Comment