[teiid-dev] Teiid Eclipse Plugin

[Sanjay Chaudhuri]

Sumanth,

As part of the generator wizard, I am working on something similar to GWT. I
didnot quite understand differences between (A) and (B), because other than
different screen layouts, both GWT and JUnit wizards comes with a default
one and allow the users to change to a different one. On Junit it's a radio
button and on GWT it's a drop-down. I guess GWT's strategy is better when
you have more available versions to choose from. The core plugin I am
developing will be responsible for:
1. Register available CDKs
2. Template Project generator

You may work on the cdk wrapper plugin which injects the classpath to the
environment (differenciator should probably be the version number; may
something like: *Teiid CDK [1.6] *) and also uses extension point to
register itself to the core plugin. I have not yet come up with a schema;
feel free to do it incase you want to and we can discuss. I guess the
important functions these CDK plugins should support are:
*String getName();
String getVersion();
String getDescription();
IPath getInstallationPath();
IClasspathEntry[] getClasspathEntries();*

Thanks

Sanjay



On Thu, Oct 22, 2009 at 1:13 PM, Sumanth P K <sumanth.technical at gmail.com>wrote:

> Sanjay / Ramesh,
> I just wanted to summarize what had been discussed so as to make sure that
> I have understood properly:
>
> 1) We would have the CDK plugin have the necessary jars within it (possibly
> till we start phase 2, as specified in the discussions, when we will have
> more options to choose from).
> 2) The plugin would register a container similar to JUnit (it would have
> all the jars bundled within the plugin available by default.).
>
> If we are to enable the support of multiple versions of Connector-Api (and
> hence multiple CDK plugins) at the same time:
> A) We can have a container (similar to JRE, JUnit, GWT) defined for each
> version and to differentiate between them have the container version
> appended to the name of the container (something like TeiidCDK6.1,
> TeiidCDK6.2 etc).
> B) Or have it something like JUnit where by default one version is selected
> and give the user the option to change it to another version.
>
> The point to note here is that in either case the paths would be fixed
> (i.e. within the corresponding plugins). The difference is in the number of
> container entries available for the user (and the way the screens would
> look).
>
> Let me know the direction to proceed.
>
> Thanks,
> Sumanth.
>
>
>   On Wed, Oct 21, 2009 at 1:24 AM, Ramesh Reddy <rareddy at redhat.com>wrote:
>
>>   On Tue, 2009-10-20 at 14:38 -0500, Sanjay Chaudhuri wrote:
>> > >> 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.
>> This is the bundled approach I mentioned before. That is fine for now,
>> as we go on to execution phases you will have other options to choose
>> from to have the out of the box experience which is important.
>>
>> _______________________________________________
>> teiid-dev mailing list
>> teiid-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/teiid-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/teiid-dev/attachments/20091022/caba818b/attachment.html