That looks good. Great Job! That is exactly what I was looking for. The properties class needs some tweaking. For more info on this follow and read "Teiid in JCA Container" thread. I encourage you to read and participate as this directly affects what you are working on too. I created "JCA" branch on the Teiid, but I do not have any check-ins yet. Once I have some commits then you can see clearly what I am talking in the thread. Based on changes for 6.3 release, the XML file we need to change that the format of "ra.xml" and can live in "src/rar/META-INF/ra.xml" location. I am attaching a sample "ra.xml" file. You can make a template xml file out of this and let users add more properties there. Each property on this "ra.xml" file will get a "set" and "get" methods on the "properties" class. Do you think you can come up some kind of properties editor for the connector, where on some pop-up window, you can specify a "property" name, type and optional value, and that value is automatically added to the ra.xml file and add the getters and setters to the properties class? The important thing is keeping them in sync. I do not know if there is anything similar you can extend. This is some good non-conflicting work that can be done by Sumanth while you are doing other stuff. Your call. Also, for the code to host we can either host on "sourceforge" or "github" while we are working, once we get this thing to a good stable stage we will think how we can integrate this into Teiid tools area. On SF I can give you commiter access as we do not use this repo for Teiid code. Let me know. Again great work, and appreciate your work. Let me know if you have questions. Thanks Ramesh.. On Fri, 2009-10-23 at 16:26 -0500, Sanjay Chaudhuri wrote: > Hi Ramesh, > > These are the specifics I am working with to generate the template. > Please let me know if you want me to change something. On the wizard: > - Will take input of the project name and the physical project that > gets created will be connector-projectname. So if HelloWorld is given > as the project name, the created project name will be > connector-helloworld > - Will take input of the package name and the following directory > structure will be created with existing Loopback classes and resources > renamed as shown. Assuming com.example.hello is used: > Project: connector-helloworld > connector-helloworld\.classpath > connector-helloworld\.project > connector-helloworld\pom.xml > connector-helloworld\src > connector-helloworld\target > connector-helloworld\src\assembly > connector-helloworld\src\main > connector-helloworld\src\test > connector-helloworld\src\assembly\bundle.xml > connector-helloworld\src\main\java > connector-helloworld\src\main\resources > connector-helloworld\src\main\java\com > connector-helloworld\src\main\java\com\example > connector-helloworld\src\main\java\com\example\hello > connector-helloworld\src\main\java\com\example\hello > \HelloWorldCapabilities.java > connector-helloworld\src\main\java\com\example\hello > \HelloWorldConnection.java > connector-helloworld\src\main\java\com\example\hello > \HelloWorldConnector.java > connector-helloworld\src\main\java\com\example\hello > \HelloWorldExecution.java > connector-helloworld\src\main\java\com\example\hello > \HelloWorldProperties.java > connector-helloworld\src\main\resources\connector-helloworld.xml > connector-helloworld\src\test\java > connector-helloworld\src\test\resources > connector-helloworld\src\test\java\com > connector-helloworld\src\test\java\com\example > connector-helloworld\src\test\java\com\example\hello > connector-helloworld\src\test\java\com\example\hello > \TestHelloWorldAsynch.java > connector-helloworld\src\test\java\com\example\hello > \TestHelloWorldExecution.java > connector-helloworld\src\test\resources\connector-helloworld.xml > connector-helloworld\target\classes > connector-helloworld\target\test-classes > connector-helloworld\target\classes\com > connector-helloworld\target\classes\com\example > connector-helloworld\target\classes\com\example\hello > connector-helloworld\target\test-classes\com > connector-helloworld\target\test-classes\com\example > connector-helloworld\target\test-classes\com\example\hello > > These are the 3 project source folders and their corresponding output > folders: > src/main/java, target/classes/ > src/main/resources, target/classes/ > src/test/java, target/test-classes/ > > Thanks > > Sanjay > _______________________________________________ > teiid-dev mailing list > teiid-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/teiid-dev

Sure, Thanks. At a minimum take look at the document see how it may affect your stuff. There are some api changes, but you should be good. Eclipse property editor sounds good. Can it be extended for usecase I was talking about? For Source forge, create an account and send me the user-id directly to me separate email. Ramesh..

Sanjay - Please proceed further with the CDK Contributor plugin. I shall start on the sheet-tab properties. From what I understand, we need to create a tabbed display similar to the one that opens up when we open the MANIFEST.mf or plugin.xml in the PDE. Physically there is a single file, but the information is scattered across various tabs. Is the sheet-tab properties going to be used for configuring the config properties elements only or is it that we would need to have the support for all the elements defined in the Connector 1.5 XSD ( http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd)? Thanks, Sumanth. On Sun, Oct 25, 2009 at 4:37 AM, Sanjay Chaudhuri < email2sanjayc(a)gmail.com&gt; wrote: > Hi Ramesh, > > Sure; shall look into it. No matter what the changes are, since I am > maintaining a template file for each of the sources with some configurable > parameters like package-name, etc, which will get substituted based on > inputs by the user through wizard, I do not anticipate any issues. Also the > necessary jars in question for classpaths will potentially be published by > the contributor plugin through an extension point if we land up having > different jar names probably because of different version numbers that gets > appended. The plugin I am developing will be flexible as the dependencies > are mostly loosely coupled except for the template directory structure and > names as well as the files that gets generated. These are currently > hard-coded in the program, which can be very well be put on an external > properties file if we want those to be configurable as well in future. > > Yes, the properties editor definitely can be used to satisfy your > use-cases; the newer sheet-tab properties editor best suits for this. Since > an editor needs to be attached; we can extend the existing xml editor to > display the content as is and intercept to provide our properties view with > all syncs and get/set generated. > > I have a sourceforge account; sending it to you through a separate mail. > > Thanks > > Sanjay > On Sat, Oct 24, 2009 at 5:22 PM, Ramesh Reddy <rareddy(a)redhat.com&gt;wrote: > >> Sure, Thanks. At a minimum take look at the document see how it may >> affect your stuff. There are some api changes, but you should be good. >> >> Eclipse property editor sounds good. Can it be extended for usecase I >> was talking about? >> >> For Source forge, create an account and send me the user-id directly to >> me separate email. >> >> Ramesh.. >> >> >> > > _______________________________________________ > teiid-dev mailing list > teiid-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/teiid-dev > >

On Sun, 2009-10-25 at 01:41 -0500, Sanjay Chaudhuri wrote: > No; I was suggesting to use the existing sheet-tab properties editor > infrastructure of eclipse. If you install the WTP SDK and try opening > any .xsd file, you will see some of the different things that can be > done on the Properties view. Normally it should automatically open up; > else you may use Windows -> Show View -> Properties. Since ra.xml > needs an editor, potentially we can extend the existing XML editor and > also enhance it for being able to address any changes made through the > xml editor also and be able to generate get/set as mentioned by > Ramesh. So users may decide to directly change the xml using the xml > editor or use the properties view. Enhancing the XML editor can also > get fancy by content-assist, problem-markers etc. and potentially this > can be renamed as a specific editor, similar to the plugin manifest > editor, which knows how to handle called plugin.xml > I would not make this too complicated. If we want we can make the "ra.xml" editor as read-only. I am interested only on adding and managing the custom properties. Rest of the ra.xml we can fill automatically. Sanjay>> If UI needs to be done, I guess the efforts are same other than

I am not sure if the current structure of ra.xml is complete; however > based on what I see, some meaningful tab segregations can be done; > Ramesh would be a better person to dictate how he would want to group > the sections. > ra.xml is defined by the JCA spec, it is complete. Since we are targeting properties, IMO we provide way to manage those, that is sufficient. If user edits the ra.xml out of this editor, next time we load the file they should reflect in the editor.

On Sun, 2009-10-25 at 16:55 -0500, Sanjay Chaudhuri wrote: > Sanjay>> Basic properties editor does not have the sheet-tab > view. So if basic key/value pair is enough, then we can stick to the > basic one as I mentioned above. Agree. We need to also have the "type" and "description" information along with key/value. Value and description values are optional.

On Sun, 2009-10-25 at 17:51 -0500, Sanjay Chaudhuri wrote: > Ok; then to keep things very simple, we can have a simple editor which > potentially can be a table/tabletree like properties view; however > with 4 columns instead of 2, viz, key, value, type and description. I > bring up tabletree as an option, incase you want the hierarchy to be > visible, which I think can be important because the file is a xml and > I saw it having a good nested structure. > All properties are at the same level in the ra.xml file, since we are only dealing with properties section of the ra.xml, the tree is optional. Once we make it hierarchical don't you have to use XMLEditor instead of the Property editor?

The idea of Custom Editor looks good to me. That way the user would have the flexibility to use the editor of choice. I shall proceed in this direction. On Mon, Oct 26, 2009 at 8:47 PM, Sanjay Chaudhuri <email2sanjayc(a)gmail.com > wrote: > The eclipse properties editor comes with 2 columns and that cannot be > changed; so we need to have a new custom editor which will be look like the > properties editor, however have 4 columns instead of 2. By default, we can > wire eclipse to open up ra.xml in our own custom editor, however users can > still open it up in default xml editor with the "Open With" option. If we > only need to address the porperties section, we can have a table with each > properties in each row. > > > On Mon, Oct 26, 2009 at 9:35 AM, Ramesh Reddy <rareddy(a)redhat.com&gt; wrote: > >> On Sun, 2009-10-25 at 17:51 -0500, Sanjay Chaudhuri wrote: >> > Ok; then to keep things very simple, we can have a simple editor which >> > potentially can be a table/tabletree like properties view; however >> > with 4 columns instead of 2, viz, key, value, type and description. I >> > bring up tabletree as an option, incase you want the hierarchy to be >> > visible, which I think can be important because the file is a xml and >> > I saw it having a good nested structure. >> > >> All properties are at the same level in the ra.xml file, since we are >> only dealing with properties section of the ra.xml, the tree is >> optional. Once we make it hierarchical don't you have to use XMLEditor >> instead of the Property editor? >> >> >> >

My answers inline. Thanks Sanjay On Thu, Oct 29, 2009 at 11:57 AM, Sumanth P K <sumanth.technical(a)gmail.com&gt; wrote: Sanjay, I have been looking regarding the custom editor implementation. Which one from your experience in Eclipse Plugin Development is a better approach: 1) Building a Custom Editor by extending from the Eclipse Text Editor OR >> What I understood from Ramesh is that he is looking for a simple editor which will have 4 columns, so extending the text-editor will not work. Should be a new editor with a table and cell editors to support different use-cases; more like Property View with 4 columns instead of 2 and should be a table instead of a table-tree. 2) Using the EMF approach where we define a model, tansform it into an Ecore Model and build the editor for it. >> The effort would be too high, and also such an elaborate framework is an overkill when all we are interested to do is create/update key/value pairs with 2 more attributes. Thanks, Sumanth. On Mon, Oct 26, 2009 at 10:46 PM, Sumanth P K <sumanth.technical(a)gmail.com&gt; wrote: The idea of Custom Editor looks good to me. That way the user would have the flexibility to use the editor of choice. I shall proceed in this direction. On Mon, Oct 26, 2009 at 8:47 PM, Sanjay Chaudhuri <email2sanjayc(a)gmail.com&gt; wrote: The eclipse properties editor comes with 2 columns and that cannot be changed; so we need to have a new custom editor which will be look like the properties editor, however have 4 columns instead of 2. By default, we can wire eclipse to open up ra.xml in our own custom editor, however users can still open it up in default xml editor with the "Open With" option. If we only need to address the porperties section, we can have a table with each properties in each row. On Mon, Oct 26, 2009 at 9:35 AM, Ramesh Reddy <rareddy(a)redhat.com&gt; wrote: On Sun, 2009-10-25 at 17:51 -0500, Sanjay Chaudhuri wrote: > Ok; then to keep things very simple, we can have a simple editor which > potentially can be a table/tabletree like properties view; however > with 4 columns instead of 2, viz, key, value, type and description. I > bring up tabletree as an option, incase you want the hierarchy to be > visible, which I think can be important because the file is a xml and > I saw it having a good nested structure. > All properties are at the same level in the ra.xml file, since we are only dealing with properties section of the ra.xml, the tree is optional. Once we make it hierarchical don't you have to use XMLEditor instead of the Property editor?