Re: [teiid-dev] Teiid Eclipse Plugin
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
>
Attachments:
- attachment.html (text/html — 4.7 KB)