1:18 a.m.
Hey All:
I'm just trying to get the ball moving on a possible breakup of the
'common' module. Common is currently FULL of all sorts of different
stuff. It has 23 plugins, 10 tests, and 13 features. Since we've just
finished a major release, now is the time to discuss reorganizations. I
hope I'm not stepping on anyone's toes. Even fi I don't end up doing the
work, it's at least time to open the discussion.
Common simply has too many different things all bundled together, and a
lot of them aren't "common" ;) I tried to make an image of what all
depends on what with regards to common, even going so far as to show
what the different common plugins depend on, but that image was just too
crowded, too many nodes. So for now I've made a more simple one of just
INSIDE common.
Hopefully we can split things out into things that are truly common and
many other plugins might use, vs stuff that's a little less common.
Attached is an image showing common's current interdependencies. Direct
dependencies supplied by other plugins are not shown, to help make the
graph easier to understand. (ex: org.jboss.tools.common.ui depends on
o.j.t.common, but since o.j.t.c.ui depends on o.j.t.c.text.xml, that
direct link is not shown.)
Hopefully this graph will help us ask other questions, for example
WHY does o.j.t.common.ui depend on o.j.t.c.text.xml, and would the code
that is in common.ui be more appropriate to live in o.j.t.c.text.xml
instead?
Anyway, we can at least start the discussion. Image attached.
2:12 a.m.
Rob, +1 for this initiative - love your "visualizer" view ;)
I'm just trying to get the ball moving on a possible breakup of
the 'common' module. Common is currently FULL of all sorts of different stuff. It
has 23 plugins, 10 tests, and 13 features. Since we've just finished a major release,
now is the time to discuss reorganizations. I hope I'm not stepping on anyone's
toes. Even fi I don't end up doing the work, it's at least time to open the
discussion.
I know I said yesterday common probably needs to be split up, but with 13 features
aren't common already split up to be reusable independently ?
Any value do do further splitting ?
Which components are "not common" ?
/max
3:12 a.m.
I've attached another screenshot detailing links from other components
into individual plugins inside common. What you can see in the attached
image is that there are several plugins with *many* incoming arrows.
text.ext, text.xml, el.core, common.model, common, common.validation,
common.verification, common.ui, etc.
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.
capabilities and mylyn seem to have no obvious links to anything inside
common or outside of it. Very strange indeed.
Because I'm trying to omit the extra links which just make the graph
look very messy, we can't really tell any more whether, for example,
el.core REALLY needs resref or if some of that code would be more
appropriately moved out of el.core and into resref directly.
Anyway, these graphs are not foolproof. They won't catch all references
since it's possible openshift depends on one common plugin which also
exposes another. So there's no guarantees here. But it's a start.
Whatever is considered to separate it though, these two graphs will come
in very handy in both showing the inner-dependencies and outward
dependencies of the common component.
On 08/15/2012 03:12 PM, Max Rydahl Andersen wrote:
Rob, +1 for this initiative - love your "visualizer" view
;)
> I'm just trying to get the ball moving on a possible breakup of the
'common' module. Common is currently FULL of all sorts of different stuff. It has
23 plugins, 10 tests, and 13 features. Since we've just finished a major release, now
is the time to discuss reorganizations. I hope I'm not stepping on anyone's toes.
Even fi I don't end up doing the work, it's at least time to open the discussion.
I know I said yesterday common probably needs to be split up, but with 13 features
aren't common already split up to be reusable independently ?
Any value do do further splitting ?
Which components are "not common" ?
/max
12:18 p.m.
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.
capabilities 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.
1:07 p.m.
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
Denis
> capabilities 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
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
6:41 a.m.
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
Denis
>> capabilities 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
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
5:07 a.m.
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 ?
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.
wtp, mylyn, etc. all "explode" dependency wise very fast.
But how much of the stuff could we actually put in the .common.core without
introducing big dependencies ?
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 ;)
When you say bundle do you mean a plugin or feature ?
common is already rather fragmented in both plugins and features so
not sure what your exact point is ?
/max
5:39 a.m.
To be more clear, I'll make my suggestions more precise:
1) Split the 'common' module into two different modules. One
lower-level, which all of JBT can depend on, and one higher level. The
higher level ones should be plugins NOT depended on by other modules,
what I would call 'leaf nodes', which implement features or provide
functionality to the user. Other plugins MAY use them, but, they are not
"common" to all of jbt. The lower level module should be used by all of
jbt. Think of the lower level one as a 'core'.
2) Ensure that plugins with names like '.core' only have core code, no
UI code. This is a huge problem currently. The split between core/ui in
each common plugin seems off.
3) Remove unused plugins in common (common.jdt / common.jdt.ui /
common.verification (?))
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.debug (DELETE)
org.jboss.tools.common.jdt.debug.ui (DELETE)
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.validation
org.jboss.tools.common.verification (DELETE as per dennis, but other
plugins now depend on it (?!))
org.jboss.tools.common.verification.ui (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.
On 08/16/2012 07:41 PM, Rob Stryker wrote:
> 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
>>
>> Denis
>>
>>>> capabilities 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
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
4488
days inactive
4493
days old
jbosstools-dev@lists.jboss.org
7 comments
4 participants
participants (4)
-
Alexey Kazakov -
Denis Golovin -
Max Rydahl Andersen -
Rob Stryker