org.jboss.tools.common (split up / clean up / organize, make part of 'low')
org.jboss.tools.common.el.core (part of 'high')
org.jboss.tools.common.el.ui (part of 'high')
org.jboss.tools.common.gef (part of 'core')
org.jboss.tools.common.jdt (part of 'high')
org.jboss.tools.common.jdt.ui (part of 'high')
org.jboss.tools.common.meta.ui (part of 'high')
org.jboss.tools.common.model (part of 'low' but needs proper core/ui split)
org.jboss.tools.common.model.ui (part of 'low' but needs proper core/ui split)
org.jboss.tools.common.model.ui.capabilities (??? I assume 'high')
org.jboss.tools.common.mylyn (part of' high')
org.jboss.tools.common.projecttemplates (part of 'low')
org.jboss.tools.common.resref.core (part of 'high')
org.jboss.tools.common.resref.ui (part of 'high')
org.jboss.tools.common.text.ext (part of 'low')
org.jboss.tools.common.text.xml (part of 'low')
org.jboss.tools.common.ui (split up somehow? Can anyone explain what's *in* this plugin as opposed to others?)
org.jboss.tools.common.verification (DELETE as per dennis, but other plugins now depend on it (?!))
(DELETE as per dennis, but other plugins depend on it (?))
Dennis suggests removing verification.*, but it seems components like jst. jsf, and struts all use it now, so, thats confusing.
As a first step, I would suggest the immediate creation of a common.core bundle which can hold any and all common utilities that may be of use to multiple extenders. Anything for importing projects, job utilities, xml mementos, resource utilities, string utilities (maybe, if generic enough), etc.
Could even just let the existing "old" bundles depend on this common.core and just expose the packages and things could migrate incrementally - would that be feasible ?
Yes, this would be
feasible, and is the path I would take. THe path for this would
be to introduce the new plugin, copy classes over, do NOT delete
the old classes, mark the old classes as Deprecated, and have
the old classes extend the new ones. This gives other components
time to switch their references to the new component / plugin.
We can then remove the 'cruft' later once we know for certain nobody else is using the deprecated classes.
I would expect the scope of this bundle (what it could depend on) would be limited to anything that comes in the jee prepackaged eclipse. No utilities that interface with anything other than standard eclipse distributions.
> +1 for the concept, but I don't think "standard eclipse distributions" is specific enough - that stuff will drag in *alot* of dependencies. - Max I agree. We could split it up based on 'product', like GEF / WTP / etc. One plugin for integration with each major product. I do think this is overkill for now, though. I think limiting ourselves to what comes with a plain eclipse install (not bundle, just the standard raw) + wtp. This includes basically eclipse platform, emf, gef, maybe dtp, and wtp.
In general, I would argue that 'common' should be similar to 'core' from 2006 (ha!) with utility classes, utility methods, functionality that is very common and ALL plugins could find some reason to use. As the base of our entire platform, it needs to be well-organized, so others can add useful stuff to them. I'm going to list problems here as I find them. So let's do this. 1) org.jboss.tools.common contains LOTS of UI code. This is a big problem and means any plugin that depends on o.j.t.common will be unable to resolve without eclipse ui bundles available. Currently, almost all common plugins depend on o.j.t.common, so you could say the entire component is a UI component. 2) org.jboss.tools.common.base.test seems to be a test plugin inside the common/plugins folder (?) 3) el.core and el.ui seem fine. el.ui depends on common.model.ui, so if common were ever split into two, it's not clear where el.ui and el.core would fit (higher level or lower level). It would definitely need to be higher than common.model. 4) common.gef seems fully featured and depended on by many components. It provides no plugin.xml and no activator and is merely useful for other extenders. THis definitely fits in common. 5) common.jdt / common.jdt.ui: The plugins seem pretty empty, but they're currently not something others would extend or use. This is confusing. As I imagine a 'common' plugin, the code in it would be used or extended by others. Also, the plugin by its name alone implies o.j.t.common + jdt dependency (to separate out bundles which require jdt and those which don't). But in reality, o.j.t.common also requires jdt. I would move this plugin into the 'higher' category. 6) common.jdt.debug.core/ui: Very small plugin which implements a feature. I would suggest this get merged with o.j.t.c.jdt/jdt.ui and given a better name. Then there would be two jdt-related features together. Since both are only features, and not code used by others, we might be able to cut 4 plugins down into 1. 7) meta.ui: I'm not familiar with this plugin at all, but judging by the two tree images, it is not extended or used by any other plugins. I believe this would be a candidate for a higher-level 'common' rather than a lower-level one others depend on. 8) common.model.*: I am pretty confused by the separation of common.model.core vs common.model.ui, since it seems both use UI heavily. Makes it difficult to tell why one should be labeled UI and the otehr should not. 9) common.mylyn: Completely disconnected from anything 'common' really. Similar to the jdt and jdt.debug features. 10) common.projecttemplates: used by struts and jst, no references to other common code except o.j.t.common. Probably safe to stay in 'low level' common. 11) common.resref.core/ui: I can see no reason for these two plugins to be separate. The only non-common plugins that depend on these two at all is VPE, but VPE depends on huge portions of the entire common module, so having these separated out is very strange and not useful at all really. I suggest combining resref.core in to org.jboss.tools.common and resref.ui in to org.jboss.tools.common.model.ui 12) common.text.*: These seem fine. I am not familiar with them but it seems huge numbers of plugins consume it, so it seems common. 13) org.jboss.tools.common.ui: I honestly cannot tell the difference between this plugin and o.j.t.common. They both have UI methods and both seem to be dealing with the same thing. Why? Where is the split between the two? 14) common.validation / verification: Not really familiar with these two at all, So overall problems seem to be no clear lines between core/ui plugins. I feel there needs to be a split between common things everyone wants to extend, and common things that are almost full features built with the common pieces. As a first step, I would suggest the immediate creation of a common.core bundle which can hold any and all common utilities that may be of use to multiple extenders. Anything for importing projects, job utilities, xml mementos, resource utilities, string utilities (maybe, if generic enough), etc. I would expect the scope of this bundle (what it could depend on) would be limited to anything that comes in the jee prepackaged eclipse. No utilities that interface with anything other than standard eclipse distributions. In WTP, their plugins are actually separated even further. They have some bundles providing functionality, and then a new bundle for integration of the first with JDT. I don't think we really need separation between java and not java at this point. If we ever get that gigantic, maybe we can split common.core again ;) From there we can start to untangle what's left inside of common. On 08/16/2012 02:07 AM, Denis Golovin wrote:On 08/15/2012 10:18 AM, Alexey Kazakov wrote:On 08/15/2012 01:12 AM, Rob Stryker wrote:But there are also a wide array of plugins that do not seem to have any links, or very few. resref.core and resref.ui seem to have only one link to vpe. And the entire group of plugins in the upper left corner have no obvious links at all. o.j.t.c.j.debug.core/ui seem to have no links in this new image, AND no links in the previous image of within common only. `Some plugins such as o.j.t.c.j.debug.core/ui probably should be removed at all. They were used in struts debugger which we removed a few years ago.How about several others: o.j.t.c.verification* o.j.t.struts* o.j.t.jst.web.tiles* they are here for years without any significant changes Deniscapabilities and mylyn seem to have no obvious links to anything inside common or outside of it. Very strange indeed.Mylyn is a small independent and standalone plugin which was placed in common because we didn't find a better place for it. And it's so small that it didn't deserve its own module. _______________________________________________ jbosstools-dev mailing list firstname.lastname@example.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev_______________________________________________ jbosstools-dev mailing list email@example.com https://lists.jboss.org/mailman/listinfo/jbosstools-dev_______________________________________________ jbosstools-dev mailing list firstname.lastname@example.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev