Max Rydahl Andersen wrote:

The JBDS global icon is just when we don't have any other options - and using that should be limited
and it should not be done in a way so we create large dependencies. Copy it over is ok for this.

Afaik, we did get an icon created specifically for ESB (https://jira.jboss.org/jira/browse/JBIDE-3040 ?) - we should use that
and if that isn't big enough get one done that are.

btw. the big problem here is that common/xmodel drags a *massive* set of dependencies in...we
really need to fix that since if we had that under control we could actually have proper shared resources

As first step we have to split richfaces to separate features and approach could be to have tree features:

A feature with the plug-ins those are a dependencies of XModel:

    org.jboss.tools.common.feature
        org.jboss.tools.common
        org.jboss.tools.common.kb
        org.jboss.tools.common.gef

A XModel feature

    org.jboss.tools.common.model.feature
        org.jboss.tools.common.model
        org.jboss.tools.common.model.ui
        org.jboss.tools.common.text.ext
        org.jboss.tools.common.text.xml

All others plug-ins that depends on XModel

    org.jboss.tools.common.framework.feature
        org.jboss.tools.common.verification.*
        org.jboss.tools.common.projecttemplates
        org.jboss.tools.common.el.*
        org.jboss.tools.common.resref.*
        org.jboss.tools.jst.*
        org.jboss.tools.jsf.*
        org.jboss.tools.vpe.*

That means if ESB depends on XModel only
    org.jboss.tools.common.feature
    org.jboss.tools.common.model.feature
would be installed as dependencies

Since we are going to get rid of separate archives on download site an use archived update site
there should be no problems for user, required features would be detected trough dependencies.


That's a separate discussion how to split it and fix all cyclic references.

Here is tentative list of features (I know that not just that simple because there are several cyclic dependencies):

org.jboss.tools.common.feature
    org.jboss.tools.common
    org.jboss.tools.common.kb
    org.jboss.tools.common.gef

org.jboss.tools.common.model.feature
    org.jboss.tools.common.model
    org.jboss.tools.common.model.ui
    org.jboss.tools.common.text.ext
    org.jboss.tools.common.text.xml

org.jboss.tools.common.verification.feature
    org.jboss.tools.common.verification
    org.jboss.tools.common.verification.ui

org.jboss.tools.common.projecttemplates.feature
    org.jboss.tools.common.projecttemplates

org.jboss.tools.common.el.feature
    org.jboss.tools.common.el.*

org.jboss.tools.common.resref.feature
    org.jboss.tools.common.resref.*

org.jboss.tools.jsf.fetaure
    org.jboss.tools.jsf.*

org.jboss.tools.jst.feature
    org.jboss.tools.jst.*

org.jboss.tools.vpe.feature
    org.jboss.tools.vpe.*

This is not a plan, just a suggestion for discussion.

> The problem is that common isn't just common.

 

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