Home » Eclipse Projects » Buckminster dev » Dependency Visualization
|
Re: Dependency Visualization [message #35564 is a reply to message #35530] |
Tue, 23 June 2009 06:27 |
|
Hi Johannes,
This looks awesome. I'll install and have a closer look today.
Regards,
Thomas Hallgren
Johannes Utzig wrote:
> Hi,
>
> as discussed in
> http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.html
> I started working on a zest based component dependency viewer for
> buckminster.
> I just finished an early prototype and thought it's enough to get at
> least an idea and ask you guys what kinds of features you'd like to see
> in it.
>
> Currently this is (for sake of simplicity) registered as an editor for
> previously saved .bom files.
> It consists of 3 areas
>
> -navigation tree that shows a tree of the component dependencies and is
> used to drill down on the graph. The selection is linked to the graph
> viewer so if you select a component in the tree, only this specific
> subtree is revealed in the graph.
>
> -graph viewer. This is very basic at the moment. It shows the
> dependency graph with some icons depending on the component type and
> highlights the direct dependencies of the selected component. Unresolved
> nodes are shown in red, a double-click on a node reveals the node's
> cspec and that's about it :)
>
> -settings section. This section lets you choose between some layout
> algorithms and filters (only platform component filter so far). Filters
> are applied to both the navigation tree and the graph viewer.
>
> I came up with the following things that should be added:
> -better highlighting
> -tooltips and properties view that reveal more details of each component
> -smart highlighting of paths through the graph (shortest path to root
> request for example)
> -regex based filter (black and white list filter)
> -dependency reports generated from a bom with some nice pictures
> -zooming
> -image export
>
> Now I'd be very interested to hear what's on your wish-list for
> dependency visualization, so that I can plan on the real implementation.
> Attached is a screenshot and a bundle.jar including source code. Just
> throw it in your dropins folder to try, but make sure that zest is
> installed.
> Keep in mind, this is just an early prototype for demonstration and my
> first steps with zest, so the code is super ugly at the moment...
>
> Best regards,
> Johannes
>
> ------------------------------------------------------------ ------------
>
|
|
|
Re: [buckminster-dev] Dependency Visualization [message #35631 is a reply to message #35530] |
Tue, 23 June 2009 07:46 |
Guillaume Chatelet Messages: 146 Registered: July 2009 |
Senior Member |
|
|
--0016367d69d84648d1046cff3096
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Wow Johannes ! This looks great : )
UI is actually an issue in Buckminster and EMF + Zest will do a good job
here. Very cool : )
Best regards,
Guillaume
On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <mail@jutzig.de> wrote:
> Hi,
>
> as discussed in
> http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.htmlI started working on a zest based component dependency viewer for
> buckminster.
> I just finished an early prototype and thought it's enough to get at least
> an idea and ask you guys what kinds of features you'd like to see in it.
>
> Currently this is (for sake of simplicity) registered as an editor for
> previously saved .bom files.
> It consists of 3 areas
>
> -navigation tree that shows a tree of the component dependencies and is
> used to drill down on the graph. The selection is linked to the graph viewer
> so if you select a component in the tree, only this specific subtree is
> revealed in the graph.
>
> -graph viewer. This is very basic at the moment. It shows the dependency
> graph with some icons depending on the component type and highlights the
> direct dependencies of the selected component. Unresolved nodes are shown in
> red, a double-click on a node reveals the node's cspec and that's about it
> :)
>
> -settings section. This section lets you choose between some layout
> algorithms and filters (only platform component filter so far). Filters are
> applied to both the navigation tree and the graph viewer.
>
> I came up with the following things that should be added:
> -better highlighting
> -tooltips and properties view that reveal more details of each component
> -smart highlighting of paths through the graph (shortest path to root
> request for example)
> -regex based filter (black and white list filter)
> -dependency reports generated from a bom with some nice pictures
> -zooming
> -image export
>
> Now I'd be very interested to hear what's on your wish-list for dependency
> visualization, so that I can plan on the real implementation.
> Attached is a screenshot and a bundle.jar including source code. Just throw
> it in your dropins folder to try, but make sure that zest is installed.
> Keep in mind, this is just an early prototype for demonstration and my
> first steps with zest, so the code is super ugly at the moment...
>
> Best regards,
> Johannes
>
> _______________________________________________
> buckminster-dev mailing list
> buckminster-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>
>
--0016367d69d84648d1046cff3096
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Wow=C2=A0Johannes=C2=A0! This looks great : )<div><br></div><div>UI is actu=
ally an issue in Buckminster and EMF + Zest will do a good job here. Very c=
ool : )</div><div><br></div><div>Best regards,</div><div>Guillaume<br><br><=
div class=3D"gmail_quote">
On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <span dir=3D"ltr"><<a h=
ref=3D"mailto:mail@jutzig.de">mail@jutzig.de</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex;">
Hi,<br>
<br>
as discussed in <a href=3D"http://dev.eclipse.org/newslists/news.eclipse.to=
ols.buckminster/msg01102.html" target=3D"_blank">http://dev.eclipse.org/new=
slists/news.eclipse.tools.buckminster/msg01102.html</a> I started working o=
n a zest based component dependency viewer for buckminster.<br>
I just finished an early prototype and thought it's enough to =C2=A0get=
at least an idea and ask you guys what kinds of features you'd like to=
see in it.<br>
<br>
Currently this is (for sake of simplicity) registered as an editor for prev=
iously saved .bom files.<br>
It consists of 3 areas<br>
<br>
=C2=A0-navigation tree that shows a tree of the component dependencies and =
is used to drill down on the graph. The selection is linked to the graph vi=
ewer so if you select a component in the tree, only this specific subtree i=
s revealed in the graph.<br>
<br>
=C2=A0-graph viewer. This is very basic at the moment. It shows the depende=
ncy graph with some icons depending on the component type and highlights th=
e direct dependencies of the selected component. Unresolved nodes are shown=
in red, a double-click on a node reveals the node's cspec and that'=
;s about it :)<br>
<br>
=C2=A0-settings section. This section lets you choose between some layout a=
lgorithms and filters (only platform component filter so far). Filters are =
applied to both the navigation tree and the graph viewer.<br>
<br>
I came up with the following things that should be added:<br>
-better highlighting<br>
-tooltips and properties view that reveal more details of each component<br=
>
-smart highlighting of paths through the graph (shortest path to root reque=
st for example)<br>
-regex based filter (black and white list filter)<br>
-dependency reports generated from a bom with some nice pictures<br>
-zooming<br>
-image export<br>
<br>
Now I'd be very interested to hear what's on your wish-list for dep=
endency visualization, so that I can plan on the real implementation.<br>
Attached is a screenshot and a bundle.jar including source code. Just throw=
it in your dropins folder to try, but make sure that zest is installed.<br=
>
Keep in mind, this is just an early prototype for demonstration and my firs=
t steps with zest, so the code is super ugly at the moment...<br>
<br>
Best regards,<br><font color=3D"#888888">
Johannes<br>
</font><br>_______________________________________________ <br>
buckminster-dev mailing list<br>
<a href=3D"mailto:buckminster-dev@eclipse.org">buckminster-dev@eclipse.org<=
/a><br>
<a href=3D"https://dev.eclipse.org/mailman/listinfo/buckminster-dev" target=
=3D"_blank">https://dev.eclipse.org/mailman/listinfo/buckminster-dev</a><br=
>
<br></blockquote></div><br></div>
--0016367d69d84648d1046cff3096--
|
|
|
Re: [buckminster-dev] Dependency Visualization [message #35733 is a reply to message #35631] |
Tue, 23 June 2009 18:40 |
Dann Martens Messages: 65 Registered: July 2009 |
Member |
|
|
Wait a minute,
EMF? Zest, sure, but I would hope we could keep that behemoth out of
there, we're talking a configuration management tool here.
Best regards,
Dann
Guillaume Chatelet wrote:
> Wow Johannes ! This looks great : )
>
> UI is actually an issue in Buckminster and EMF + Zest will do a good job
> here. Very cool : )
>
> Best regards,
> Guillaume
>
> On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <mail@jutzig.de
> <mailto:mail@jutzig.de>> wrote:
>
> Hi,
>
> as discussed in
> http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.html
> I started working on a zest based component dependency viewer for
> buckminster.
> I just finished an early prototype and thought it's enough to get
> at least an idea and ask you guys what kinds of features you'd like
> to see in it.
>
> Currently this is (for sake of simplicity) registered as an editor
> for previously saved .bom files.
> It consists of 3 areas
>
> -navigation tree that shows a tree of the component dependencies
> and is used to drill down on the graph. The selection is linked to
> the graph viewer so if you select a component in the tree, only this
> specific subtree is revealed in the graph.
>
> -graph viewer. This is very basic at the moment. It shows the
> dependency graph with some icons depending on the component type and
> highlights the direct dependencies of the selected component.
> Unresolved nodes are shown in red, a double-click on a node reveals
> the node's cspec and that's about it :)
>
> -settings section. This section lets you choose between some layout
> algorithms and filters (only platform component filter so far).
> Filters are applied to both the navigation tree and the graph viewer.
>
> I came up with the following things that should be added:
> -better highlighting
> -tooltips and properties view that reveal more details of each component
> -smart highlighting of paths through the graph (shortest path to
> root request for example)
> -regex based filter (black and white list filter)
> -dependency reports generated from a bom with some nice pictures
> -zooming
> -image export
>
> Now I'd be very interested to hear what's on your wish-list for
> dependency visualization, so that I can plan on the real implementation.
> Attached is a screenshot and a bundle.jar including source code.
> Just throw it in your dropins folder to try, but make sure that zest
> is installed.
> Keep in mind, this is just an early prototype for demonstration and
> my first steps with zest, so the code is super ugly at the moment...
>
> Best regards,
> Johannes
>
> _______________________________________________
> buckminster-dev mailing list
> buckminster-dev@eclipse.org <mailto:buckminster-dev@eclipse.org>
> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>
>
|
|
|
Re: [buckminster-dev] Dependency Visualization [message #35768 is a reply to message #35733] |
Tue, 23 June 2009 21:33 |
|
Hi Dann,
A Buckminster runtime is one thing, the tools used to maintain it another. The runtime should be kept mean and lean,
that's for sure, and I think that is what your concern is about?
One thing that I've learned about EMF the last couple of weeks is that the runtime instances that it creates are very
optimized and in many cases far more optimal then the Java classes that people normally write. Booleans are grouped
together as bits in integer values, same thing with enums. I'm sure there's a lot of other optimizations going on as
well that I haven't found yet. All in all, I'm quite convinced that using EMF to describe things like our CSPEC, RMAP,
etc. will give us a smaller, less error prone, and more efficient runtime. The actual models themselves, visualized
graphically using the ecore tools diagram editor, will become valuable contributions to the documentation.
Then we have the tools surrounding it all. Editors for the model for instance. We get them for free with EMF. The
generated editor can be extended and improved a lot of course, but event the bare-bone generated thing beats the hell
out of using a text editor on XML documents. The generated editors are also very well crafted. Mean and lean. Easy to
extend and modify.
IMO EMF will become (and in some respect already is) a very valuable tool for us. Not sure I see why you'd think otherwise.
I have no experience with Zest but from the looks of it, it brings us a very good dependency visualization and that is
something that we have been longing for for some time now. Installing it will be optional of course.
Regards,
Thomas Hallgren
Dann Martens wrote:
> Wait a minute,
>
> EMF? Zest, sure, but I would hope we could keep that behemoth out of
> there, we're talking a configuration management tool here.
>
> Best regards,
> Dann
>
>
>
> Guillaume Chatelet wrote:
>> Wow Johannes ! This looks great : )
>>
>> UI is actually an issue in Buckminster and EMF + Zest will do a good
>> job here. Very cool : )
>>
>> Best regards,
>> Guillaume
>>
>> On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <mail@jutzig.de
>> <mailto:mail@jutzig.de>> wrote:
>>
>> Hi,
>>
>> as discussed in
>>
>> http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.html
>>
>> I started working on a zest based component dependency viewer for
>> buckminster.
>> I just finished an early prototype and thought it's enough to get
>> at least an idea and ask you guys what kinds of features you'd like
>> to see in it.
>>
>> Currently this is (for sake of simplicity) registered as an editor
>> for previously saved .bom files.
>> It consists of 3 areas
>>
>> -navigation tree that shows a tree of the component dependencies
>> and is used to drill down on the graph. The selection is linked to
>> the graph viewer so if you select a component in the tree, only this
>> specific subtree is revealed in the graph.
>>
>> -graph viewer. This is very basic at the moment. It shows the
>> dependency graph with some icons depending on the component type and
>> highlights the direct dependencies of the selected component.
>> Unresolved nodes are shown in red, a double-click on a node reveals
>> the node's cspec and that's about it :)
>>
>> -settings section. This section lets you choose between some layout
>> algorithms and filters (only platform component filter so far).
>> Filters are applied to both the navigation tree and the graph viewer.
>>
>> I came up with the following things that should be added:
>> -better highlighting
>> -tooltips and properties view that reveal more details of each
>> component
>> -smart highlighting of paths through the graph (shortest path to
>> root request for example)
>> -regex based filter (black and white list filter)
>> -dependency reports generated from a bom with some nice pictures
>> -zooming
>> -image export
>>
>> Now I'd be very interested to hear what's on your wish-list for
>> dependency visualization, so that I can plan on the real
>> implementation.
>> Attached is a screenshot and a bundle.jar including source code.
>> Just throw it in your dropins folder to try, but make sure that zest
>> is installed.
>> Keep in mind, this is just an early prototype for demonstration and
>> my first steps with zest, so the code is super ugly at the moment...
>>
>> Best regards,
>> Johannes
>>
>> _______________________________________________
>> buckminster-dev mailing list
>> buckminster-dev@eclipse.org <mailto:buckminster-dev@eclipse.org>
>> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>>
>>
|
|
|
Re: [buckminster-dev] Dependency Visualization [message #35802 is a reply to message #35768] |
Tue, 23 June 2009 21:47 |
Dann Martens Messages: 65 Registered: July 2009 |
Member |
|
|
Well yes,
I don't really want to go through the pain of having to install the EMF
plug-ins (ouch!) just to use Buckminster. I really hope you're not going
on that path because that sounds really terrible. I hope P2 changes
things, but installing EMF has been an incredible pain up to now.
Really, that's en emphatic no-no; I'd be really unhappy to see EMF
dependencies pulled in, just to use Buckminster. Actually, I have to sit
down, now. The idea of all that bloat is making my tummy ache.
Zest is just a wrapper around draw2D, and that's a totally different matter.
Best regards,
Dann
Thomas Hallgren wrote:
> Hi Dann,
> A Buckminster runtime is one thing, the tools used to maintain it
> another. The runtime should be kept mean and lean, that's for sure,
> and I think that is what your concern is about?
>
> One thing that I've learned about EMF the last couple of weeks is that
> the runtime instances that it creates are very optimized and in many
> cases far more optimal then the Java classes that people normally
> write. Booleans are grouped together as bits in integer values, same
> thing with enums. I'm sure there's a lot of other optimizations going
> on as well that I haven't found yet. All in all, I'm quite convinced
> that using EMF to describe things like our CSPEC, RMAP, etc. will give
> us a smaller, less error prone, and more efficient runtime. The actual
> models themselves, visualized graphically using the ecore tools
> diagram editor, will become valuable contributions to the documentation.
>
> Then we have the tools surrounding it all. Editors for the model for
> instance. We get them for free with EMF. The generated editor can be
> extended and improved a lot of course, but event the bare-bone
> generated thing beats the hell out of using a text editor on XML
> documents. The generated editors are also very well crafted. Mean and
> lean. Easy to extend and modify.
>
> IMO EMF will become (and in some respect already is) a very valuable
> tool for us. Not sure I see why you'd think otherwise.
>
> I have no experience with Zest but from the looks of it, it brings us
> a very good dependency visualization and that is something that we
> have been longing for for some time now. Installing it will be
> optional of course.
>
> Regards,
> Thomas Hallgren
>
>
> Dann Martens wrote:
>> Wait a minute,
>>
>> EMF? Zest, sure, but I would hope we could keep that behemoth out of
>> there, we're talking a configuration management tool here.
>>
>> Best regards,
>> Dann
>>
>>
>>
>> Guillaume Chatelet wrote:
>>> Wow Johannes ! This looks great : )
>>>
>>> UI is actually an issue in Buckminster and EMF + Zest will do a good
>>> job here. Very cool : )
>>>
>>> Best regards,
>>> Guillaume
>>>
>>> On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <mail@jutzig.de
>>> <mailto:mail@jutzig.de>> wrote:
>>>
>>> Hi,
>>>
>>> as discussed in
>>>
>>> http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.html
>>>
>>> I started working on a zest based component dependency viewer for
>>> buckminster.
>>> I just finished an early prototype and thought it's enough to get
>>> at least an idea and ask you guys what kinds of features you'd like
>>> to see in it.
>>>
>>> Currently this is (for sake of simplicity) registered as an editor
>>> for previously saved .bom files.
>>> It consists of 3 areas
>>>
>>> -navigation tree that shows a tree of the component dependencies
>>> and is used to drill down on the graph. The selection is linked to
>>> the graph viewer so if you select a component in the tree, only
>>> this
>>> specific subtree is revealed in the graph.
>>>
>>> -graph viewer. This is very basic at the moment. It shows the
>>> dependency graph with some icons depending on the component type
>>> and
>>> highlights the direct dependencies of the selected component.
>>> Unresolved nodes are shown in red, a double-click on a node reveals
>>> the node's cspec and that's about it :)
>>>
>>> -settings section. This section lets you choose between some
>>> layout
>>> algorithms and filters (only platform component filter so far).
>>> Filters are applied to both the navigation tree and the graph
>>> viewer.
>>>
>>> I came up with the following things that should be added:
>>> -better highlighting
>>> -tooltips and properties view that reveal more details of each
>>> component
>>> -smart highlighting of paths through the graph (shortest path to
>>> root request for example)
>>> -regex based filter (black and white list filter)
>>> -dependency reports generated from a bom with some nice pictures
>>> -zooming
>>> -image export
>>>
>>> Now I'd be very interested to hear what's on your wish-list for
>>> dependency visualization, so that I can plan on the real
>>> implementation.
>>> Attached is a screenshot and a bundle.jar including source code.
>>> Just throw it in your dropins folder to try, but make sure that
>>> zest
>>> is installed.
>>> Keep in mind, this is just an early prototype for demonstration and
>>> my first steps with zest, so the code is super ugly at the
>>> moment...
>>>
>>> Best regards,
>>> Johannes
>>>
>>> _______________________________________________
>>> buckminster-dev mailing list
>>> buckminster-dev@eclipse.org <mailto:buckminster-dev@eclipse.org>
>>> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>>>
>>>
>
|
|
|
Re: [buckminster-dev] Dependency Visualization [message #35837 is a reply to message #35802] |
Wed, 24 June 2009 00:05 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Dann,
Naturally I don't think of EMF has a behemoth. :-P
I suppose if you consider the all-in-one-sdk zip, which includes each
and every fine-grained EMF feature along with the fine-grained XSD
features (that you don't need), at grand total of 27MB, you might
consider that a behemoth. But then, I'm not sure what that makes
Eclipse itself at 150MB+. The behemoth that chokes all behemoths?
Surely you're not suggesting that an additional < 20% of downloads would
be the end of the world? The core EMF runtime is tiny, i.e., 2 MB, and
even the EMF features needed to support viewing are tiny, a few more
MB. We're talking tools at this point, not runtime, at Thomas pointed
out, though I'm not sure that matters to you...
I'm just not sure at which point the "terrible pain" kicks in though...
Of course p2 changes the game entirely. Only the features you actually
need need be installed...
Maybe you could elaborate on the incredibly painful experiences you've
had with installing EMF. Is it the download rate that's the problem?
The long unzip times? Something else? Many millions of people are
installing EMF, even just to install WTP, and I've not heard about a
great many incredibly painful events. People tend to complain loudly so
I'm pretty sure I would have heard about painful things...
At some point in the future, i.e., the e4 future, EMF will already be in
the platform installation itself, because it's being used to model the
workbench, so you're bound to be unhappy eventually if EMF itself makes
you unhappy. I suppose perhaps eventually you just won't notice EMF's
presence...
I hope you're sitting down already. Maybe lying down would be better. :-P
I've seen many arguments about avoid bloat. Unfortunately they usually
involve each project inventing its own solution to the same common
problem. The net result is that there end up being dozens of solutions
to exactly the same problem. That's also bloat; the worst kind. It's
ironic to me that avoiding bloat causes bloat, but that always seems to
be the way...
Probably you need to get over your aversion, or be more specific about it...
Dann Martens wrote:
> Well yes,
>
> I don't really want to go through the pain of having to install the
> EMF plug-ins (ouch!) just to use Buckminster. I really hope you're not
> going on that path because that sounds really terrible. I hope P2
> changes things, but installing EMF has been an incredible pain up to
> now. Really, that's en emphatic no-no; I'd be really unhappy to see
> EMF dependencies pulled in, just to use Buckminster. Actually, I have
> to sit down, now. The idea of all that bloat is making my tummy ache.
>
> Zest is just a wrapper around draw2D, and that's a totally different
> matter.
>
> Best regards,
> Dann
>
>
>
> Thomas Hallgren wrote:
>> Hi Dann,
>> A Buckminster runtime is one thing, the tools used to maintain it
>> another. The runtime should be kept mean and lean, that's for sure,
>> and I think that is what your concern is about?
>>
>> One thing that I've learned about EMF the last couple of weeks is
>> that the runtime instances that it creates are very optimized and in
>> many cases far more optimal then the Java classes that people
>> normally write. Booleans are grouped together as bits in integer
>> values, same thing with enums. I'm sure there's a lot of other
>> optimizations going on as well that I haven't found yet. All in all,
>> I'm quite convinced that using EMF to describe things like our CSPEC,
>> RMAP, etc. will give us a smaller, less error prone, and more
>> efficient runtime. The actual models themselves, visualized
>> graphically using the ecore tools diagram editor, will become
>> valuable contributions to the documentation.
>>
>> Then we have the tools surrounding it all. Editors for the model for
>> instance. We get them for free with EMF. The generated editor can be
>> extended and improved a lot of course, but event the bare-bone
>> generated thing beats the hell out of using a text editor on XML
>> documents. The generated editors are also very well crafted. Mean and
>> lean. Easy to extend and modify.
>>
>> IMO EMF will become (and in some respect already is) a very valuable
>> tool for us. Not sure I see why you'd think otherwise.
>>
>> I have no experience with Zest but from the looks of it, it brings us
>> a very good dependency visualization and that is something that we
>> have been longing for for some time now. Installing it will be
>> optional of course.
>>
>> Regards,
>> Thomas Hallgren
>>
>>
>> Dann Martens wrote:
>>> Wait a minute,
>>>
>>> EMF? Zest, sure, but I would hope we could keep that behemoth out of
>>> there, we're talking a configuration management tool here.
>>>
>>> Best regards,
>>> Dann
>>>
>>>
>>>
>>> Guillaume Chatelet wrote:
>>>> Wow Johannes ! This looks great : )
>>>>
>>>> UI is actually an issue in Buckminster and EMF + Zest will do a
>>>> good job here. Very cool : )
>>>>
>>>> Best regards,
>>>> Guillaume
>>>>
>>>> On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <mail@jutzig.de
>>>> <mailto:mail@jutzig.de>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> as discussed in
>>>>
>>>> http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.html
>>>>
>>>> I started working on a zest based component dependency viewer for
>>>> buckminster.
>>>> I just finished an early prototype and thought it's enough to get
>>>> at least an idea and ask you guys what kinds of features you'd
>>>> like
>>>> to see in it.
>>>>
>>>> Currently this is (for sake of simplicity) registered as an editor
>>>> for previously saved .bom files.
>>>> It consists of 3 areas
>>>>
>>>> -navigation tree that shows a tree of the component dependencies
>>>> and is used to drill down on the graph. The selection is linked to
>>>> the graph viewer so if you select a component in the tree, only
>>>> this
>>>> specific subtree is revealed in the graph.
>>>>
>>>> -graph viewer. This is very basic at the moment. It shows the
>>>> dependency graph with some icons depending on the component
>>>> type and
>>>> highlights the direct dependencies of the selected component.
>>>> Unresolved nodes are shown in red, a double-click on a node
>>>> reveals
>>>> the node's cspec and that's about it :)
>>>>
>>>> -settings section. This section lets you choose between some
>>>> layout
>>>> algorithms and filters (only platform component filter so far).
>>>> Filters are applied to both the navigation tree and the graph
>>>> viewer.
>>>>
>>>> I came up with the following things that should be added:
>>>> -better highlighting
>>>> -tooltips and properties view that reveal more details of each
>>>> component
>>>> -smart highlighting of paths through the graph (shortest path to
>>>> root request for example)
>>>> -regex based filter (black and white list filter)
>>>> -dependency reports generated from a bom with some nice pictures
>>>> -zooming
>>>> -image export
>>>>
>>>> Now I'd be very interested to hear what's on your wish-list for
>>>> dependency visualization, so that I can plan on the real
>>>> implementation.
>>>> Attached is a screenshot and a bundle.jar including source code.
>>>> Just throw it in your dropins folder to try, but make sure that
>>>> zest
>>>> is installed.
>>>> Keep in mind, this is just an early prototype for demonstration
>>>> and
>>>> my first steps with zest, so the code is super ugly at the
>>>> moment...
>>>>
>>>> Best regards,
>>>> Johannes
>>>>
>>>> _______________________________________________
>>>> buckminster-dev mailing list
>>>> buckminster-dev@eclipse.org <mailto:buckminster-dev@eclipse.org>
>>>> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>>>>
>>>>
>>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [buckminster-dev] Dependency Visualization [message #35871 is a reply to message #35837] |
Wed, 24 June 2009 00:49 |
Dann Martens Messages: 65 Registered: July 2009 |
Member |
|
|
Hi Ed,
First of all, I have no aversion to EMF. But the model-driven approach
does bring a lot of overhead to enable all that meta-modeling. Must be
the 'meta' thing ;)
I'm not so sure you're response is that honest in terms of installation
pain. Installing WTP can be an unbelievable pain, and I'm sure I'm not
the only one saying that. The amount of times I just got stuck with an
Eclipse set-up which wouldn't install additional plug-ins because of
EMF-related plug-in mismatches... I simply can't count those instances
anymore. You'll probably say that's not EMF's fault per se, but EMF is
always implicated.
Because EMF is high up in the dependency hierarchy, it is one of those
projects which exposes Eclipse dependency problems the most. You're
probably referring to 'just EMF', but I'm talking about getting those
EMF-based projects to get along, which has been a *real* pain.
Building EMF with Buckminster is one thing, but if you already need an
instance of EMF before you can do that? How about those circular build
dependencies? Back to the dark woods of the PDE build?
Perhaps I better start a fork, right here and now and maintain a bit of
peace of mind...
Best regards,
Dann
Ed Merks wrote:
> Dann,
>
> Naturally I don't think of EMF has a behemoth. :-P
> I suppose if you consider the all-in-one-sdk zip, which includes each
> and every fine-grained EMF feature along with the fine-grained XSD
> features (that you don't need), at grand total of 27MB, you might
> consider that a behemoth. But then, I'm not sure what that makes
> Eclipse itself at 150MB+. The behemoth that chokes all behemoths?
>
> Surely you're not suggesting that an additional < 20% of downloads would
> be the end of the world? The core EMF runtime is tiny, i.e., 2 MB, and
> even the EMF features needed to support viewing are tiny, a few more
> MB. We're talking tools at this point, not runtime, at Thomas pointed
> out, though I'm not sure that matters to you...
>
> I'm just not sure at which point the "terrible pain" kicks in though...
>
> Of course p2 changes the game entirely. Only the features you actually
> need need be installed...
>
> Maybe you could elaborate on the incredibly painful experiences you've
> had with installing EMF. Is it the download rate that's the problem?
> The long unzip times? Something else? Many millions of people are
> installing EMF, even just to install WTP, and I've not heard about a
> great many incredibly painful events. People tend to complain loudly so
> I'm pretty sure I would have heard about painful things...
>
> At some point in the future, i.e., the e4 future, EMF will already be in
> the platform installation itself, because it's being used to model the
> workbench, so you're bound to be unhappy eventually if EMF itself makes
> you unhappy. I suppose perhaps eventually you just won't notice EMF's
> presence...
>
> I hope you're sitting down already. Maybe lying down would be better. :-P
>
> I've seen many arguments about avoid bloat. Unfortunately they usually
> involve each project inventing its own solution to the same common
> problem. The net result is that there end up being dozens of solutions
> to exactly the same problem. That's also bloat; the worst kind. It's
> ironic to me that avoiding bloat causes bloat, but that always seems to
> be the way...
>
> Probably you need to get over your aversion, or be more specific about
> it...
>
>
> Dann Martens wrote:
>> Well yes,
>>
>> I don't really want to go through the pain of having to install the
>> EMF plug-ins (ouch!) just to use Buckminster. I really hope you're not
>> going on that path because that sounds really terrible. I hope P2
>> changes things, but installing EMF has been an incredible pain up to
>> now. Really, that's en emphatic no-no; I'd be really unhappy to see
>> EMF dependencies pulled in, just to use Buckminster. Actually, I have
>> to sit down, now. The idea of all that bloat is making my tummy ache.
>>
>> Zest is just a wrapper around draw2D, and that's a totally different
>> matter.
>>
>> Best regards,
>> Dann
>>
>>
>>
>> Thomas Hallgren wrote:
>>> Hi Dann,
>>> A Buckminster runtime is one thing, the tools used to maintain it
>>> another. The runtime should be kept mean and lean, that's for sure,
>>> and I think that is what your concern is about?
>>>
>>> One thing that I've learned about EMF the last couple of weeks is
>>> that the runtime instances that it creates are very optimized and in
>>> many cases far more optimal then the Java classes that people
>>> normally write. Booleans are grouped together as bits in integer
>>> values, same thing with enums. I'm sure there's a lot of other
>>> optimizations going on as well that I haven't found yet. All in all,
>>> I'm quite convinced that using EMF to describe things like our CSPEC,
>>> RMAP, etc. will give us a smaller, less error prone, and more
>>> efficient runtime. The actual models themselves, visualized
>>> graphically using the ecore tools diagram editor, will become
>>> valuable contributions to the documentation.
>>>
>>> Then we have the tools surrounding it all. Editors for the model for
>>> instance. We get them for free with EMF. The generated editor can be
>>> extended and improved a lot of course, but event the bare-bone
>>> generated thing beats the hell out of using a text editor on XML
>>> documents. The generated editors are also very well crafted. Mean and
>>> lean. Easy to extend and modify.
>>>
>>> IMO EMF will become (and in some respect already is) a very valuable
>>> tool for us. Not sure I see why you'd think otherwise.
>>>
>>> I have no experience with Zest but from the looks of it, it brings us
>>> a very good dependency visualization and that is something that we
>>> have been longing for for some time now. Installing it will be
>>> optional of course.
>>>
>>> Regards,
>>> Thomas Hallgren
>>>
>>>
>>> Dann Martens wrote:
>>>> Wait a minute,
>>>>
>>>> EMF? Zest, sure, but I would hope we could keep that behemoth out of
>>>> there, we're talking a configuration management tool here.
>>>>
>>>> Best regards,
>>>> Dann
>>>>
>>>>
>>>>
>>>> Guillaume Chatelet wrote:
>>>>> Wow Johannes ! This looks great : )
>>>>>
>>>>> UI is actually an issue in Buckminster and EMF + Zest will do a
>>>>> good job here. Very cool : )
>>>>>
>>>>> Best regards,
>>>>> Guillaume
>>>>>
>>>>> On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <mail@jutzig.de
>>>>> <mailto:mail@jutzig.de>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> as discussed in
>>>>>
>>>>> http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.html
>>>>>
>>>>> I started working on a zest based component dependency viewer for
>>>>> buckminster.
>>>>> I just finished an early prototype and thought it's enough to get
>>>>> at least an idea and ask you guys what kinds of features you'd
>>>>> like
>>>>> to see in it.
>>>>>
>>>>> Currently this is (for sake of simplicity) registered as an editor
>>>>> for previously saved .bom files.
>>>>> It consists of 3 areas
>>>>>
>>>>> -navigation tree that shows a tree of the component dependencies
>>>>> and is used to drill down on the graph. The selection is linked to
>>>>> the graph viewer so if you select a component in the tree, only
>>>>> this
>>>>> specific subtree is revealed in the graph.
>>>>>
>>>>> -graph viewer. This is very basic at the moment. It shows the
>>>>> dependency graph with some icons depending on the component
>>>>> type and
>>>>> highlights the direct dependencies of the selected component.
>>>>> Unresolved nodes are shown in red, a double-click on a node
>>>>> reveals
>>>>> the node's cspec and that's about it :)
>>>>>
>>>>> -settings section. This section lets you choose between some
>>>>> layout
>>>>> algorithms and filters (only platform component filter so far).
>>>>> Filters are applied to both the navigation tree and the graph
>>>>> viewer.
>>>>>
>>>>> I came up with the following things that should be added:
>>>>> -better highlighting
>>>>> -tooltips and properties view that reveal more details of each
>>>>> component
>>>>> -smart highlighting of paths through the graph (shortest path to
>>>>> root request for example)
>>>>> -regex based filter (black and white list filter)
>>>>> -dependency reports generated from a bom with some nice pictures
>>>>> -zooming
>>>>> -image export
>>>>>
>>>>> Now I'd be very interested to hear what's on your wish-list for
>>>>> dependency visualization, so that I can plan on the real
>>>>> implementation.
>>>>> Attached is a screenshot and a bundle.jar including source code.
>>>>> Just throw it in your dropins folder to try, but make sure that
>>>>> zest
>>>>> is installed.
>>>>> Keep in mind, this is just an early prototype for demonstration
>>>>> and
>>>>> my first steps with zest, so the code is super ugly at the
>>>>> moment...
>>>>>
>>>>> Best regards,
>>>>> Johannes
>>>>>
>>>>> _______________________________________________
>>>>> buckminster-dev mailing list
>>>>> buckminster-dev@eclipse.org <mailto:buckminster-dev@eclipse.org>
>>>>> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>>>>>
>>>>>
>>>
|
|
|
Re: [buckminster-dev] Dependency Visualization [message #35909 is a reply to message #35871] |
Wed, 24 June 2009 01:14 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------030002040002000400070306
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Dann,
Comments below.
Dann Martens wrote:
> Hi Ed,
>
> First of all, I have no aversion to EMF.
It sounds like one though...
> But the model-driven approach does bring a lot of overhead to enable
> all that meta-modeling.
Overhead? Meta-modeling?
> Must be the 'meta' thing ;)
I'm not a big fan of the word meta. Probably you know that, but perhaps
you don't... The model of a model is a model...
>
> I'm not so sure you're response is that honest in terms of
> installation pain.
Honesty is a fundamental quality I hold dear. Very few people question
my honesty. Certainly it's your prerogative to do that, and in that
case, I'll reserve the right to question yours.
> Installing WTP can be an unbelievable pain, and I'm sure I'm not the
> only one saying that.
I've not installed WTP, so personally I have no idea. I've only ever
install the platform and then I bootstrap EMF (and a dozen or more other
projects) from CVS, so in all honesty, I can say I have little
experience installing anything...
> The amount of times I just got stuck with an Eclipse set-up which
> wouldn't install additional plug-ins because of EMF-related plug-in
> mismatches...
Again, I have no idea what you mean by "install". You mean update
manager, unzipping files, p2, or what?
> I simply can't count those instances anymore.
I can imagine the pain, though I've not experienced it. Of course if
installing one more thing on top of the platform is a huge pain, then
even installing Buckminster as one additional thing must be painful
already. If not, why not? I suppose you mean installing two different
things each of which depends on EMF, but instead you might want to blame
that pain on bad plugin version ranges, the platform's treatment of
them, and the universal belief that they represent goodness, rather than
blame EMF...
> You'll probably say that's not EMF's fault per se, but EMF is always
> implicated.
I've very used to being a scapegoat.
http://ed-merks.blogspot.com/2009/03/on-being-scapegoat.html
In the end though, there's little of substance in the scapegoating, so
it's just a form of entertainment for me. Folly in other words...
>
> Because EMF is high up in the dependency hierarchy, it is one of those
> projects which exposes Eclipse dependency problems the most.
Or low down, depending on which direction you grow. But yes, being a
foundation component makes for being a great scapegoat. It seems as if
you're arguing to avoid having foundation components because that way we
can avoid seeing dependency problems. That's clearly a questionable
argument.
> You're probably referring to 'just EMF', but I'm talking about getting
> those EMF-based projects to get along, which has been a *real* pain.
I guess that's a pain, but since you have to do that anyway, or so it
seems, I'm not sure how your problem got worse. In any case, you've not
provided one iota of substance. Just scapegoating EMF and finger
pointing in the typical way that's grown tiresome over the years.
>
> Building EMF with Buckminster is one thing,
A totally unrelated thing in fact...
> but if you already need an instance of EMF before you can do that?
Isn't bootstrapping fun. That's irrelevant to you though, since you
aren't building EMF. Why bring it up?
In any case, one needs an instance of EMF to generate EMF. That sounds
impossible?
> How about those circular build dependencies?
I guess it's impossible although we do this all the time.
> Back to the dark woods of the PDE build?
I guess PDE build is the dark wood, but I don't see the connection.
>
> Perhaps I better start a fork, right here and now and maintain a bit
> of peace of mind...
I guess so. Peace of mind is a valuable commodity so it's probably worth
just about any price.
In any case, I don't think you've done a good job arguing you have no
aversions. Your line of reasoning would seem to argue that it's a bad
idea to have common foundation components because there are dependency
problems when many projects depend on such foundation components.
Perhaps we ought to focus on those so they're fixed rather than throw
away good architecture concepts...
>
>
> Best regards,
> Dann
>
>
>
>
> Ed Merks wrote:
>> Dann,
>>
>> Naturally I don't think of EMF has a behemoth. :-P
>> I suppose if you consider the all-in-one-sdk zip, which includes each
>> and every fine-grained EMF feature along with the fine-grained XSD
>> features (that you don't need), at grand total of 27MB, you might
>> consider that a behemoth. But then, I'm not sure what that makes
>> Eclipse itself at 150MB+. The behemoth that chokes all behemoths?
>>
>> Surely you're not suggesting that an additional < 20% of downloads
>> would be the end of the world? The core EMF runtime is tiny, i.e.,
>> 2 MB, and even the EMF features needed to support viewing are tiny, a
>> few more MB. We're talking tools at this point, not runtime, at
>> Thomas pointed out, though I'm not sure that matters to you...
>>
>> I'm just not sure at which point the "terrible pain" kicks in though...
>>
>> Of course p2 changes the game entirely. Only the features you
>> actually need need be installed...
>>
>> Maybe you could elaborate on the incredibly painful experiences
>> you've had with installing EMF. Is it the download rate that's the
>> problem? The long unzip times? Something else? Many millions of
>> people are installing EMF, even just to install WTP, and I've not
>> heard about a great many incredibly painful events. People tend to
>> complain loudly so I'm pretty sure I would have heard about painful
>> things...
>>
>> At some point in the future, i.e., the e4 future, EMF will already be
>> in the platform installation itself, because it's being used to model
>> the workbench, so you're bound to be unhappy eventually if EMF itself
>> makes you unhappy. I suppose perhaps eventually you just won't
>> notice EMF's presence...
>>
>> I hope you're sitting down already. Maybe lying down would be
>> better. :-P
>>
>> I've seen many arguments about avoid bloat. Unfortunately they
>> usually involve each project inventing its own solution to the same
>> common problem. The net result is that there end up being dozens of
>> solutions to exactly the same problem. That's also bloat; the worst
>> kind. It's ironic to me that avoiding bloat causes bloat, but that
>> always seems to be the way...
>>
>> Probably you need to get over your aversion, or be more specific
>> about it...
>>
>>
>> Dann Martens wrote:
>>> Well yes,
>>>
>>> I don't really want to go through the pain of having to install the
>>> EMF plug-ins (ouch!) just to use Buckminster. I really hope you're
>>> not going on that path because that sounds really terrible. I hope
>>> P2 changes things, but installing EMF has been an incredible pain up
>>> to now. Really, that's en emphatic no-no; I'd be really unhappy to
>>> see EMF dependencies pulled in, just to use Buckminster. Actually, I
>>> have to sit down, now. The idea of all that bloat is making my tummy
>>> ache.
>>>
>>> Zest is just a wrapper around draw2D, and that's a totally different
>>> matter.
>>>
>>> Best regards,
>>> Dann
>>>
>>>
>>>
>>> Thomas Hallgren wrote:
>>>> Hi Dann,
>>>> A Buckminster runtime is one thing, the tools used to maintain it
>>>> another. The runtime should be kept mean and lean, that's for sure,
>>>> and I think that is what your concern is about?
>>>>
>>>> One thing that I've learned about EMF the last couple of weeks is
>>>> that the runtime instances that it creates are very optimized and
>>>> in many cases far more optimal then the Java classes that people
>>>> normally write. Booleans are grouped together as bits in integer
>>>> values, same thing with enums. I'm sure there's a lot of other
>>>> optimizations going on as well that I haven't found yet. All in
>>>> all, I'm quite convinced that using EMF to describe things like our
>>>> CSPEC, RMAP, etc. will give us a smaller, less error prone, and
>>>> more efficient runtime. The actual models themselves, visualized
>>>> graphically using the ecore tools diagram editor, will become
>>>> valuable contributions to the documentation.
>>>>
>>>> Then we have the tools surrounding it all. Editors for the model
>>>> for instance. We get them for free with EMF. The generated editor
>>>> can be extended and improved a lot of course, but event the
>>>> bare-bone generated thing beats the hell out of using a text editor
>>>> on XML documents. The generated editors are also very well crafted.
>>>> Mean and lean. Easy to extend and modify.
>>>>
>>>> IMO EMF will become (and in some respect already is) a very
>>>> valuable tool for us. Not sure I see why you'd think otherwise.
>>>>
>>>> I have no experience with Zest but from the looks of it, it brings
>>>> us a very good dependency visualization and that is something that
>>>> we have been longing for for some time now. Installing it will be
>>>> optional of course.
>>>>
>>>> Regards,
>>>> Thomas Hallgren
>>>>
>>>>
>>>> Dann Martens wrote:
>>>>> Wait a minute,
>>>>>
>>>>> EMF? Zest, sure, but I would hope we could keep that behemoth out
>>>>> of there, we're talking a configuration management tool here.
>>>>>
>>>>> Best regards,
>>>>> Dann
>>>>>
>>>>>
>>>>>
>>>>> Guillaume Chatelet wrote:
>>>>>> Wow Johannes ! This looks great : )
>>>>>>
>>>>>> UI is actually an issue in Buckminster and EMF + Zest will do a
>>>>>> good job here. Very cool : )
>>>>>>
>>>>>> Best regards,
>>>>>> Guillaume
>>>>>>
>>>>>> On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <mail@jutzig.de
>>>>>> <mailto:mail@jutzig.de>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> as discussed in
>>>>>>
>>>>>> http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.html
>>>>>>
>>>>>> I started working on a zest based component dependency viewer
>>>>>> for
>>>>>> buckminster.
>>>>>> I just finished an early prototype and thought it's enough
>>>>>> to get
>>>>>> at least an idea and ask you guys what kinds of features
>>>>>> you'd like
>>>>>> to see in it.
>>>>>>
>>>>>> Currently this is (for sake of simplicity) registered as an
>>>>>> editor
>>>>>> for previously saved .bom files.
>>>>>> It consists of 3 areas
>>>>>>
>>>>>> -navigation tree that shows a tree of the component
>>>>>> dependencies
>>>>>> and is used to drill down on the graph. The selection is
>>>>>> linked to
>>>>>> the graph viewer so if you select a component in the tree,
>>>>>> only this
>>>>>> specific subtree is revealed in the graph.
>>>>>>
>>>>>> -graph viewer. This is very basic at the moment. It shows the
>>>>>> dependency graph with some icons depending on the component
>>>>>> type and
>>>>>> highlights the direct dependencies of the selected component.
>>>>>> Unresolved nodes are shown in red, a double-click on a node
>>>>>> reveals
>>>>>> the node's cspec and that's about it :)
>>>>>>
>>>>>> -settings section. This section lets you choose between some
>>>>>> layout
>>>>>> algorithms and filters (only platform component filter so far).
>>>>>> Filters are applied to both the navigation tree and the graph
>>>>>> viewer.
>>>>>>
>>>>>> I came up with the following things that should be added:
>>>>>> -better highlighting
>>>>>> -tooltips and properties view that reveal more details of
>>>>>> each component
>>>>>> -smart highlighting of paths through the graph (shortest path to
>>>>>> root request for example)
>>>>>> -regex based filter (black and white list filter)
>>>>>> -dependency reports generated from a bom with some nice pictures
>>>>>> -zooming
>>>>>> -image export
>>>>>>
>>>>>> Now I'd be very interested to hear what's on your wish-list for
>>>>>> dependency visualization, so that I can plan on the real
>>>>>> implementation.
>>>>>> Attached is a screenshot and a bundle.jar including source code.
>>>>>> Just throw it in your dropins folder to try, but make sure
>>>>>> that zest
>>>>>> is installed.
>>>>>> Keep in mind, this is just an early prototype for
>>>>>> demonstration and
>>>>>> my first steps with zest, so the code is super ugly at the
>>>>>> moment...
>>>>>>
>>>>>> Best regards,
>>>>>> Johannes
>>>>>>
>>>>>> _______________________________________________
>>>>>> buckminster-dev mailing list
>>>>>> buckminster-dev@eclipse.org <mailto:buckminster-dev@eclipse.org>
>>>>>> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>>>>>>
>>>>>>
>>>>
>
>
--------------030002040002000400070306
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dann,<br>
<br>
Comments below.<br>
<br>
Dann Martens wrote:
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite">Hi Ed,
<br>
<br>
First of all, I have no aversion to EMF. </blockquote>
It sounds like one though...<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite">But the
model-driven approach does bring a lot of overhead to enable all that
meta-modeling. </blockquote>
Overhead? Meta-modeling?<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite">Must be
the 'meta' thing ;)
<br>
</blockquote>
I'm not a big fan of the word meta. Probably you know that, but
perhaps you don't... The model of a model is a model... <br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"><br>
I'm not so sure you're response is that honest in terms of installation
pain.</blockquote>
Honesty is a fundamental quality I hold dear. Very few people question
my honesty. Certainly it's your prerogative to do that, and in that
case, I'll reserve the right to question yours.<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite">Installing
WTP can be an unbelievable pain, and I'm sure I'm not the only one
saying that.</blockquote>
I've not installed WTP, so personally I have no idea. I've only ever
install the platform and then I bootstrap EMF (and a dozen or more
other projects) from CVS, so in all honesty, I can say I have little
experience installing anything...<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"> The
amount of times I just got stuck with an Eclipse set-up which wouldn't
install additional plug-ins because of EMF-related plug-in mismatches...</blockquote>
Again, I have no idea what you mean by "install". You mean update
manager, unzipping files, p2, or what?<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"> I
simply can't count those instances anymore.</blockquote>
I can imagine the pain, though I've not experienced it. Of course if
installing one more thing on top of the platform is a huge pain, then
even installing Buckminster as one additional thing must be painful
already. If not, why not? I suppose you mean installing two different
things each of which depends on EMF, but instead you might want to
blame that pain on bad plugin version ranges, the platform's treatment
of them, and the universal belief that they represent goodness, rather
than blame EMF...<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"> You'll
probably say that's not EMF's fault per se, but EMF is always
implicated.
<br>
</blockquote>
I've very used to being a scapegoat. <br>
<blockquote><a
href=" http://ed-merks.blogspot.com/2009/03/on-being-scapegoat.html"> http://ed-merks.blogspot.com/2009/03/on-being-scapegoat.html</a><br>
</blockquote>
In the end though, there's little of substance in the scapegoating, so
it's just a form of entertainment for me. Folly in other words...<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"><br>
Because EMF is high up in the dependency hierarchy, it is one of those
projects which exposes Eclipse dependency problems the most.</blockquote>
Or low down, depending on which direction you grow. But yes, being a
foundation component makes for being a great scapegoat. It seems as if
you're arguing to avoid having foundation components because that way
we can avoid seeing dependency problems. That's clearly a questionable
argument.<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"> You're
probably referring to 'just EMF', but I'm talking about getting those
EMF-based projects to get along, which has been a *real* pain.
<br>
</blockquote>
I guess that's a pain, but since you have to do that anyway, or so it
seems, I'm not sure how your problem got worse. In any case, you've
not provided one iota of substance. Just scapegoating EMF and finger
pointing in the typical way that's grown tiresome over the years.<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"><br>
Building EMF with Buckminster is one thing, </blockquote>
A totally unrelated thing in fact...<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite">but if
you already need an instance of EMF before you can do that? </blockquote>
Isn't bootstrapping fun. That's irrelevant to you though, since you
aren't building EMF. Why bring it up?<br>
<br>
In any case, one needs an instance of EMF to generate EMF. That sounds
impossible?<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite">How
about those circular build dependencies?</blockquote>
I guess it's impossible although we do this all the time.<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"> Back
to the dark woods of the PDE build?
<br>
</blockquote>
I guess PDE build is the dark wood, but I don't see the connection.<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"><br>
Perhaps I better start a fork, right here and now and maintain a bit of
peace of mind...</blockquote>
I guess so. Peace of mind is a valuable commodity so it's probably
worth just about any price.<br>
<br>
In any case, I don't think you've done a good job arguing you have no
aversions. Your line of reasoning would seem to argue that it's a bad
idea to have common foundation components because there are dependency
problems when many projects depend on such foundation components.
Perhaps we ought to focus on those so they're fixed rather than throw
away good architecture concepts...<br>
<blockquote cite="mid:4A41780D.6020504@tomoton.com" type="cite"><br>
<br>
Best regards,
<br>
Dann
<br>
<br>
<br>
<br>
<br>
Ed Merks wrote:
<br>
<blockquote type="cite">Dann,
<br>
<br>
Naturally I don't think of EMF has a behemoth. :-P
<br>
I suppose if you consider the all-in-one-sdk zip, which includes each
and every fine-grained EMF feature along with the fine-grained XSD
features (that you don't need), at grand total of 27MB, you might
consider that a behemoth. But then, I'm not sure what that makes
Eclipse itself at 150MB+. The behemoth that chokes all behemoths?
<br>
<br>
Surely you're not suggesting that an additional < 20% of downloads
would be the end of the world? The core EMF runtime is tiny, i.e., 2
MB, and even the EMF features needed to support viewing are tiny, a few
more MB. We're talking tools at this point, not runtime, at Thomas
pointed out, though I'm not sure that matters to you...
<br>
<br>
I'm just not sure at which point the "terrible pain" kicks in though...
<br>
<br>
Of course p2 changes the game entirely. Only the features you actually
need need be installed...
<br>
<br>
Maybe you could elaborate on the incredibly painful experiences you've
had with installing EMF. Is it the download rate that's the problem?
The long unzip times? Something else? Many millions of people are
installing EMF, even just to install WTP, and I've not heard about a
great many incredibly painful events. People tend to complain loudly
so I'm pretty sure I would have heard about painful things...
<br>
<br>
At some point in the future, i.e., the e4 future, EMF will already be
in the platform installation itself, because it's being used to model
the workbench, so you're bound to be unhappy eventually if EMF itself
makes you unhappy. I suppose perhaps eventually you just won't notice
EMF's presence...
<br>
<br>
I hope you're sitting down already. Maybe lying down would be better.
:-P
<br>
<br>
I've seen many arguments about avoid bloat. Unfortunately they usually
involve each project inventing its own solution to the same common
problem. The net result is that there end up being dozens of solutions
to exactly the same problem. That's also bloat; the worst kind. It's
ironic to me that avoiding bloat causes bloat, but that always seems to
be the way...
<br>
<br>
Probably you need to get over your aversion, or be more specific about
it...
<br>
<br>
<br>
Dann Martens wrote:
<br>
<blockquote type="cite">Well yes,
<br>
<br>
I don't really want to go through the pain of having to install the EMF
plug-ins (ouch!) just to use Buckminster. I really hope you're not
going on that path because that sounds really terrible. I hope P2
changes things, but installing EMF has been an incredible pain up to
now. Really, that's en emphatic no-no; I'd be really unhappy to see EMF
dependencies pulled in, just to use Buckminster. Actually, I have to
sit down, now. The idea of all that bloat is making my tummy ache.
<br>
<br>
Zest is just a wrapper around draw2D, and that's a totally different
matter.
<br>
<br>
Best regards,
<br>
Dann
<br>
<br>
<br>
<br>
Thomas Hallgren wrote:
<br>
<blockquote type="cite">Hi Dann,
<br>
A Buckminster runtime is one thing, the tools used to maintain it
another. The runtime should be kept mean and lean, that's for sure, and
I think that is what your concern is about?
<br>
<br>
One thing that I've learned about EMF the last couple of weeks is that
the runtime instances that it creates are very optimized and in many
cases far more optimal then the Java classes that people normally
write. Booleans are grouped together as bits in integer values, same
thing with enums. I'm sure there's a lot of other optimizations going
on as well that I haven't found yet. All in all, I'm quite convinced
that using EMF to describe things like our CSPEC, RMAP, etc. will give
us a smaller, less error prone, and more efficient runtime. The actual
models themselves, visualized graphically using the ecore tools diagram
editor, will become valuable contributions to the documentation.
<br>
<br>
Then we have the tools surrounding it all. Editors for the model for
instance. We get them for free with EMF. The generated editor can be
extended and improved a lot of course, but event the bare-bone
generated thing beats the hell out of using a text editor on XML
documents. The generated editors are also very well crafted. Mean and
lean. Easy to extend and modify.
<br>
<br>
IMO EMF will become (and in some respect already is) a very valuable
tool for us. Not sure I see why you'd think otherwise.
<br>
<br>
I have no experience with Zest but from the looks of it, it brings us a
very good dependency visualization and that is something that we have
been longing for for some time now. Installing it will be optional of
course.
<br>
<br>
Regards,
<br>
Thomas Hallgren
<br>
<br>
<br>
Dann Martens wrote:
<br>
<blockquote type="cite">Wait a minute,
<br>
<br>
EMF? Zest, sure, but I would hope we could keep that behemoth out of
there, we're talking a configuration management tool here.
<br>
<br>
Best regards,
<br>
Dann
<br>
<br>
<br>
<br>
Guillaume Chatelet wrote:
<br>
<blockquote type="cite">Wow Johannes ! This looks great : )
<br>
<br>
UI is actually an issue in Buckminster and EMF + Zest will do a good
job here. Very cool : )
<br>
<br>
Best regards,
<br>
Guillaume
<br>
<br>
On Mon, Jun 22, 2009 at 11:25 PM, Johannes Utzig <<a class="moz-txt-link-abbreviated" href="mailto:mail@jutzig.de">mail@jutzig.de</a>
<a class="moz-txt-link-rfc2396E" href="mailto:mail@jutzig.de"><mailto:mail@jutzig.de></a>> wrote:
<br>
<br>
Hi,
<br>
<br>
as discussed in
<br>
<a class="moz-txt-link-freetext" href=" http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.html"> http://dev.eclipse.org/newslists/news.eclipse.tools.buckmins ter/msg01102.html</a>
<br>
I started working on a zest based component dependency viewer for
<br>
buckminster.
<br>
I just finished an early prototype and thought it's enough to get
<br>
at least an idea and ask you guys what kinds of features you'd like
<br>
to see in it.
<br>
<br>
Currently this is (for sake of simplicity) registered as an editor
<br>
for previously saved .bom files.
<br>
It consists of 3 areas
<br>
<br>
-navigation tree that shows a tree of the component dependencies
<br>
and is used to drill down on the graph. The selection is linked to
<br>
the graph viewer so if you select a component in the tree, only
this
<br>
specific subtree is revealed in the graph.
<br>
<br>
-graph viewer. This is very basic at the moment. It shows the
<br>
dependency graph with some icons depending on the component type
and
<br>
highlights the direct dependencies of the selected component.
<br>
Unresolved nodes are shown in red, a double-click on a node reveals
<br>
the node's cspec and that's about it :)
<br>
<br>
-settings section. This section lets you choose between some
layout
<br>
algorithms and filters (only platform component filter so far).
<br>
Filters are applied to both the navigation tree and the graph
viewer.
<br>
<br>
I came up with the following things that should be added:
<br>
-better highlighting
<br>
-tooltips and properties view that reveal more details of each
component
<br>
-smart highlighting of paths through the graph (shortest path to
<br>
root request for example)
<br>
-regex based filter (black and white list filter)
<br>
-dependency reports generated from a bom with some nice pictures
<br>
-zooming
<br>
-image export
<br>
<br>
Now I'd be very interested to hear what's on your wish-list for
<br>
dependency visualization, so that I can plan on the real
implementation.
<br>
Attached is a screenshot and a bundle.jar including source code.
<br>
Just throw it in your dropins folder to try, but make sure that
zest
<br>
is installed.
<br>
Keep in mind, this is just an early prototype for demonstration and
<br>
my first steps with zest, so the code is super ugly at the
moment...
<br>
<br>
Best regards,
<br>
Johannes
<br>
<br>
_______________________________________________
<br>
buckminster-dev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:buckminster-dev@eclipse.org">buckminster-dev@eclipse.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:buckminster-dev@eclipse.org"><mailto:buckminster-dev@eclipse.org></a>
<br>
<a class="moz-txt-link-freetext" href="https://dev.eclipse.org/mailman/listinfo/buckminster-dev">https://dev.eclipse.org/mailman/listinfo/buckminster-dev</a>
<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
</body>
</html>
--------------030002040002000400070306--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: [buckminster-dev] Dependency Visualization [message #36079 is a reply to message #35943] |
Wed, 24 June 2009 07:43 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Dann,
Comments below.
Dann Martens wrote:
> Here we go again :)
>
> I feel some of the reply you've formulated doesn't address what I've
> tried to convey.
That may well be.
>
> As far as Buckminster is concerned, I have managed to build a complete
> working build system with additional plug-ins without any need of EMF,
> already two years ago.
Cool.
> I see no compelling reason to introduce EMF now, as what I feel is
> needed to further Buckminster is totally unrelated.
Buckminster serves a community so it's useful to get feedback from it.
> I'm interested in having Buckminster stable (which it isn't) and in
> contributing back what I added myself at that point.
Perhaps contributing back will help with stability?
> I really see no reason at all to warrant this diversion.
That's your subjective opinion, but in the end, the people who do the
actual work make the choices, of course taking into account opinions
from the community and the substance behind those opinions.
> This has nothing to do with the qualities of EMF itself, but I will
> not support this decision.
You've described installing EMF as a nightmare, EMF has a bloated
behemoth, and its use as an unwarranted diversion. You've complained
dramatically about a tummy ache and your need to sit down. Yet still
you claim to have made no value judgment of EMF.
>
> We can argue and misunderstand each other as much as you want,
So not only am I being perhaps dishonest, misunderstandings are
something I desire...
> but this feels like a real waste of my time.
Helping Buckminster get value from EMF isn't a waste of my time, and
working with the community, even when it's occasionally hostile, isn't
either.
> And I'm sure yours as well.
It's my time to spend and for me to decide how best to spend it.
> For a silly build tool, no less.
As far as I'm concerned, the biggest problem with builds is the attitude
that they're silly and working on them is beneath real developers. If
you ask almost any developer at Eclipse, they'll explain that builds are
the bane of their existence, that they happily delegate it all to
someone else. But there's nothing silly about builds. In fact, we
ought to treated the problem as the most fundamentally important problem
to solve when it comes to ensuring that the goodness we develop ends up
coming out of the pipeline and feeding to those who consume it. I'll
climb down off my build soap box now. :-P
I'm thinking the only real substance in your stated concerns is
installation problems, yet what you describe isn't something familiar to
me. I'm wondering why components like GEF, which are also widely used
in other Eclipse projects, don't cause the same installations nightmares
that EMF does. I.e., what's fundamentally different about dependencies
on GEF verses dependencies on EMF? Neither are in the platform and both
need additional installation...
>
> Best regards,
> Dann
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: [buckminster-dev] Dependency Visualization [message #36113 is a reply to message #35943] |
Wed, 24 June 2009 09:35 |
Achim Demelt Messages: 160 Registered: July 2009 |
Senior Member |
|
|
Dann,
I'm not sure that what I'm going to write will change your mind, but I'll
try anyway.
I am using both EMF and Buckminster very intensively. I have built products
based on EMF. Built, of course, with Buckminster. I can run EMF-based code
generators during my automated build with Buckminster. Yes, EMF is already
running in my headless Buckminster. So I guess I know what I'm talking
about.
EMF will not introduce any significant overhead to a typical Buckminster
installation. The runtime JARs are _really_ small. And there's only few of
them. At runtime, I'd argue that it may even _decrease_ Buckminster's memory
footprint.
Installation-wise, I predict that people will see less of these "cannot
install XY" problems with Eclipse 3.5. That's for two reasons: One, p2 has
matured a lot in 3.5. Two, people (i.e. plug-in providers) have learned how
to specify their dependencies correctly. They used to be sloppy with this,
and while the old update manager accepted a lot of crap, p2 threw their
failures into the faces of their users. I learned this, I'm sure others
have, too.
I won't reiterate all the benefits that EMF will bring. But I hope that I
could mitigate some of your fears.
Regards,
Achim
Dann Martens wrote:
> Here we go again :)
>
> I feel some of the reply you've formulated doesn't address what I've
> tried to convey.
>
> As far as Buckminster is concerned, I have managed to build a complete
> working build system with additional plug-ins without any need of EMF,
> already two years ago. I see no compelling reason to introduce EMF now,
> as what I feel is needed to further Buckminster is totally unrelated.
> I'm interested in having Buckminster stable (which it isn't) and in
> contributing back what I added myself at that point. I really see no
> reason at all to warrant this diversion. This has nothing to do with the
> qualities of EMF itself, but I will not support this decision.
>
> We can argue and misunderstand each other as much as you want, but this
> feels like a real waste of my time. And I'm sure yours as well. For a
> silly build tool, no less.
>
> Best regards,
> Dann
|
|
|
Re: [buckminster-dev] Dependency Visualization [message #36147 is a reply to message #36113] |
Wed, 24 June 2009 19:50 |
Dann Martens Messages: 65 Registered: July 2009 |
Member |
|
|
Hi Achim,
This discussion is not simple and potentially endless, and that's why I
refuse to engage in it anymore.
I'm currently working on two other Eclipse-based projects and I need to
focus. If the need arises to use EMF in those projects, I won't
hesitate, I can assure you.
I was in need of a build system badly, and I'll continue my pursuit,
although not necessarily along this track.
Thanks,
Dann
Achim Demelt wrote:
> Dann,
>
> I'm not sure that what I'm going to write will change your mind, but I'll
> try anyway.
>
> I am using both EMF and Buckminster very intensively. I have built products
> based on EMF. Built, of course, with Buckminster. I can run EMF-based code
> generators during my automated build with Buckminster. Yes, EMF is already
> running in my headless Buckminster. So I guess I know what I'm talking
> about.
>
> EMF will not introduce any significant overhead to a typical Buckminster
> installation. The runtime JARs are _really_ small. And there's only few of
> them. At runtime, I'd argue that it may even _decrease_ Buckminster's memory
> footprint.
>
> Installation-wise, I predict that people will see less of these "cannot
> install XY" problems with Eclipse 3.5. That's for two reasons: One, p2 has
> matured a lot in 3.5. Two, people (i.e. plug-in providers) have learned how
> to specify their dependencies correctly. They used to be sloppy with this,
> and while the old update manager accepted a lot of crap, p2 threw their
> failures into the faces of their users. I learned this, I'm sure others
> have, too.
>
> I won't reiterate all the benefits that EMF will bring. But I hope that I
> could mitigate some of your fears.
>
> Regards,
> Achim
>
>
> Dann Martens wrote:
>
>> Here we go again :)
>>
>> I feel some of the reply you've formulated doesn't address what I've
>> tried to convey.
>>
>> As far as Buckminster is concerned, I have managed to build a complete
>> working build system with additional plug-ins without any need of EMF,
>> already two years ago. I see no compelling reason to introduce EMF now,
>> as what I feel is needed to further Buckminster is totally unrelated.
>> I'm interested in having Buckminster stable (which it isn't) and in
>> contributing back what I added myself at that point. I really see no
>> reason at all to warrant this diversion. This has nothing to do with the
>> qualities of EMF itself, but I will not support this decision.
>>
>> We can argue and misunderstand each other as much as you want, but this
>> feels like a real waste of my time. And I'm sure yours as well. For a
>> silly build tool, no less.
>>
>> Best regards,
>> Dann
>
>
|
|
| |
Re: Dependency Visualization [message #37125 is a reply to message #37018] |
Thu, 02 July 2009 14:46 |
|
This is a multi-part message in MIME format.
--------------060709070901000202000109
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Johannes,
I tried this and I'm amazed. It looks great and I don't think it needs further improvement at this
stage. It's very useful as it is and I'd like to include it in Buckminster. In order to do that,
you'd have to submit the code in a bugzilla so that we can get the IP approval process going (a
contribution of this size must be scrutinized by the Eclipse EMO). A bugzilla with a proper patch
will also give people a chance to voice their opinion about the patch.
Some things to think about before you submit the code:
1. You need to add an 'about.html' file stating that the code is EPL 1.0 to the plug-in (see
attachement).
2. The 'about.html' must be included in the binary build of the bundle, i.e. checked on the manifest
editor 'Build' tab.
3. You probably want to add a copyright notice to the head of each source file.
How do we package this in Buckminster? Should we add a special 'Dependency Visualization' feature or
should we simply include it in the core UI distribution? Opinions welcome.
Kind Regards,
Thomas Hallgren
Johannes Utzig wrote:
> Hi,
>
> I had some time since the last post to work an the visualization and
> these are the latest changes:
>
> -better path highlighting. so far 3 kinds of relationships are
> implemented for highlighting:
> -path to direct dependencies of the selected component
> -path to components that directly require the selected component
> -path to root request. (either shortest, or all)
> each way of highlighting can be selectively enabled/disabled and is
> additive to the other selected highlightings
>
> -tooltips on components to reveal some details
> -sash form between navigation tree and graph viewer
> -better resize behavior
> -bugfixes
> -tidier code base and architecture
>
> Unfortunately something seems to be broken in the Zest zooming support,
> so that feature didn't make it into the visualization just yet and it's
> still just registered as a bom editor because I couldn't think of other
> useful integration points.
>
> Apart from that it I think it's pretty usable already and I'm curious
> what you want me to add/change/do before you'd consider to accept it as
> a contribution.
>
> Attached are some updated screenshots to get an impression as well as
> the exported bundle including source code.
>
> Remarks for the screenshots:
> light green = root component (either cquery root, or drilled down)
> green = path to root component
> orange = direct dependencies
> blue = components that directly depend on the selected component
> yellow = current selection
>
> Best regards,
> Johannes
>
>
>
>
> ------------------------------------------------------------ ------------
>
>
> ------------------------------------------------------------ ------------
>
>
> ------------------------------------------------------------ ------------
>
--------------060709070901000202000109
Content-Type: text/html; charset=ISO-8859-1;
name="about.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="about.html"
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>About</title>
</head>
<body lang="EN-US">
<h2>About This Content</h2>
<p>June 24, 2009</p>
<h3>License</h3>
<p>The Eclipse Foundation makes available all content in this plug-in ("Content"). Unless otherwise
indicated below, the Content is provided to you under the terms and conditions of the
Eclipse Public License Version 1.0 ("EPL"). A copy of the EPL is available
at <a href="http://www.eclipse.org/legal/epl-v10.html">http://www.eclipse.org/legal/epl-v10.html</a>.
For purposes of the EPL, "Program" will mean the Content.</p>
<p>If you did not receive this Content directly from the Eclipse Foundation, the Content is
being redistributed by another party ("Redistributor") and different terms and conditions may
apply to your use of any object code in the Content. Check the Redistributor's license that was
provided with the Content. If no such license exists, contact the Redistributor. Unless otherwise
indicated below, the terms and conditions of the EPL still apply to any source code in the Content
and such source code may be obtained at <a href="/">http://www.eclipse.org</a>.</p>
</body>
</html>
--------------060709070901000202000109--
|
|
| |
Re: Dependency Visualization [message #37192 is a reply to message #37125] |
Thu, 02 July 2009 16:42 |
Johannes Utzig Messages: 329 Registered: July 2009 |
Senior Member |
|
|
Hi Thomas, hi Henrik,
comments inline.
Thomas Hallgren schrieb:
> Johannes,
> I tried this and I'm amazed. It looks great and I don't think it needs
> further improvement at this stage. It's very useful as it is and I'd
> like to include it in Buckminster. In order to do that, you'd have to
> submit the code in a bugzilla so that we can get the IP approval process
> going (a contribution of this size must be scrutinized by the Eclipse
> EMO). A bugzilla with a proper patch will also give people a chance to
> voice their opinion about the patch.
>
I'm glad that you want to include it, that's great. One dumb question
about that: by 'patch' you mean just a copy of the source, right? Or how
would I create a patch against a repository where the plugin is not yet
checked in?
> Some things to think about before you submit the code:
>
> 1. You need to add an 'about.html' file stating that the code is EPL 1.0
> to the plug-in (see attachement).
> 2. The 'about.html' must be included in the binary build of the bundle,
> i.e. checked on the manifest editor 'Build' tab.
> 3. You probably want to add a copyright notice to the head of each
> source file.
>
That's easy enough to do, but before that I should probably put
everything in a shape that's acceptable for the buckminster team and the
foundation, because once it's commited it would be a lot harder to do
stuff like string externalization, api-doc,... because I'd need to
provide all that as separate patches, right?
Where can I look-up the things like coding guidelines, naming
conventions, icon conventions,...?
There's also a really dirty implementation hack that I'd rather not see
in a released version, unfortunately I couldn't find another way. I
wanted to open the selected component's cspec on double click, but it
turned out that you don't export the package that contains the
CSpecEditorInput. I worked my way around by subclassing
ViewChosenCSpecAction and invoke its run method, but that's really nasty...
Would there be another way to open a cspec, or should it stay like that?
> How do we package this in Buckminster? Should we add a special
> 'Dependency Visualization' feature or should we simply include it in the
> core UI distribution? Opinions welcome.
>
> Kind Regards,
> Thomas Hallgren
>
>
Either way sounds fine to me, but I should point out that I'm pretty
much the only person that tested this plugin so far. Bundeling it with
the core UI feature could give users the impression that it's a well
tested and mature feature, but maybe that's just me.
Henrik Lindberg schrieb:
> I would put it in the buckminster UI unless it is (unexpectantly)
> a) huge or b) there are issues with required bundles.
>
> - henrik
It's definetly not huge and here's a list of the dependencies:
org.eclipse.core.runtime,
org.eclipse.zest.core;bundle-version="1.1.0",
org.eclipse.zest.layouts;bundle-version="1.1.0",
org.eclipse.buckminster.ui;bundle-version="1.0.350",
org.eclipse.core.resources;bundle-version="3.5.0",
org.eclipse.ui;bundle-version="3.5.0",
org.eclipse.ui.forms;bundle-version="3.4.0",
org.eclipse.ui.ide;bundle-version="3.5.0",
org.eclipse.buckminster.core;bundle-version="1.1.350",
org.eclipse.buckminster.sax;bundle-version="1.0.0",
org.eclipse.equinox.p2.core;bundle-version="1.0.100"
Until I hear more from you I'll add some java-doc, comments, do some
code formatting, see if I can paint some better icons (I suck at that
:)), externalize the strings, add the copyright statement and the licence.
Thank you very much for your help and best regards,
Johannes
|
|
|
Re: Dependency Visualization [message #37226 is a reply to message #37192] |
Thu, 02 July 2009 18:23 |
|
Hi Johannes,
Johannes Utzig wrote:
>... by 'patch' you mean just a copy of the source, right? Or how
> would I create a patch against a repository where the plugin is not yet
> checked in?
It's OK to attach a zip containing the project as a whole.
>> Some things to think about before you submit the code:
>>
>> 1. You need to add an 'about.html' file stating that the code is EPL
>> 1.0 to the plug-in (see attachement).
>> 2. The 'about.html' must be included in the binary build of the
>> bundle, i.e. checked on the manifest editor 'Build' tab.
>> 3. You probably want to add a copyright notice to the head of each
>> source file.
>>
> That's easy enough to do, but before that I should probably put
> everything in a shape that's acceptable for the buckminster team and the
> foundation, because once it's commited it would be a lot harder to do
> stuff like string externalization, api-doc,... because I'd need to
> provide all that as separate patches, right?
> Where can I look-up the things like coding guidelines, naming
> conventions, icon conventions,...?
>
Actually, what I'm after is things that might be significant in your initial contribution. The EPL
affinity is such a thing and if you want to retain your own copyright, you need to do that too
before your initial submission.
The code will be reformatted according to the Buckminster Formatting rules and the project will have
preferences set that will enforce this before it's checked in.
> There's also a really dirty implementation hack that I'd rather not see
> in a released version, unfortunately I couldn't find another way. I
> wanted to open the selected component's cspec on double click, but it
> turned out that you don't export the package that contains the
> CSpecEditorInput. I worked my way around by subclassing
> ViewChosenCSpecAction and invoke its run method, but that's really nasty...
> Would there be another way to open a cspec, or should it stay like that?
>
Let it remain like that for now. This can be refactored once the patch is in.
> Either way sounds fine to me, but I should point out that I'm pretty
> much the only person that tested this plugin so far. Bundeling it with
> the core UI feature could give users the impression that it's a well
> tested and mature feature, but maybe that's just me.
>
Of course it must be tested before we decide to release it but one important aspect of testing is to
let the community at large get their hands on it and start hammering. Since this is a viewer, the
bugs found in it will not be disruptive, so I'd rather see that happen sooner rather then later.
> It's definetly not huge and here's a list of the dependencies:
>
> org.eclipse.core.runtime,
> org.eclipse.zest.core;bundle-version="1.1.0",
> org.eclipse.zest.layouts;bundle-version="1.1.0",
> org.eclipse.buckminster.ui;bundle-version="1.0.350",
> org.eclipse.core.resources;bundle-version="3.5.0",
> org.eclipse.ui;bundle-version="3.5.0",
> org.eclipse.ui.forms;bundle-version="3.4.0",
> org.eclipse.ui.ide;bundle-version="3.5.0",
> org.eclipse.buckminster.core;bundle-version="1.1.350",
> org.eclipse.buckminster.sax;bundle-version="1.0.0",
> org.eclipse.equinox.p2.core;bundle-version="1.0.100"
>
Right. The only added dependencies here are the two zest bundles. The rest is already required from
our own UI bundle.
Regards,
Thomas Hallgren
|
|
| |
Re: [buckminster-dev] Re: Dependency Visualization [message #37296 is a reply to message #37158] |
Thu, 02 July 2009 21:22 |
Guillaume Chatelet Messages: 146 Registered: July 2009 |
Senior Member |
|
|
--0016365ee96ea01cac046dbfa397
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Totally agree with you Henrik. Let's put it in the UI Bundle.
It's just 2 more dependencies to zest : quite alright.
Guillaume
On Thu, Jul 2, 2009 at 5:00 PM, Henrik Lindberg <
henrik.lindberg@cloudsmith.com> wrote:
> Thomas Hallgren wrote:
>
>> Johannes,
>> I tried this and I'm amazed.
>>
> I have not tried it, but the screnshoots look really good.
>
> How do we package this in Buckminster? Should we add a special 'Dependency
>> Visualization' feature or should we simply include it in the core UI
>> distribution? Opinions welcome.
>>
>> I would put it in the buckminster UI unless it is (unexpectantly)
> a) huge or b) there are issues with required bundles.
>
> - henrik
>
> _______________________________________________
> buckminster-dev mailing list
> buckminster-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/buckminster-dev
>
--0016365ee96ea01cac046dbfa397
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Totally agree with you Henrik. Let's put it in the UI Bundle.<br>It'=
;s just 2 more dependencies to zest : quite alright.<br><br>Guillaume<br><b=
r><div class=3D"gmail_quote">On Thu, Jul 2, 2009 at 5:00 PM, Henrik Lindber=
g <span dir=3D"ltr"><<a href=3D"mailto:henrik.lindberg@cloudsmith.com">h=
enrik.lindberg@cloudsmith.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class=3D"im"=
>Thomas Hallgren wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Johannes,<br>
I tried this and I'm amazed. <br>
</blockquote></div>
I have not tried it, but the screnshoots look really good.<div class=3D"im"=
><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
How do we package this in Buckminster? Should we add a special 'Depende=
ncy Visualization' feature or should we simply include it in the core U=
I distribution? Opinions welcome.<br>
<br>
</blockquote></div>
I would put it in the buckminster UI unless it is (unexpectantly)<br>
a) huge or b) there are issues with required bundles.<br><font color=3D"#88=
8888">
<br>
- henrik</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
buckminster-dev mailing list<br>
<a href=3D"mailto:buckminster-dev@eclipse.org" target=3D"_blank">buckminste=
r-dev@eclipse.org</a><br>
<a href=3D"https://dev.eclipse.org/mailman/listinfo/buckminster-dev" target=
=3D"_blank">https://dev.eclipse.org/mailman/listinfo/buckminster-dev</a><br=
>
</div></div></blockquote></div><br>
--0016365ee96ea01cac046dbfa397--
|
|
| |
Re: [buckminster-dev] Re: Dependency Visualization [message #37363 is a reply to message #37296] |
Thu, 02 July 2009 22:42 |
Guillaume Chatelet Messages: 146 Registered: July 2009 |
Senior Member |
|
|
--0016365ee96ed4ce9b046dc0c0e6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
On Fri, Jul 3, 2009 at 12:17 AM, Thomas Hallgren <thomas@tada.se> wrote:
> Guillaume Chatelet wrote:
>
>> Totally agree with you Henrik. Let's put it in the UI Bundle.
>>
>
> I'd rather have it in a bundle of it's own but included in the core UI
> feature. Perhaps that's what you meant?
Definitely Thomas. That's what I meant, sorry for the confusion.
Cheers,
Guillaume
--0016365ee96ed4ce9b046dc0c0e6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Fri, Jul 3, 2009 at 12:17 AM, Thomas Hallgren=
<span dir=3D"ltr"><<a href=3D"mailto:thomas@tada.se">thomas@tada.se</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"border-lef=
t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1=
ex;">
<div class=3D"im">Guillaume Chatelet wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Totally agree with you Henrik. Let's put it in the UI Bundle.<br>
</blockquote>
<br></div>
I'd rather have it in a bundle of it's own but included in the core=
UI feature. Perhaps that's what you meant?</blockquote><div><br>Defini=
tely Thomas. That's what I meant, sorry for the confusion.<br><br>
Cheers,<br>Guillaume<br></div></div>
--0016365ee96ed4ce9b046dc0c0e6--
|
|
| |
Re: Dependency Visualization [message #37537 is a reply to message #37226] |
Mon, 06 July 2009 19:34 |
Johannes Utzig Messages: 329 Registered: July 2009 |
Senior Member |
|
|
Hi Thomas,
I'm done now with the code clean up and submitted it as a bugzilla
attachment:
See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=282569
Best regards,
Johannes
Thomas Hallgren schrieb:
> Hi Johannes,
>
> Johannes Utzig wrote:
>> ... by 'patch' you mean just a copy of the source, right? Or how would
>> I create a patch against a repository where the plugin is not yet
>> checked in?
>
> It's OK to attach a zip containing the project as a whole.
>
>>> Some things to think about before you submit the code:
>>>
>>> 1. You need to add an 'about.html' file stating that the code is EPL
>>> 1.0 to the plug-in (see attachement).
>>> 2. The 'about.html' must be included in the binary build of the
>>> bundle, i.e. checked on the manifest editor 'Build' tab.
>>> 3. You probably want to add a copyright notice to the head of each
>>> source file.
>>>
>> That's easy enough to do, but before that I should probably put
>> everything in a shape that's acceptable for the buckminster team and
>> the foundation, because once it's commited it would be a lot harder to
>> do stuff like string externalization, api-doc,... because I'd need to
>> provide all that as separate patches, right?
>> Where can I look-up the things like coding guidelines, naming
>> conventions, icon conventions,...?
>>
> Actually, what I'm after is things that might be significant in your
> initial contribution. The EPL affinity is such a thing and if you want
> to retain your own copyright, you need to do that too before your
> initial submission.
>
> The code will be reformatted according to the Buckminster Formatting
> rules and the project will have preferences set that will enforce this
> before it's checked in.
>
>> There's also a really dirty implementation hack that I'd rather not
>> see in a released version, unfortunately I couldn't find another way.
>> I wanted to open the selected component's cspec on double click, but
>> it turned out that you don't export the package that contains the
>> CSpecEditorInput. I worked my way around by subclassing
>> ViewChosenCSpecAction and invoke its run method, but that's really
>> nasty...
>> Would there be another way to open a cspec, or should it stay like that?
>>
> Let it remain like that for now. This can be refactored once the patch
> is in.
>
>> Either way sounds fine to me, but I should point out that I'm pretty
>> much the only person that tested this plugin so far. Bundeling it with
>> the core UI feature could give users the impression that it's a well
>> tested and mature feature, but maybe that's just me.
>>
> Of course it must be tested before we decide to release it but one
> important aspect of testing is to let the community at large get their
> hands on it and start hammering. Since this is a viewer, the bugs found
> in it will not be disruptive, so I'd rather see that happen sooner
> rather then later.
>
>> It's definetly not huge and here's a list of the dependencies:
>>
>> org.eclipse.core.runtime,
>> org.eclipse.zest.core;bundle-version="1.1.0",
>> org.eclipse.zest.layouts;bundle-version="1.1.0",
>> org.eclipse.buckminster.ui;bundle-version="1.0.350",
>> org.eclipse.core.resources;bundle-version="3.5.0",
>> org.eclipse.ui;bundle-version="3.5.0",
>> org.eclipse.ui.forms;bundle-version="3.4.0",
>> org.eclipse.ui.ide;bundle-version="3.5.0",
>> org.eclipse.buckminster.core;bundle-version="1.1.350",
>> org.eclipse.buckminster.sax;bundle-version="1.0.0",
>> org.eclipse.equinox.p2.core;bundle-version="1.0.100"
>>
> Right. The only added dependencies here are the two zest bundles. The
> rest is already required from our own UI bundle.
>
> Regards,
> Thomas Hallgren
|
|
|
Goto Forum:
Current Time: Fri Sep 20 17:43:09 GMT 2024
Powered by FUDForum. Page generated in 0.05859 seconds
|