<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:EBEA631B28B74671862CF83FE057D617@GLORYPC"
type="cite">
<div><font size="2" face="Arial">Splitting common:</font></div>
<div> </div>
<div><font size="2" face="Arial">We can move all plugins other than 5
mentioned to trunk/jst folder as is. </font></div>
</blockquote>
So that is:<br>
<br>
EL/Resource resolving/knowledge base:<br>
org.jboss.tools.common.el.core<br>
org.jboss.tools.common.el.ui<br>
org.jboss.tools.common.el.kb<br>
org.jboss.tools.common.resref.core<br>
org.jboss.tools.common.resref.ui <br>
<br>
<br>
Meta ui ?(what is this for ?) <br>
org.jboss.tools.common.meta.ui <br>
<br>
Project templates:<br>
org.jboss.tools.common.projecttemplates (isn't this common
functionallity?)<br>
<br>
Verification:<br>
org.jboss.tools.common.verification<br>
org.jboss.tools.common.verification.ui<br>
<blockquote cite="mid:EBEA631B28B74671862CF83FE057D617@GLORYPC"
type="cite">
<div><font size="2" face="Arial">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 <font
size="2">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.</font></font></div>
</blockquote>
What kind of changes beyond package rename ?<br>
<br>
Also changes in .meta files ?<br>
<br>
Will it affect users local config files ?<br>
<br>
Maybe most of these should be handled by simply having more than one
common feature ? i.e. common.verification/common.xmodel/etc. ?<br>
<br>
<blockquote cite="mid:EBEA631B28B74671862CF83FE057D617@GLORYPC"
type="cite">
<div><font size="2" face="Arial">Cleaning model:</font></div>
<div> </div>
<div><font size="2" face="Arial">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. </font></div>
</blockquote>
k - any specific reason why it should be based on nature and not just
on some other setting/logic ?<br>
<blockquote cite="mid:EBEA631B28B74671862CF83FE057D617@GLORYPC"
type="cite">
<div><font size="2" face="Arial">Next, 'options' section of XModel is
heaped in one file in common. I will think about its separation into
components.</font></div>
</blockquote>
k.<br>
<br>
/max
</body>
</html>