Community
Participate
Working Groups
While trying to use the feature described here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=140816 which is intended to allow jars bundled in plugins to be used as JDBC drivers, we discovered that it doesn't work if the plugin is bundled as a JAR. That is, if the relative path must ultimately point into a JAR archive rather than a sub-directory of the eclipse/plugins dir.
It would be ideal if the extension point could allow pointing at the plugin jar itself (allowing distribution of jdbc jars as proper osgi bundles). That was the first thing we tried. That didn't work. Then we tried a jdbc driver jar inside a jarred plugin. That didn't work either. It seems like the only thing that works is a jdbc driver jar in an exploded plugin directory. Distributing exploded plugins is not optimal for a variety of reasons, so we'd like to see this issue resolved soon.
This is a good thought and one that we can explore for the "Galileo" or 1.7/2.0 for the June 2009 release
Ok... So forgive my lack of OSGI awareness... Do you have an example of how I would set up something along the lines of distributing JDBC jar(s) as an OSGI bundle? If you look at Derby, there's an example there of how we take the Orbit bundle (which I believe is a binary wrapper of the plug-in) for Derby 10.1, is that what you're looking for? We do that in the driver property provider class (hunt for the plug-in, use the path to the plug-in jar).
> Ok... So forgive my lack of OSGI awareness... Do you have an example of how I > would set up something along the lines of distributing JDBC jar(s) as an OSGI > bundle? You just need to add the various OSGi properties (such as bundle id and version) to the manifest of the jar and can be used as a plain jar or as an OSGi bundle. > If you look at Derby, there's an example there of how we take the Orbit > bundle (which I believe is a binary wrapper of the plug-in) for Derby 10.1, is > that what you're looking for? We do that in the driver property provider class > (hunt for the plug-in, use the path to the plug-in jar). Could you provide some more details on this? I am not following. In our code we have something like the following, which works if the plugin containing the jdbc driver jar is in exploded form. <driverTemplate createDefault="true" emptyJarListIsOK="false" id="oracle.dbtools.dtp.connectivity.db.genericDriverTemplate" jarList="[oracle.dbtools.dtp.jdbc.driver]/lib/ojdbc14.jar" name="Oracle Database 10g Driver" parentCategory="org.eclipse.datatools.enablement.oracle.10.driverCategory" > If I look at the Derby plugin, I see this: <driverTemplate createDefault="false" defaultDefinitionName="%DERBY_EMBEDDED_DRIVER_DEFAULT_INSTANCE_NAME" emptyJarListIsOK="false" id="org.eclipse.datatools.connectivity.db.derby.genericDriverTemplate" jarList="derby.jar" name="%DERBY_EMBEDDED_DRIVER_TEMPLATE_NAME" parentCategory="org.eclipse.datatools.connectivity.db.derby.10_0.driverCategory" valuesProvider="org.eclipse.datatools.connectivity.apache.internal.derby.driver.DerbyDriverValuesProvider101"> I did not find derby.jar as specified in jarList in that plugin. Are you saying there is some magic in the valuesProvider that takes care of locating the jar? Ideally the following use of the existing syntax should work for jdbc drivers packaged as OSGi bundles: <driverTemplate createDefault="true" emptyJarListIsOK="false" id="oracle.dbtools.dtp.connectivity.db.genericDriverTemplate" jarList="[oracle.dbtools.dtp.jdbc.driver]" name="Oracle Database 10g Driver" parentCategory="org.eclipse.datatools.enablement.oracle.10.driverCategory" >
Answering my own question... > I did not find derby.jar as specified in jarList in that plugin. Are you saying > there is some magic in the valuesProvider that takes care of locating the jar? Looking at the valuesProvider code it looks like it is dynamically computing the value for the jarList attribute. Presumably the value in plugin.xml (plain derby.jar) is never actually used.
Well, that's not exactly true. The "derby.jar" value that's in the jarlist of the driver template IS used, but only if the values provider doesn't find one of the various plug-ins that it's looking for. The values provider gives you a ton more control (like in the Derby case) to look for things like jarred plug-ins. If you grab the derby plug-in from Orbit: http://download.eclipse.org/tools/orbit/downloads/drops/R20080611105805/bundles/org.apache.derby_10.1.2.1_v200803061811.jar I believe this is jarred as you would want for OSGI. So if you do something similar, you can save the user a bunch of trouble. The values provider class gets called every time the workbench starts. So if you drop the derby plug-in into the workspace and restart (and no Derby default driver definition was already there), it'll create a default driver for derby with the corrected paths to the plug-in...
I do like the idea of having a simple [plugin] syntax (with no path) to indicate that it should just use the plug-in jar. But that would only apply to fully jarred plug-ins I'm guessing. So you'd still have to do the path thing with unjarred plug-ins.
Created attachment 108765 [details] possible patch Hi there... So here's a possibility for how your simple [plugin] case might work. It works for the jarred Derby Orbit plug-in and for the Apache Derby Core plugin that has the derby.jar split out (i.e. non jarred). Let me know if it works for you. Hopefully will simplify things. --Fitz
Any thoughts on this fix?
Larry, can you review this patch?
Brian, the patch looks good.
Delivered as tag v200812110730
