Community
Participate
Working Groups
PDE build now contains facility to export binary plugins (it was actually not too difficult to put together) that are either imported (linked or not) or leave in the target platform. For pde build, a binary plugin is a plugin that does not have a build.properties. The support works pretty well and I'm confident to expose it to the public. Therefore, I would like pde ui to stop protecting its beloved pde build and let the users export binary plugins. Given the ease with which the filtering as been added I guess it can probably be removed easily too :-)
The motivation for pde build to fix the original problem was that nothign prevented users to create/load features that included a binary plugin and it was failing while exporting.
Com'on Wassim don't be shy :-)
Too little too late ;-) Not sure we can sneak this one in for 3.0 at this point. It will have to wait for 3.0.1.
I'm sure Jeff and Kevin will give your their +1. I can probably bride others for extra +1 ;-)
Before you take out your cheque book, I have to give this a +1, and I am not willing to do that at this point in time in the imminent RC4 cycle, unless a better argument is presented. When it comes right down to it, this is really an enhancement for the plugin export experience and not a bug and certainly not an RC4 bug. From a PDE/UI point of view, it is not just a matter of filtering. The whole user experience can be affected. 1. Now that binary plugins would show up in the viewer, potentially a lot more plugins would show up in the wizard viewer, since people who import binary plugins import them en masse. The viewer is already small. So this will result in a lot of vertical scrolling and it will be a major annoyance for the majority of users who don't even care about exporting binary plugins. 2. So to please everybody, PDE/UI would for sure be asked to provide a checkbox that toggles the filtering of binary plugins, so that people who don't care about them don't see them and their user experience would be identical as before. If we do, the counter (x out of x are selected) would have to be affected too. 3. Also now that the number of plugins in the viewer is higher and the nature of the plugins in the viewer is of two types (source vs. binary), we would be expected to provide more buttons like in the import wizard, e.g. "Select Binary", "Invert Selection", etc. As you can see this can open the door to many inconveniences to the already huge audience of the plugin export wizard, and RC4 is not the time to address these cosmetic UI changes.
Seen from this angle, I agree that it is hard to motivate people for 3.0. What I was proposing was simply to revert to the 2.1 mode where binary plugins were shown.
*** Bug 221995 has been marked as a duplicate of this bug. ***
Let's look at this during M7 and see what damage we can cause.
This will have to wait for 3.5
(In reply to comment #0) > PDE build now contains facility to export binary plugins (it was actually not > too difficult to put together) that are either imported (linked or not) or leave > in the target platform. For pde build, a binary plugin is a plugin that does not > have a build.properties. Bug #240821 [1] shows that binary export doesn't fully work. One ends up with the binary plug-in as a nested jar. And I haven't seen anything in the code base that could handle binary export. Thus I suggest to make this bug a dependent of #240821. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=240821
In light of p2, I think this should be solved differently. If the binary bundle being exported is part of an installation, its content should be mirrored during export. However, I don't see this as critical for 3.5.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
