Splitting common:

We can move all plugins other than 5 mentioned to trunk/jst folder as is.

So that is:

EL/Resource resolving/knowledge base:
org.jboss.tools.common.el.core
org.jboss.tools.common.el.ui
org.jboss.tools.common.el.kb
org.jboss.tools.common.resref.core
org.jboss.tools.common.resref.ui

Meta ui ?(what is this for ?)
org.jboss.tools.common.meta.ui

Project templates:
org.jboss.tools.common.projecttemplates (isn't this common functionallity?)

Verification:
org.jboss.tools.common.verification
org.jboss.tools.common.verification.ui

That will involve mimimal changes, including new features definitions. However, if we want to keep to naming agreements and rename plugins and packages, for example org.jboss.tools.common.el.core -> org.jboss.tools.jst.el.core, then it may be not good for the nearest release as involving major changes.

What kind of changes beyond package rename ?

Also changes in .meta files ?

Will it affect users local config files ?

Maybe most of these should be handled by simply having more than one common feature ? i.e. common.verification/common.xmodel/etc. ?

Cleaning model:

For instance, EclipseResourceUtil lists in code possible natures based on XModel (jsfnature, strutsnature). It really does not need either to know or use concrete natures. But it needs to know that some Eclipse project do has a nature based on XModel. This is easily solved by new extension point 'xmodelnature' that will provide for given installation available natures.

k - any specific reason why it should be based on nature and not just on some other setting/logic ?

Next, 'options' section of XModel is heaped in one file in common. I will think about its separation into components.

k.

/max