Community
Participate
Working Groups
With Eclipse 3.4, when installing a feature, its dependencies are not made visible to the user if the dependencies are on the plug-in level. Example: when installing a feature depending on the "org.eclipse.wst.xml.ui" plug-in, that dependency will be silently installed. The wizard after clicking "Install" in the update dialog will not show that additional plug-ins will be installed. The user has no idea about the amount of code being downloaded, nor can he tell from what other update sites plug-ins will be pulled. Expected: - the wizard's "Install" page shows the dependencies that are being pulled in, and from what repositories (I don't care about the mirror). The page should also note the total download and install size of all the dependencies. If this creates too much clutter on the "Install" page, the plug-in dependency details could be moved to their own page, which could be skipped by selecting "Finish", or the list of installed items could be a tree with "plug-in dependencies" a collapsed top-level item... Alternatively, the update dialog could feature a "Resolve dependencies" button as in Eclipse 3.3, showing the features in the tree that were included to satisfy dependencies. I assume this is not feasible as the new update mechanism seems to satisfy dependencies on the lowest possible (i.e. plug-in) level.
This behaviour was quite deliberate. The idea is that the end user doesn't know or care what bundles are needed. They just want to install "X", and if that requires installing some other pieces, that's an implementation detail of X they don't need to worry about. We do compute the size of the download, including all dependencies, and show this information in the install wizard. If you take the viewpoint of an end user who doesn't even know what a plug-in is, does this make sense to you? Imagine a win32 product listing all of the DLLs that will be installed...
I do see the rationale behind it, however, I believe the comparison to the Windows installer is skewed for the following reasons: 1. many Windows installers *do* provide a details pane reporting what they are going to install or did just install - the user may skip it (which would be okay for Eclipse as well). 2. most Windows installers I encounter install a package I just downloaded or from a installer medium. If they do collect installables from the internet, these typically come from a single source (e.g. the companys server). 3. all Linux updated mechanisms I know of do show me the dependencies they are going to pull: apt, yum, smart, whatever frontend on Gnome... 4. I am not asking for a report on the file level (which could be compared to the 'DLLs', but one on the feature level. If that cannot be provided (since deps are resolved on plug-in level, I would expect to get a list of those. Again, I am fine with hiding the information in order to not overwhelm the user, be it using a collapsible tree item, or an optional wizard page, or a button. BTW: what happens if the additional dependencies are not signed - will I be able to veto, or could I end up with unsigned plug-ins pulled from ... say, Switzerland, or another rogue country...? Without me consenting?
(In reply to comment #2) > BTW: what happens if the additional dependencies are not signed - will I be > able to veto, or could I end up with unsigned plug-ins pulled from ... say, > Switzerland, or another rogue country...? Without me consenting? I guess this is not quite fair - the updater will of course limit its search to the update sites I have configured. So, if I have a company's update site activated, it's probably ok to pull any needed updates from it. But then again: If I understand correctly P2 was created to also smoothly support meta update sites that provide plug-ins from multiple sources, such as a "plug-in central repository". In that case I would definitely want to know: - what's being installed - who's the provider / creator - under what licence - under what copyright - whether signed or not I guess one problem with the plug-in based approach is that copyright and licence information is typically only provided (machine-readable, that is) on feature-level - or I am getting this wrong?
This bug is really a variant of bug 224472 (see bug #224472 comment #19 in particular). I'm leaving this open, though, because of Tom's specific suggestions on organization.
on second thought, I will mark this as a dup and move new suggestions to that bug. *** This bug has been marked as a duplicate of bug 224472 ***
