With the JCA work, the current rar packaging for connectors presents a few issues with the old way we used to manage dependencies. For example if I want a custom JDBC connection which introduces a new connector binding property and custom code, then I would need to create a copy of the jdbc rar, add my custom jar, and modify the ra.xml file. Since the jdbc rar contains our jdbc connector jar, now there are two copies of that jar. Management of patching becomes an issue.
Even in a simpler case which is providing my own implementation of capabilities of the Translator class would require either that I place my custom code in a higher level class loader or create a copied rar and add my custom jar. In the former case there is the possibility of class loading issues, in the latter there's the same duplicated dependency issue.
It doesn't seem that there is a simple answer to this problem. Options include:
1. Elevating all of the built-in connector jars to the same class loader as the connector api. Now there is a single place to manage/patch the dependency. This path assumes that the xml connectors will be refactored to contain only minimal external dependencies, otherwise they would still need to be managed as rar.
2. Investigate OSGI support (http://jbossosgi.blogspot.com/2009/06/jboss-osgi-runtime-as-integration.html) so that we can use declared dependencies. However this is a poor fit with the JCA model and adds additional complexities.
3. Treat all custom connector work, even extensions of our connectors, equally. Each new type requires a rar and any dependency maintenance becomes the responsibility of the customer.
I have uploaded fresh changes on the cdk plugin. The plugin would now take a
repository (typically a maven repository) and be able to download dependent
jars and add to classpath automatically while creating the template. The
names of the jars and the location currently needs to be specified, as
currently there does not exist any maven repository for teiid on
The downloaded plugins are put in *lib* directory of the generated project.
The generated template also uses the old way of using cdk-dist plugins for
adding dependencies. This feature will be removed in future once we have the