Slava, No sense to implement new editor, even more there is someone in JIRA as a patch - I had to modify old Exadel studio hibernate cfg editor far times ago, but this wasn't accepted in trunk. https://jira.jboss.org/jira/browse/JBIDE-2607 some clauses from this are fixed. But the main feature which seems could be very useful is properties name-value suggestion in Add Property dialog. This idea how to enhance XML Editor - it will be great if this possible to implement in common use. I check which common plugins are necessary for Hibernate Configuration 3.0 XML Editor: org.jboss.tools.common.model, org.jboss.tools.common, org.jboss.tools.common.model.ui, org.jboss.tools.common.gef, org.jboss.tools.common.text.ext, org.jboss.tools.common.text.xml, org.jboss.tools.common.el.core, org.jboss.tools.common.resref.core This is a half common plugins. download Hibernate Tools separately, but there is no possibility to download jboss.tools.common. May be there is a sense to have common as a separate plugins bundle? Just as idea. Sometime people ask "I install Hibernate Tools there I can find "Hibernate Configuration 3.0 XML Editor"? - cause there is it's description in documentation", so it is necessary to explain what this part of Jboss Tools and this is not included in Hibernate Tools. So this could be a reason to include "Hibernate Configuration 3.0 XML Editor" into Hibernate Tools and suggest the user to download and install jboss.tools.common together with Hibernate Tools or have "Hibernate Configuration 3.0 XML Editor" plugins separately as some Hibernate Tools addition extension which required jboss.tools.common. It is interesting to hear some other opinion about the question. Vitali From: Viacheslav Kabanovich [mailto:scabanovich@exadel.com] Sent: Wednesday, September 09, 2009 7:48 PM To: vyemialyanchyk(a)exadel.com; Exadel List Cc: jbosstools-dev(a)lists.jboss.org Subject: Re: [jbosstools-dev] "Hibernate Configuration 3.0 XML Editor" Hi, Vitali, In my opinion that just means implementing new editor from scratch. In doing so, you will develop components that you may wish to put to common. We have many xml editors, there ui has a lot in common, so why not share new approaches between them? And that is exactly what XModel framework does. Plugins .hibernate.xml and .hibernate.xml.ui include just few lines of code customizing components developed in common. Why 'integrating editor into Hibernate Tools' should mean separating it from common? All enhancements, listed in https://jira.jboss.org/jira/browse/JBIDE-2607 may be implemented within existing editor. I am sorry I did not pay attention to this issue before. Slava ----- Original Message ----- From: Vitali Yemialyanchyk <mailto:vyemialyanchyk@exadel.com> To: Exadel List <mailto:external-exadel-list@redhat.com> Cc: jbosstools-dev(a)lists.jboss.org Sent: Wednesday, September 09, 2009 5:12 PM Subject: [jbosstools-dev] "Hibernate Configuration 3.0 XML Editor" Hi, I want to start discussion of "Hibernate Configuration 3.0 XML Editor". This rather strange editor is situated in trunk\hibernatetools\plugins\org.jboss.tools.hibernate.xml trunk\hibernatetools\plugins\org.jboss.tools.hibernate.xml.ui I call it strange cause it in hibernatetools in svn repository, but really this is Jboss Tools thing and it was nether in Hibernate Tools. Some users has questions about this and create such bugs in jira: https://jira.jboss.org/jira/browse/JBIDE-4802 For them and for me (if I think about myself as Hibernate Tools user, not a developer) it is difficult to explain, why I should take a lot of things from JBoss Tools if I just want to use separate Hibernate Tools. As a developer I see advantages of common things. To make it more useful I create JIRA issue far time ago: https://jira.jboss.org/jira/browse/JBIDE-2607 there are no changes since that time. I want to enhance this editor to make it more useful and I want to integrate it into Hibernate Tools. For this it is necessary to separate org.jboss.tools.hibernate.xml and org.jboss.tools.hibernate.xml.ui, make it detached from XModel. So I want to hear some arguments pro/contra this solution and/or may be some advises howto possible make this changes in better manner. Vitali _____ _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

No sense to implement new editor, even more there is someone in JIRA as a patch - I had to modify old Exadel studio hibernate cfg editor far times ago, but this wasn't accepted in trunk. I never saw a patch that actually worked ;) Got a link ? And what is the problem with the current cfg.xml editor ? (beyond that it only gets installed when selectin gJBoss Tools feature ?) My mistake -> it was hibernate properties editor - not cfg.xml: https://jira.jboss.org/jira/browse/JBIDE-1674 Not a big problem, just https://jira.jboss.org/jira/browse/JBIDE-2607 - my opened Feature Request. I have no peace cause I want to see it fixed. Mainly property name/value suggestion - for me it looks like a feature which is obligatory for Hibernate cfg.xml editor. We have it discussed with Slava, so possible to get the issue resolved. Vitali

Hi, Max 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? Next, I will clean common.model from unnecessary references using new extension points. 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. Slava ----- Original Message ----- From: Max Rydahl Andersen To: Viacheslav Kabanovich Cc: vyemialyanchyk(a)exadel.com ; Exadel List ; jbosstools-dev(a)lists.jboss.org Sent: Thursday, September 10, 2009 2:15 PM Subject: Re: [jbosstools-dev] "Hibernate Configuration 3.0 XML Editor" Viacheslav Kabanovich wrote: Hi, Vitali, In my opinion that just means implementing new editor from scratch. In doing so, you will develop components that you may wish to put to common. We have many xml editors, there ui has a lot in common, so why not share new approaches between them? And that is exactly what XModel framework does. Plugins .hibernate.xml and .hibernate.xml.ui include just few lines of code customizing components developed in common. Why 'integrating editor into Hibernate Tools' should mean separating it from common? The problem is that common isn't just common. It includes ton's of jsf, xhtml, jsp and even struts references. That is what we need separated before I'm ok having Hibernate tools feature depend on it. i.e. if I *only* install Hibernate tools feature it should *not* result in other additional editors such as jsf, jsp, xhtml etc. to be installed. That were the case last time I tried it - if that has changed we should look at it again. /max

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 ----- From: Max Rydahl Andersen To: Viacheslav Kabanovich Cc: vyemialyanchyk(a)exadel.com ; Exadel List ; jbosstools-dev(a)lists.jboss.org Sent: Thursday, September 10, 2009 4:05 PM Subject: Re: [jbosstools-dev] "Hibernate Configuration 3.0 XML Editor" 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

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. It keeps templates for jsf, struts etc projects. To be truly common, it should rather only provide an extension point for adding specific templates. 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.) 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 ----- From: Max Rydahl Andersen To: Viacheslav Kabanovich Cc: vyemialyanchyk(a)exadel.com ; Exadel List ; jbosstools-dev(a)lists.jboss.org 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