<div class="gmail_quote">My thoughts inline:</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">On Tue, Oct 20, 2009 at 2:17 PM, Ramesh Reddy <span dir="ltr"><<a href="mailto:rareddy@redhat.com">rareddy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">On Tue, 2009-10-20 at 10:45 -0500, Sanjay Chaudhuri wrote:<br>> Yes I understand. I was trying to compile both the jdbc and the<br>> loo-back connection, and was getting into issues while compiling in my<br>
> workspace. What jars should be used by the end-user to develop any<br>> connector by an user from compilation standpoint ? I was using<br>> teiid-6.2.0-M3-dist and teiid-6.2.0-M3-cdk-dist for my tests.<br></div>
My intent is to replace the CDK-DIST with your plugin distribution. The<br>user brings in "teiid-connector-api" and "teiid-core" into your plugin<br>however they grab hold of the jars or design the project as Maven<br>
project, where maven would know to grab jar from here<br><a href="http://repository.jboss.com/maven2/" target="_blank">http://repository.jboss.com/maven2/</a>. automatically. I prefer the maven<br>approach.<br>
<div class="im">>>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<br>
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.</div>
</blockquote>
<div> </div>
<div>><br>> It is posible in eclipse to have the product level classpaths injected<br>> automatically in the environment through the plugins. (Eg. Right<br>> clicking any Java project, click Properties; click Add Lbrary and you<br>
> would see libraries JUNIT, GWT, JEE libraries injected by the relevant<br>> plugins. I was thinking in similar lines, so users do not need to<br>> search for required libraries and have those added manually and this<br>
> would also facilitate quick-fix operation, etc along with be able to<br>> maintain different jars version across different cdk versions. The<br>> generated template will thus be self sufficient and be erady for<br>
> development.<br></div>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">This is nice, but that would make your plugin to bundle above jars<br>inside your distribution, or make available in a separate plug-in. Both,<br>
IMO is better not to do, as they then tied to each other.<br>>> 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.<br>
</blockquote>
<div>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.</div>
</div><br>