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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/teiid-dev
>>>
>>
>>
>