Pete, I wasn't saying that preferences are a bad thing or that you shouldn't do this, but just mentioning some considerations about various options available for Eclipse plugin development (based on recommendations from "Contributing to Eclipse"). Yes, I think the global nature of preferences would make it difficult to support multiple projects and/or deployment choices in the same workspace, where the preference settings were different for each combination. For example, if I have a project using struts-tomcat-direct-hibernate-mysql, there would be a given set of preferences. Or if I also want to change that for a different deployment option where I might want to use have want to use jsf-jboss-jms-db2. Unless multiple sets of preferences were maintained globally, each change would require changing the global preferences, and then copying them to the local *-deploy.properties file. Certainly, this would work, but it would probably mean that you have a separate Eclipse workspace for each Keel project and/or configuration. I also agree we need to start simply, and perhaps the alternatives will become clearer as we experiment with the plugin features. Then, we can refine and/or integrate them from there, and it's probably better to do this with actual code examples, rather than long-winded discussions like mine. In any case, I think we can add a lot of value to the Keel environment via Eclipse plugins. Also, we certainly need Keel Preferences, and your suggestion should give us a good start with this.
Doug -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Pete Carapetyan Sent: Wednesday, December 31, 2003 8:18 AM To: [EMAIL PROTECTED] Subject: Re: [Keelgroup] Eclipse Preference Page - inputs invited Doug: Summarizing your comments, there is an impedance mis-match between the global nature of preferences and the one-of nature of each of the (perhaps multiple) -deploy.properties files. Before we go too far with this, there is an article on Eclipse.org which already addresses this problem and solves it elegantly. http://eclipse.org/articles/Article-Mutatis-mutandis/overlay-pages.html Until the code in the above article is implemented, it is still a reasonably satisfactory situation Until a particular -deploy.properties file is right clicked on and the action selected, no copying of the global preferences into that file takes place. So you don't have two way GUI representation of the data (something I am not as drastically concerned about in initial versions) but at least you can be assured that whatever you see in the GUI will be written properly, and according to the right rules, which is most of the difficulty encountered by most users. Migration to the two way code per the code in the article can take place when inspiration and time permits. If this does not address your concerns, at least for the short term, let me know. Doug Warren wrote: >Pete, > >Perhaps some additional comments and clarification is appropriate. > >1. Since Eclipse preferences are global to the entire workspace, I'm not >sure that's the right place to store property name/value information for >specific *-deploy.properties files, which may be different for a project and >resource level. If you only had a single project with a single deployment >configuration within a workspace, then that might work. However, since you >indicated that you wanted an action associated with a specific deploy >resource, you would have to use the same global preferences for all such >deployment configuration resources. > >2. Resources also have both session and persistent properties keyed by a >qualified name, similar to preferences. Although these are intended to >store resource-specific information that persists across sessions, they can >not be shared with a team via a repository. Therefore, I don't think this >option makes sense either. > >3. There is also a metadata area for each plug-in where additional data >could be stored, includes additional files and directories that you manage, >but that is also not shareable across a team. > >4. Actually, files are probably the simplest and most flexible way to store >data, and can be shared with team members. Since *-deploy.properties files >already exist with such data, what's really needed are Eclipse editors as >visual components for Keel resources, such as *-deploy.properties, >ant.properties, custom.xml, etc. Editors are opened by the user on a >particular element, and the element becomes input to the editor. Editors >can also contribute to the global Eclipse toolbar, such as Keel menu. >Multiple editors of the same kind can be opened on different inputs inside >the same workbench page. Also, editors have an open-modify-save life cycle >with ability to save permanent changes. Basically, editors are typically >used to edit resources, and that seems the best approach to editing and >managing Keel configuration resources. > >5. I still believe that it's appropriate to use Eclipse preferences for >Keel as global workspace properties. Although preferences are easier to >develop and integrate than editors, they're still workspace-global settings. >Another option might consider adding a Keel preferences resource (file) to a >Keel project for project-specific information (similar to .classpath, >.project, etc.). This might allow additional flexibility to use these at >different levels of granularity, such as Keel project, directory, >application, service, etc. However, such project preference files would >also need an editor. So perhaps it's easier just to use specific >*-deploy.properties files for that purpose, with the ability to use it as a >template that you clone, change, rename, and save. > >This is an important area of discussion, and I think offers a lot of promise >to enhance Keel usability, configuration, and flexibility. We need to be >thinking about a Keel development environment based on Eclipse, which will >require a set of related tools, utilities, and components. Why don't you go >ahead with the Keel preferences, I'll explore the editor option (unless >someone else already has), and we can also start integrating Derek's and >Jeff's plugins too. Thanks for getting this going because this is an >important area, especially with the growing list of capabilities with Keel >2.0 and related deployment configuration combinations. I know it's an area >I keep getting tripped up with. Flexibility and choices are great, but we >need to make it simpler and easier to use the rich features available with >Keel. Hopefully, this will generate some additional discussion and other >ideas, wish lists, etc. > >Doug > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] >Behalf Of Pete Carapetyan >Sent: Tuesday, December 30, 2003 7:45 PM >To: [EMAIL PROTECTED] >Subject: Re: [Keelgroup] Eclipse Preference Page - inputs invited > > >Doug Warren wrote: > > > >>Pete, >> >>Great idea! I've been wanting something like this for a while now. This >>will really help with deployment configuration settings, as well as >> >> >managing > > >>different Keel deployments. It might also be helpful for related >>configuration files such as ant.properties, custom.xml, etc. It would be >>nice to have the ability to load a specific (or default) deploy properties, >>making some changes, and save it with a different name, instead of having >> >> >to > > >>set all the options from scratch (that is, copy and change an existing >>configuration model). >> >> >> >I am not sure exactly how it would all work from the configuration side, >but configuration and saving preferences are 100% decoupled in totally >separate plugins as a programming/maintenance measure. > >Right now the preferences pages just save preferences in Eclipse. > >The initial design idea is that whenever you right click on a >-deploy.properties file, you would have the option of selecting "Copy >Keel Preferences" and it would take those preferences and copy them into >the file as any other property. Attempting to keep it as simple and dumb >as possible. > > > >>Would this create just properties files, or XML >>configuration files too (or maybe those are still experimental)? >> >> >> >Never even thought about that. Good idea. > > > >>You >>omitted "axis" as one of the client options? >> >> >> >Aha, missed that. Thanks. > > > >>Looks good. >> >>Doug >> >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] >>Behalf Of Pete Carapetyan >>Sent: Monday, December 29, 2003 8:50 AM >>To: [EMAIL PROTECTED] >>Subject: [Keelgroup] Eclipse Preference Page - inputs invited >> >> >>If you are interested in any Eclipse Preference Pages, used as a GUI to >>feed your -deploy.properties files or any other purpose... >>[in Eclipse, it's Window, Preferences, Keel, etc] >> >>Here is the tentative breakdown, but it is very easy to change so let me >>know if any of these pages, their properties, default values etc need to >>be ammended. Or any entirely new pages, if required. >> >>Main Preference Page >>- keel.version (1.x, 2.x) [used and requested by RedKeel] [default is 2.x] >>- keel.deploy.file.name [default is default-deploy.properties] >> >>Database Layer Preference Page >>- database.type (hsqldb, oracle, mysql, postgres, sqlServer, interbase, >>db2, sybase) [default is hsqldb] >>- database.url [default is 127.0.0.1] >>- database.username [default is sa] >>- database.password [default is blank] >>- database.port [required by Oracle, leave blank otherwise] >> >>App Server Preference Page >>- app.server (tomcat, jboss, other) [default is tomcat] >>- app.server.home [if use existing installation rather than new >>installation] [default is blank] >> >>Messaging Layer Preference Page >>- select.messaging (direct, jms) [default is direct] >> >>Clustering Preference Page >>- select.clustering (standalone, clustered) [default is standalone] >> >>Client Layer Preference Page >>- select.ui (struts, cocoon, velocity, jsf, webworks, tapestry, >>maverick) [default is struts] >> >>Security Preference Page >>- root.username [default is root] >>- root.password [default is root] >>- crypto.strength (strong, weak) [default is weak] >> >> >> >>http://keelframework.org/documentation >>Keelgroup mailing list >>[EMAIL PROTECTED] >>http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com >> >> >> >>http://keelframework.org/documentation >>Keelgroup mailing list >>[EMAIL PROTECTED] >>http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com >> >> >> >> >> > > > >http://keelframework.org/documentation >Keelgroup mailing list >[EMAIL PROTECTED] >http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com > > >http://keelframework.org/documentation >Keelgroup mailing list >[EMAIL PROTECTED] >http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com > > > http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com http://keelframework.org/documentation Keelgroup mailing list [EMAIL PROTECTED] http://lists.keelframework.com/listinfo.cgi/keelgroup-keelframework.com
