Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #222480 +++ Build ID: eclipse-SDK-3.4RC3 (I20080523-0100) With a fresh installed eclipse SDK, perform Help > About > Feature Details. All the Source Features ("org.eclipse.cvs.source" for instance) are missing. I checked around my old installations, and it seems to be a regression between Eclipse-3.4m4 (which did show the source features), and Eclipse-3.4m6a (which did not show them any more). I don't quite understand under what circumstances the included features are missing. Having CDT-5.0-RC2 SDK installed into an Extension Location by means of the "Classic Update" Capability, for instance, I do see "cdt.platform.source" which is included in org.eclipse.cdt.sdk; I dont see "cdt.platform" which isn't anywhere included but is required. I find that behavior not only confusing to the user because I don't really understand any more what features in what dependencies I have installed; given that also P2 Installer only shows the "Root" features that I had selected, but not the "included/required" features, I have no good handle anymore what I have installed when the About Dialog also doesn't show me that information. What I find even more problematic, is that I have absolutely no way to look at the License of the invisible features from the UI any more (I can look at the plugin licenses by pressing the "Plug-in Details" button from the main About Dialog). Maybe the issue is somehow to existence Branding plugins, since my own Target Management / RSE features all show up and I know that I have specified branding plugins for all of them. The "org.eclipse.cdt.platform" plugin which is missing does not have a branding plugin explicitly specified, and CDT does also not come with a plugin by the same name. For the "org.eclipse.cdt.platform.source" feature which is shown, there does exist a plugin which goes by the same name. It might also be that I'm wrong assuming this is a P2 regression; perhaps it's always been that way that features without associated breanding plugin were not shown, and in Eclipse 3.4m4 the source features did happen to have a "branding" plugin by the same name but that was changed with the new source bundle story? See also bug 163169. Could anybody assess how critical the issue of missing features in about is, from a Licensing / Legal point of view? I'm setting the issue "major" for now.
One odd thing here is that org.eclipse.cdt which is not an included feature in my case, and does not have a branding plugin listed in its plugins (in fact, that feature does not have any plugin on its own, but only included features) - *is* listed in about. So, it's sufficient to have a plugin by the same name (org.eclipse.cdt) even if included in a different feature, in order to make the feature appear in about. Which gives odd user experience in the org.eclipse.cdt case, bacause "List Plugins" for that feature returns an emtpy list. Users asks: "What kind of feature is this, which doesn't have any plugins for its own and seemingly also has no subfeatures"? With Old Classic UM , things were not that bad because there was still the "Manage Updates" dialog whichpresented a tree view of all feature inclusions, even if "About" did not show feature inclusion dependencies.
The absence of source feature in the about dialog is not a consequence of p2, but rather a consequence of the decision to no longer install, in OSGi, the source bundles. Why this decision? Because with the new format for source bundles (one per binary bundle) the system contained twice as many bundle as it used to and consequently got a bit slower to start. The technical problem comes from the fact that update manager is looking for the primary plugin in the set of OSGi bundles and fails to find the source bundles because they are no longer installed. Two things that we still need to verify: - why, in case of a dropins install plug-in, a source bundle is not recognized as such (we may have taken this decision as a backward compatibility story, but I don't recall for sure) - why is the code we changed in UM a month ago or so, did not cover that case?
Hm... I understand your comment about source bundles, but that doesn't explain why I cannot see the following CDT features which are *not* source features and *not* related to source bundles: org.eclipse.cdt.platform org.eclipse.cdt.gnu.build org.eclipse.cdt.gnu.debug These three are automatically installed when I install the "CDT Tooling" feature (org.eclipse.cdt) -- cdt.platform is "required" the two gnu features are "included". But none of these three are shown in the About dialog, leaving only the "org.eclipse.cdt" feature which doesn't have any plugin of its own. This looks like an incomplete fix for bug 222480, or a regression. And, again, I'm quite worried about the Legal implications of no longer being able to see the Licenses for such features from the UI by any means. The Apache License, for instance, *requires* products which use an Apache Library to make the note "This product includes software developed by the Apache Software Foundation" visible from a product's about dialog. Now assume that my feature which is including an Apache Library, and which is correctly set up, is eventually included by somebody else's feature (which I don't know about). And it gets hidden consequently. Now my Apache note is no longer visible in the About Dialog, thus no longer complying with the License. This is a theoretical scenario which I didn't test, but it's scary enough to investigate what's going wrong here. And, what's going wrong here is a regression compared to Eclipse 3.3 for sure.
Adding Bjorn and Janet on CC to notify about potential legal issues with this (See my previous comment #3)
Just to be clear, there are 2 issues here: one concerning source bundles/features and the other with features with branding. As for branding, the fix for bug 222480 included changes to the metadata generator and thus changes to the metadata. Once the update site that you are using is updated with the new metadata, the branding issue should be resolved.
(In reply to comment #5) > Just to be clear, there are 2 issues here: one concerning source > bundles/features and the other with features with branding. Ok > As for branding, the fix for bug 222480 included changes to the metadata > generator and thus changes to the metadata. Once the update site that you are > using is updated with the new metadata, the branding issue should be resolved. Hm... I've been using CDT site which doesn't have artifacts.jar / content.jar but only site.xml -- shouldn't Eclipse 3.4RC3 include the updated metadata generator which generates the stuff correctly on the fly, based on the site.xml ?
I'll look into that now....
For the source legal aspects I think we are fine here for now. Source is NOT installed into the Eclipse configuration you are running so reporting it in the About is not relevant. If the user installs a source feature via p2 then they are prompted with the same licensing workflow as all other p2 installed content. However, looking forward, if the About information is supposed to be "About this profile" (p2 notion of profile) then it would make sense to start talking about all the different things that may have been installed using p2. remember p2 can install WARs, natives, RPMs, ... and even source. This sort of change is not containable in Ganymede (and perhaps not even the maintenance release) as it is quite deep and would require rework in p2, core and UI.
Martin, do you have an example where all those CDT features do appear in the About dialog? I have tried several different variants of installation (p2 and non-p2) and I see the org.eclipse.cdt feature in the list but not the others. The 3 features that are missing from the dialog (org.eclipse.cdt.gnu.build, org.eclipse.cdt.gnu.debug, org.eclipse.cdt.platform) don't have a plug-in with the same ID and don't specify a primary plug-in in their feature manifest. It could be argued that all the features should appear in the dialog (I'd have to look closer at the doc and API), but I don't think this is a regression. For instance, one of the things that I am doing is installing the new CDT version into a non-p2'ized Eclipse (see updated script in bug 224908) and I am seeing the same results... just the one feature in the list. Thanks.
(In reply to comment #9) > Martin, do you have an example where all those CDT features do appear in the > About dialog? Hm... Eclipse 3.3 did show all the features for sure, but that was with CDT 4.0 while now we have 5.0 so I'm not sure if this is a fair comparison in this case. > The 3 features that are missing from the dialog (org.eclipse.cdt.gnu.build, > org.eclipse.cdt.gnu.debug, org.eclipse.cdt.platform) don't have a plug-in with > the same ID and don't specify a primary plug-in in their feature manifest. Correct. > It could be argued that all the features should appear in the dialog (I'd have > to look closer at the doc and API), but I don't think this is a regression. Hm... likely not a P2 regression, but probably an About Dialog regression? I'm not 100% sure whether Eclipse 3.3 did show features without branding plugin in the about dialog or not. Probably it did not and it's all meant to be that way. Perhaps it's time to reassign this to Platform UI. > For instance, one of the things that I am doing is installing the new CDT > version into a non-p2'ized Eclipse (see updated script in bug 224908) and I am > seeing the same results... just the one feature in the list. Right. Either CDT has their features misconfigured, or it's intended to be that way by CDT (unlikely), or it's a bug in Platform UI Aboutdialog. I'll leave it for you though to reassign since you likely better know the right persons to talk to. And, this is independent of the source bundle question which has been answered separately.
My comments in comment #9 triggered a light bulb as to why the source features don't appear in the About dialog. I believe we lost them when we made the move to individual source bundles. The source features no longer have a corresponding bundle with the same id and they don't specify a primary plug-in in their manifest, so they aren't in the dialog.
*** This bug has been marked as a duplicate of bug 220839 ***
