Community
Participate
Working Groups
It would be valueable if imported and exported packages that participate in x-friend relationship were decorated in the manifest editor. Today you can only see the packages that are exported to x-friendly bundles, but even so you cannot tell at a glance, but rather you have to select each package and see if it is visible to any x-friends. It is not currently possible to tell that an imported package was made available as a result of being an x-friend of another bundle. Since the "unit of x-friendship" is the package, it is important for a developer to keep track of which packages are exported to an x-friend since all the types in the package are visible to the x-friend. Likewise, it is important for a developer to keep track of which packages are imported via an x-friend relationship, since types obtained in this way are not strictly API and are likely to change.
+1
happy faces for decorations, since friends are happy... however I think Simon would argue for sad faces for people who use x-friends
Happy or sad, just make sure the preference is sticky <g>
Decorating exported packages was done with bug 210183 leaving this open to deal with imported packages
I'll have a look at this bug :)
Created attachment 89562 [details] Work in progress
Created attachment 89563 [details] mylyn/context/zip
Although it's quite straightforward to compute the decorator status "just-in-time" when a package is imported , I don't know what to do when reopening the Manifest : no info is stored in the text file so computing the "friend" status is quite heavy (call to the PluginRegistry to get active models and find if somewhere we are registered as friend...). ATM, I didn't add the "internal" decorator. Should I?
And what decorator must be set when the package is exported by different bundles in the target platform, maybe once as "friend", once as "internal", once as API etc .... ?
Well I think I had a bad idea when I decided to cache the "isImportedAsFriend" flag into the ImportPackageObject. I think it would only be the role of the labelprovider to compute this flag, on the fly, requesting the PluginRegistry. But caching mechanisms and background computations will be necessary because computing this flag is -very- expensive Any suggestions? Ideas?
I think for now, we should hold off on this one as it is making us think about doing expensive calculations within label providers (something we didn't really need to do before). For these types of things, it seems we would have to kick off a job to do the calculation and just refresh the view apprioriately when it's done. There are other approaches, but as I say before, noone has died (maybe Simon) without this functionality yet ;) There's bigger fish to fry at the moment :)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
Please remove the stalebug flag, if this issue is still relevant and can be reproduced on the latest release.
