[jbosstools-dev] "Hibernate Configuration 3.0 XML Editor"

[Max Rydahl Andersen]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20090910/d3a67466/attachment-0001.html