Community
Participate
Working Groups
Created attachment 85371 [details] deafalt definitions for commonly used drivers please add a set of default driver definitions so the user can easily create a connection. Please add the attached code in the plugin.xml file in the org.eclipse.datatools.connectivity plugin
Hi there... Have a couple of issues with your approach... 1) By putting this into the connectivity plug-in, we have a number of problems... a) Connectivity should not have dependencies on Enablement, as we can't guarantee that the Enablement feature will always be included b) There's no way to customize this on a per-installation basis... For example, IBM may only want to auto-create IBM-related drivers, and Sybase may only want to create Sybase-related drivers, as opposed to just by default creating every single one 2) This would need to be done on a per-consumer basis... (see 1b)... So I would recommend that if you want to include a plug-in that simply does this for your components...
Brian, we agree with you about the connectivity/enablement dependencies The right approach would probably be adding a default driver for every specific enablement plugin, so that the user does not get an error when try to create a new connection saying that the driver is not found. The simple user would expect to be able to create a connection withou having to install DB drivers, as he probably doesn't know how to do it...
Another concern I have is that if we have each enablement project provide a default driver definition via this mechanism (which was designed to do just that)... There are going to be a ton of drivers showing up in the list that the user may never actually use... Do we maybe want to do a check the first time the drivers UI is used to see which drivers the user wants to create/update by default? (A bit intrusive, but an option nonetheless...) I don't want to just blanket the install with a bunch of non-functioning drivers because they don't have accurate jar lists... And I believe that's why we haven't done this in the past.
Having "tons of drivers showing up in the list" isn't better than seeing zero drivers? especially if "tons" are reduced to a dozen in our case that each connection provider supplies his own enablement plug-in and attaches the jar driver file. Also we can define one driver for each provider which minimizes the number of predefined drivers to 5-6. Anyway, this issue came from many customers that couldn't understand how to configure in a fast way a simple working connection.
But we can't guarantee that each enablement plug-in contributes its own driver jar... Due to IP, we are stuck... If the EPL and GPL licenses are in conflict, we can't do anything there... If it's commercial software (like an Oracle, SQL Server, IBM, or Sybase driver), we're stuck there also... So the odds are that we CAN'T ship a driver jar with each of the enablement projects. I won't rule it out from ever happening, but it's a long shot unless licensing issues resolve themselves. If we want to go this route, we could ask each vendor to provide a downloadable driver plug-in that does this and point users to them for download or via an update site. But there isn't an easy solution to this.
You are absolutely right about that, we do have licensing problem with providers, hope it will be resolved soon. I guess we will need to handle it as you suggested when there will be solution for this issue.
Some of this has been resolved with work done for 105552 and 201682. We now have the ability to write a driver values provider class (and associate it with a driverTemplate or driverTemplateOverride extension) that can update the jar lists with platform-appropriate paths if plug-ins are in the installation that wrap the given drivers as well as change the createDefault flag if that type of plug-in is available. An example of that has been delivered for Derby. If the driver plug-in wrapper from org.apache.derby is installed in the workbench before the user starts the workbench, the Derby Embedded & Derby Client drivers are created by default. (If the Derby driver plug-in is added to the installation AFTER the workspace is created, the jars are picked up when the user creates a new Derby driver so no further jar file configuration is required.) So this should hopefully make it easier for vendors to provide drivers for an Eclipse installation and for those drivers to get picked up by DTP and react accordingly. Because of the licensing/IP issues, we're stuck with what we can provide in a default DTP installation, but if you have those jars available for redistribution in a Zend product, you would be able to provide plug-ins wrapping them and a DTP driverTemplateOverride that provides a Driver Values Provider class to automatically populate the jar lists and create the driver definitions by default. Hopefully this will help the situation. This functionality will be in the DTP 1.6M5 drop next week for you to look at. --Fitz
As much as I'd like to do this for Ganymede, I'm still concerned with creating all of these defaults without driver jars provided. We've gone further to provide additional methods for adopters/extenders to provide plug-ins and classes to create the default instances if the jars are in a known location, but it's still an open concern. If you take a look at the Derby driver situation now, for instance, we've created a new values provider class that checks to see if one of two plug-ins wrapping the jar happen to be in the installation. If they're there, they go ahead and create the default drivers. If Zend is providing plug-in wrappers for each of the driver jars, it would be trivial to follow the same pattern for each driver plug-in so you could create your defaults for the user.
