Community
Participate
Working Groups
Some "advice" may come out of files nested inside a binary bundle. The p2.inf file is one example, another example is reading the plugin.xml (which will be needed for install handlers). For performance reasons, instead of cracking open the jars to read these nested advice files, we should handle this at the same time we already have the jar open when we are reading the manifest. This avoids the performance penalty of reading the jar later to get more advice. Perhaps a general "are any advice providers interested in any files in this jar we just opened?" We can then get an input stream to pass to the advice provider.
I think we should not go too crazy on how much generation we do from binaries, because otherwise we will have even more complaints about how long the startup time is when using the dropins. Also making the dropins be good does not encourage ppl to switch over to do proper install.
Do we already handle the case where the thing dropped in somehow already has metadata that either already exists or is being dropped in at the same time? This would be interesting if, for example, we were going to get people to put metadata in their .zips etc.
We do have this support, however all the bundles need to be in a "runnable" form.
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. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
