<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=ISO-8859-1">
<META content="MSHTML 6.00.6001.18294" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV>> Maybe most of these should be handled by simply having more than one
common feature ?</DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Meta.ui is internal plugin for editing .meta
files.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>> Projecttemplates </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>It keeps templates for jsf, struts etc projects. To
be truly common, it should rather only provide an extension point for
adding specific templates.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>> What kind of changes beyond package rename ?</DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>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.)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>> <FONT face="Times New Roman" size=3>any
specific reason why it should be based on nature </FONT></FONT></DIV>
<DIV>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.</DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<BLOCKQUOTE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A title=max.andersen@redhat.com href="mailto:max.andersen@redhat.com">Max
Rydahl Andersen</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=scabanovich@exadel.com
href="mailto:scabanovich@exadel.com">Viacheslav Kabanovich</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=vyemialyanchyk@exadel.com
href="mailto:vyemialyanchyk@exadel.com">vyemialyanchyk@exadel.com</A> ; <A
title=external-exadel-list@redhat.com
href="mailto:external-exadel-list@redhat.com">Exadel List</A> ; <A
title=jbosstools-dev@lists.jboss.org
href="mailto:jbosstools-dev@lists.jboss.org">jbosstools-dev@lists.jboss.org</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Thursday, September 10, 2009 5:19
PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [jbosstools-dev] "Hibernate
Configuration 3.0 XML Editor"</DIV>
<DIV><BR></DIV><BR>
<BLOCKQUOTE cite=mid:EBEA631B28B74671862CF83FE057D617@GLORYPC type="cite">
<DIV><FONT face=Arial size=2>Splitting common:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 face=Arial size=2>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 face=Arial size=2>Cleaning model:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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 face=Arial size=2>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 </BLOCKQUOTE></BODY></HTML>