Home » Eclipse Projects » Equinox » On dependency management
| On dependency management [message #466] |
Wed, 19 February 2003 21:19  |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
It's hard to manage dependencies without a picture. I've done some
experimental work in displaying the plugin depencies, based only on the
<requires> tags (See picture). As soon as I showed this to someone, they
immediately suggested that the "quality" of the requirement be expressed.
Meaning, show which classes require which other classes from the upstream
plugin. I feel like I'm having a hard time working this. Anyway, it might
be possible to show the resource-to-resource list of requirements (at
development time) by accessing the JDT compiler's dependency maps. Does
this make sense?
|
|
| |
| Re: On dependency management [message #492 is a reply to message #481] |
Thu, 20 February 2003 09:49  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Bob Hays, Computer Geek" <electricbob@telocity.com> wrote in message
news:t8j95v8kcfkqosadjuu6sm07s617jovhah@4ax.com...
> Why not use UML diagrams to show the dependencies? Then you could add
> stereotypes (and possiblty tag/value pairs?) to the connections to
> show qualities.
Along the lines of "Not support work items which have no hope of being
integrated into the Eclipse platform", I was thinking of a simple extension
to the current PDE dependency view (which I remember in 2.0, but can't seem
to find in 2.1). I don't think a full-blown UML editor is on the 2.2 or
even 3.0 plan. Also, *plugin* dependencies are strictly directed and
acyclic, so an automatic layout of the plugins is possible. This means that
such a "tool" could function without any additional information or resources
other that the plugin.XMLs.
>
> Have fun! - Bob
>
> On Wed, 19 Feb 2003 21:19:12 -0500, "Randy Hudson" <none@us.ibm.com>
> wrote:
>
> >It's hard to manage dependencies without a picture. I've done some
> >experimental work in displaying the plugin depencies, based only on the
> ><requires> tags (See picture). As soon as I showed this to someone, they
> >immediately suggested that the "quality" of the requirement be expressed.
> >Meaning, show which classes require which other classes from the upstream
> >plugin. I feel like I'm having a hard time working this. Anyway, it
might
> >be possible to show the resource-to-resource list of requirements (at
> >development time) by accessing the JDT compiler's dependency maps. Does
> >this make sense?
> >
>
|
|
|
| Re: On dependency management [message #1473 is a reply to message #492] |
Fri, 21 February 2003 07:44 |
| Eclipse User |
|
|
|
Originally posted by: electricbob.telocity.com
Okay, then why not use a true acyclic directed graph picture? That
would include arrows to indicate direction and probably names for the
nodes and edges.
BTW, I wasn't suggesting a UML editor - I was suggesting drawing the
picture in UML because that's become the standard language for
software design materials, and this is one of those. Also, only a
very small subset of the language would be needed for this
application....
Thanks and have fun! - Bob
On Thu, 20 Feb 2003 09:49:24 -0500, "Randy Hudson" <none@us.ibm.com>
wrote:
>"Bob Hays, Computer Geek" <electricbob@telocity.com> wrote in message
>news:t8j95v8kcfkqosadjuu6sm07s617jovhah@4ax.com...
>> Why not use UML diagrams to show the dependencies? Then you could add
>> stereotypes (and possiblty tag/value pairs?) to the connections to
>> show qualities.
>
>Along the lines of "Not support work items which have no hope of being
>integrated into the Eclipse platform", I was thinking of a simple extension
>to the current PDE dependency view (which I remember in 2.0, but can't seem
>to find in 2.1). I don't think a full-blown UML editor is on the 2.2 or
>even 3.0 plan. Also, *plugin* dependencies are strictly directed and
>acyclic, so an automatic layout of the plugins is possible. This means that
>such a "tool" could function without any additional information or resources
>other that the plugin.XMLs.
>
>>
>> Have fun! - Bob
>>
>> On Wed, 19 Feb 2003 21:19:12 -0500, "Randy Hudson" <none@us.ibm.com>
>> wrote:
>>
>> >It's hard to manage dependencies without a picture. I've done some
>> >experimental work in displaying the plugin depencies, based only on the
>> ><requires> tags (See picture). As soon as I showed this to someone, they
>> >immediately suggested that the "quality" of the requirement be expressed.
>> >Meaning, show which classes require which other classes from the upstream
>> >plugin. I feel like I'm having a hard time working this. Anyway, it
>might
>> >be possible to show the resource-to-resource list of requirements (at
>> >development time) by accessing the JDT compiler's dependency maps. Does
>> >this make sense?
>> >
>>
>
|
|
| |
| Re: On dependency management [message #1634 is a reply to message #1586] |
Mon, 24 February 2003 13:36 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Hi Erich,
Sounds like good stuff, but I always regret the lack of integration of PDE.
It would be great if the buildpath at the JDT would understand those things
too. I find cumbersome to construct a build path for Java in terms of
projects
and jar files, when I am building dependencies between plug-ins. This is
even
more confusing if you throw fragments, which show up in the buildpath but
not
in the plugin dependencies.
Actually, I will go even further saying that the dependencies should
understand
features. Indeed, I like Jeff's analogy between features and Java profiles.
So when I am developing a plug-in, I would know the features that will be
available
in the target Eclispe, but most likely not the details of their plug-ins...
which by the way
depends on the target OS, WM, and ARCH.
Hence, I believe we should have a notion of a profile or a configuration,
which
ever we want to call it. This profile would mimick the intended deployment
target.
That configuration should server to construct both the plug-in dependencies
and
the buildpath. Not only the buildpath, but also drive which features are
installed
when PDE is launching the target environment.
This is where features, fragments, and plug-ins are not well integrated in
the overall
Eclipse, from development to deployment. Development is too much
project-based
while deployment is solely feature-based. Supporting features as first-class
concept
seems to me the way to simplify all this.
Best regards,
Olivier.
"Erich Gamma" <erich_gamma@oti.com> wrote in message
news:3E590C7D.4090105@oti.com...
> >Meaning, show which classes require which other classes from the
> >upstream plugin.
> This is already supported in PDE since a while.
> In the depency view or the manifest editor's
> Dependency tab you can select a required plugin and
> execute "Compute Dependency Extent". This will show
> you the types required from the pre-req by this plugin.
>
> There is also a "Find Unused Dependencies" action. It will
> report which pre-reqs are potentially not needed. This
> helps you to clean-up and minimize your pre-reqs.
>
> --erich
>
>
|
|
|
Goto Forum:
Current Time: Thu Oct 30 23:45:07 EDT 2025
Powered by FUDForum. Page generated in 0.24727 seconds |
Home