On 9/26/07, Kevan Miller <[EMAIL PROTECTED]> wrote: > > > On Sep 25, 2007, at 12:38 PM, Jarek Gawor wrote: > > > Vamsi, > > > > In general I think we agree on how things should be handled when > > schema changes. Also, the patch I looked at had schema changes made in > > the existing .xsd files and I assumed that the new files would be > > introduced in trunk only. But since nobody else has an issue with that > > change, that's fine. We just have to remember to publish the new > > schemas on the website and (eventually) update the eclipse plugin. > > Several people have expressed their concerns about this change. I > must confess that I'm not entirely comfortable with the change > either. I don't think there's a black and white answer. Obviously, > Vamsi would prefer that the change go into 2.0.2. We could always > retag 2.0.2 and call it 2.1. However, that doesn't feel right either. > I'd thought about the required documentation changes, but don't > really know how to evaluate the plugin impacts. I'd like to hear > about this from an eclipse plugin perspective...
Yes, with every new version of Geronimo deployment schema coming out we have a major headache in Geronimo Eclipse Plug-in (GEP). Sorry for being late in raising this, but I am still lacking clarity, so please correct me if I am wrong. GEP source code currently looks like this (only mentioning the directories relevant to this discussion. Also note that GEP doesn't yet support Geronimo 2.0 schemas): | - emf | - geronimo-1.0 | - geronimo-1.1 | - plugins | - org.apache.geronimo.deployment.model | - org.apache.geronimo.deployment.model.edit | - org.apache.geronimo.v11.deployment.model | - org.apache.geronimo.v11.deployment.model.edit | - plugins | - org.apache.geronimo.st.ui | - org.apache.geronimo.st.v1.ui | - org.apache.geronimo.st.v11.ui where, | - emf | - geronimo-1.0 | - geronimo-1.1 contain the configuration files for generating EMF model classes for Geronimo deployment schemas, | - plugins | - org.apache.geronimo.deployment.model | - org.apache.geronimo.deployment.model.edit contain the generated EMF model classes, and | - plugins | - org.apache.geronimo.st.ui | - org.apache.geronimo.st.v1.ui | - org.apache.geronimo.st.v11.ui contain the source code (viewer & controller part of MVC pattern) for "Geronimo Deployment Plan Editors". Once we add the support for 2.0 schemas, then the above source will look like: | - emf | - geronimo-1.0 | - geronimo-1.1 | - geronimo-2.0 | - plugins | - org.apache.geronimo.deployment.model | - org.apache.geronimo.deployment.model.edit | - org.apache.geronimo.v11.deployment.model | - org.apache.geronimo.v11.deployment.model.edit | - org.apache.geronimo.v20.deployment.model | - org.apache.geronimo.v20.deployment.model.edit | - plugins | - org.apache.geronimo.st.ui | - org.apache.geronimo.st.v1.ui | - org.apache.geronimo.st.v11.ui | - org.apache.geronimo.st.v20.ui Ideally, | - org.apache.geronimo.v20.deployment.model | - org.apache.geronimo.v20.deployment.model.edit should have been *deltas* (sub classes) over, | - org.apache.geronimo.v11.deployment.model | - org.apache.geronimo.v11.deployment.model.edit But, they turn out to be full fledged classes by themselves. This in-turn forces, *no* sharing of code between | - org.apache.geronimo.st.v11.ui | - org.apache.geronimo.st.v20.ui This is the real pain point. Every time a new version of Geronimo schema is released, we have to copy the entire current editor-code (say org.apache.geronimo.st.v11.ui) and modify/update them to support the new version (resulting in say org.apache.geronimo.st.v20.ui). Not to forget the pain this causes during maintenance/jira-fixing. Ideally the required work should have been to come up with UI code just for delta between the old & new schemas. Don't know who is the culprit? Is it the design of GEP? or the way we are generating EMF model classes for Geronimo plans? or a limitation of using EMF as the modelling framework? Will migrating away from EMF and using DConfigBeans or XMLBeans solve this problem? OR Is it a limitation posed by the way Geronimo schemas have been evolving? A quick comparison of the various Geronimo schemas (v1.0, v1.1 & v2.0) show that each of the xsd files (say geronimo-web-1.0.xsd, geronimo-web-1.1.xsd & geronimo-web-2.0.xsd) are independent files by themselves and don't derive from a base xsd. (Is there anything like an XSD deriving from another XSD??) Any and all help is appreciated. Thanks, Shiva I think Vamsi has done a commendable job of communicating with the > community (one minor quibble: don't use Jira as a group communication > mechanism. Not all people read Jira comments as actively as they read > the dev list). > > Even with this communication, it's quite reasonable for Jarek or > anyone to express their concerns about a commit. He, or any other > project member, can do this *at any time*. > > --kevan > > > > >