On Tue, Oct 20, 2009 at 2:17 PM, Ramesh Reddy
<rareddy@redhat.com> wrote:
On Tue, 2009-10-20 at 10:45 -0500, Sanjay Chaudhuri wrote:
> Yes I understand. I was trying to compile both the jdbc and the
> loo-back connection, and was getting into issues while compiling in my
> workspace. What jars should be used by the end-user to develop any
> connector by an user from compilation standpoint ? I was using
> teiid-6.2.0-M3-dist and teiid-6.2.0-M3-cdk-dist for my tests.
My intent is to replace the CDK-DIST with your plugin distribution. The
user brings in "teiid-connector-api" and "teiid-core" into your plugin
however they grab hold of the jars or design the project as Maven
project, where maven would know to grab jar from here
http://repository.jboss.com/maven2/. automatically. I prefer the maven
approach.
>>Sanjay: I was thinking slightly differently. To maintain CDK dist as-is which should not have any eclipse contraints; ie users should be able to build thing by hand just like today they are doing without eclipse plugins in place; a pure java/jar
To have CDK plugins; one potentially just a wrapper to expose the CDK-dist as a plugin. Every new release of CDK-dist will have an updated version of the wrapper plugin. The remaining plugins will provide the core functionalities of Eclipse pltaform. I intend to have the wrapper CDK plugins register themselves through extension-point. As a result, the runtime platform would see different version of CDK that the user may choose to for building a connector.
>
> It is posible in eclipse to have the product level classpaths injected
> automatically in the environment through the plugins. (Eg. Right
> clicking any Java project, click Properties; click Add Lbrary and you
> would see libraries JUNIT, GWT, JEE libraries injected by the relevant
> plugins. I was thinking in similar lines, so users do not need to
> search for required libraries and have those added manually and this
> would also facilitate quick-fix operation, etc along with be able to
> maintain different jars version across different cdk versions. The
> generated template will thus be self sufficient and be erady for
> development.
This is nice, but that would make your plugin to bundle above jars
inside your distribution, or make available in a separate plug-in. Both,
IMO is better not to do, as they then tied to each other.
>> Sanjay: Eclipse plugin is really helpless other than generating templates without the necessary jars in the classpath, so I guess plugin's dependency on the jars is kind of mandatory for development. Even if it is not made implicit, users manually have to do so anyhow; so I was thinking of having it integrated to begin with. And as pointed out above, CDK-sdk will not depend on eclipse. It will be a matter of build process to generate the eclipse wrapper plugin as part of the cdk-dist build.
Also doing all this, does not prevent the user to manually take off the dependency and associate the project to any jar of choice anyhow. I was thinking in those lines to give the users out-of-box development environment.