[teiid-dev] Teiid Eclipse Plugin

Fri Oct 23 14:01:19 EDT 2009

Sumanth,

The main hassle of working with eclipse is indeed getting HelloWorld
examples for every use-cases. I had put in last few years into eclipse
development; in my initial years and now, I go back to core eclipse sources
if I have some doubts; I guess that the best place to look into as it has
all the use-cases you can think off !!

My thoughts are kind of standards I see around in other commercial
implementations and also usability from a developer's perspective when I use
these plugins as a developer. Probably this is not the right forum and we
can take it offline; however I work with several implementations of the same
use-case from different companies and can clearly see what is productive
being using one set of plugins over other. I do not know if there are more
than one implementations of the CVS plugins other than eclipse. Assuming
there were, then working with both sets will give you a clear perspective
what functionality is better in one over the other. I try to frame a
solution looking into what I wanted as developer and was missing from these
plugins and also taking best of all worlds for a new one !!!

Thanks

Sanjay
On Fri, Oct 23, 2009 at 12:24 PM, Sumanth P K
<sumanth.technical at gmail.com>wrote:

> Sanjay,
> The difference between option A and options B is this: In the case of B, we
> would have a wizard very similar to GWT or JUnit (drop down to choose the
> version to which the user wants to point to). As a result of this design, on
> the *Add Libraries* dialog, there would be only 1 entry. In A there would
> not be a dropdown or radio button. The user would have to select the
> container directly and hence there would be multiple entries (one for each
> version) on the *Add Libraries* dialog. Now that we are interested in
> option B let us proceed further in that direction.
>
> *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 guess what you meant to say here is that the CDK plugins would
> register with the core plugin and identify themselves with the help of
> version numbers. The core plugin would decide on the entry it should point
> to by default.
>
>>>Sanjay: Yes. I guess the best one to use by default is the highest
version number available from the registered plugins.

>
> I have been in the process of implementing a container entry by going
> through the documentation. The amount of information in the Eclipse Help is
> not much. If there are any good places where I can get information please
> let me know. I have been looking on the web but could not locate good
> sources.
>
> Also, there are a list of functions that you have mentioned. Can you let me
> know from where you got that information?
>
> Thanks,
> Sumanth.
>
>
> On Fri, Oct 23, 2009 at 12:42 AM, Sanjay Chaudhuri <
> email2sanjayc at gmail.com> wrote:
>
>> 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/20091023/8469b185/attachment-0001.html 