[jbosstools-dev] "Hibernate Configuration 3.0 XML Editor"

[Viacheslav Kabanovich]

> 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 ----- 
  From: Max Rydahl Andersen 
  To: Viacheslav Kabanovich 
  Cc: vyemialyanchyk at exadel.com ; Exadel List ; jbosstools-dev at 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 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20090910/8a0da0ef/attachment.html