Splitting common:
We can move all plugins other than 5 mentioned to
trunk/jst folder as is. 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.
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.
Next, 'options' section of XModel is heaped in one
file in common. I will think about its separation into components.
Slava
----- Original Message -----
Sent: Thursday, September 10, 2009 4:05
PM
Subject: Re: [jbosstools-dev] "Hibernate
Configuration 3.0 XML Editor"
> The
problem is that common isn't just common.
I suggest to split common. "True" common will
contain only
org.jboss.tools.common
org.jboss.tools.common.model
org.jboss.tools.common.model.ui
org.jboss.tools.common.text.xml
part of org.jboss.tools.common.text.ext
Other plugins may be moved to
org.jboss.tools.jst...
Or, may we physically leave plugins where they
are, but for build and installation purposes apply this logic separation
'virtually' by defining other set of
features?
I say we move the plugins
that can be moved to where they belong.
Could you outline which changes
you would do ?
Next, I will clean common.model from
unnecessary references using new extension points.
sounds good. Again, would like to know what this
involves ?
As to what we have now, installing Hibernate
Tools + common will not add jsf, jsp, etc editors; and though common
includes some excessive knowledge of jsp, jsf, struts, it does not add any
functionality.
Ok - I'll try again then
;)
/max