Re: [jbosstools-dev] "Hibernate Configuration 3.0 XML Editor"
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
Attachments:
- attachment.html (text/html — 2.7 KB)