| Dependency Analysis issues [message #663132] |
Sun, 03 April 2011 22:14 |
 Alain Picard
Messages: 266
Registered: July 2009 |
Senior Member |
|
|
I am having a few issues here and I'd like to know how best to proceed.
First, don't think it matters here, but we use Required Plugins for
Eclipse provided functionality and Imported Packages for everything else.
When I use "Find Unused Dependencies" from the Manifest Dependency
Analysis section, it tells me that I have some Unused Dependencies and
if I remove them, I get build errors. The opposite is also the case if I
ask to "add dependencies" from that same set it tells me that no
additional dependencies were found (which we had tried to use a while
back to establish a baseline but got the same type of problems as
described below and we just fixed the errors reported then).
There seems to be a number of situations where the analysis is
incorrect. Here are 2 identified situations causing the issue:
-First downcasting.
I have a package that defines some methods that would return an EList
(from EMF) and my plugin uses it but downcasted to a List as such:
List<Something> = xyz.run(blah);
where run is set to return an EList and not a List.
This gives me that the type EList cannot be resolved and it is
indirectly referenced.
-Second superclass
I have a plugin/package that define a class that is subclassed in a
different plugin/package. That subclass is being used in a 3rd plugin.
This plugin import the package for the subclass that it uses, but I get
an error the the type SuperClass cannot be resolved and it is indirectly
referenced. Here I have no clue how I'm even referencing the super
class, I don't even address superclass field or method that I see.
So, back to the questions.
1. Why isn't this managed with the dependency analysis and if that is a
limitation, how can this dependency analysis be useful in real life cases.
2. I can obviously fix every error until there are none (and that works
btw), but that doesn't seem like a good way to deal with the issue. Are
there some patterns or strategies when building plugins to avoid those
cases?
3. In the first case, I feel that I probably can get around it by
marking the EMF common plugin as re-exported from my first plugin. Here
my question is two-fold, I've read a lot of posts about staying away
from re-exporting and so wonder about how good they are and secondly,
since we mostly use import packages, what is the equivalent and how do
we deal with such issues then?
Thanks,
Alain
|
|
|
Powered by
FUDForum. Page generated in 0.04550 seconds
] 
Search
Help
Register
Login
Home
