My thoughts inline:
On Tue, Oct 20, 2009 at 2:17 PM, Ramesh Reddy <rareddy(a)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.