Geronimo schema changes & Eclipse Plug-in (was svn commit: r577890 - in /geronimo/server: branches/2.0/modules/...)

[Shiva Kumar H R <sh...@gmail.com>]

On 9/26/07, Kevan Miller <ke...@gmail.com> 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
>
>
>
>
>