March 15, 2012 2 Comments
I’m wearing the hat of toolkit producer these days and I’m responsible for delivering a number of outbound JDBC Advanced Integration Services.
Another team member is working on another toolkit, which also implements JDBC AISs.
Both toolkits need the JDBC connector module to compile, and both toolkits will bundle the JDBC RAR (embedded adapter).
This arrangement creates two interesting problems. One at ID workspace compile time, the other at runtime deployment time.
When I create the outbound JDBC import on my toolkit implementation module, the JDBC connector project with the adapter RAR is created, and in order to compile the toolkit, this project has to be associated with it or its dependencies.
So I associated the connector with my toolkit. Splendid.
Now, when I bring into my workspace the other team member’s toolkit, which also has the connector associated with it, things get hairy. Process Center tells me the connector already exists in my workspace, and I say “fine, makes sense, don’t bother loading it to my workspace a second time then” and I deselected it from the projects to bring in.
But then, what happens is, the connector is associated with only one of the toolkits, and my ID workspace can’t build. Joy.
To make matters worse, the runtime starts moaning about duplicate contributions, along the lines of “CWYBC_JDBC is already installed”.
Now, we can install the rar standalone on the server and that would resolve the deployment issue, but we still need a way to build the toolkits.
So what we did is factored out the connector project into a third toolkit and made both my toolkit and the other team member’s depend on it.
This approach worked fine, the connector module is associated with a single toolkit and that solves the build problems, and, somewhat counter intuitively, even though both our toolkit implementation modules dependencies ask for the connector project to be embedded, the deployment works OK as well.