> Maybe most of these should be handled by simply having more than one
common feature ?
Yes, I would keep to that for now, my alternative
suggestion was "may we physically leave plugins where they are" and "define
other set of features". Then we only need to ensure that 'true' common plugins
do not depend on other plugins left in 'common' folder.
Meta.ui is internal plugin for editing .meta
files.
> Projecttemplates
It keeps templates for jsf, struts etc projects. To
be truly common, it should rather only provide an extension point for
adding specific templates.
> What kind of changes beyond package rename ?
Nothing else, but I think it is bad enough when we
are between M3 and M4 since that involves moving interfaces. (So, once more, I
am for defining new features.)
> any
specific reason why it should be based on nature
Instance of XModel for jsf and struts is provided by the project nature.
That is convenient for configuring XModel properly in jsf/struts plugins. In the
example mentioned, a util function is requested to return XModel instance by
IProject instance. So it needs to find in the project a nature providing
XModel.
----- Original Message -----
Sent: Thursday, September 10, 2009 5:19
PM
Subject: 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