Community
Participate
Working Groups
Build Identifier: Would be far more robust if the Marketplace server would automatically build the Feature ID. Very fragile to have to hand edit the ID each time any change is made to the plugin version. An alternative would be to support wildcards in the Feature ID for at least the qualifier and minor version number. Reproducible: Always
Can you expand on what you mean by "the Marketplace server would automatically build the Feature ID"? There are a few reasons why we didn't take an automated approach with the initial implementation but I'd like to get a better idea of what you mean before commenting on it
(In reply to comment #1) > Can you expand on what you mean by "the Marketplace server would automatically > build the Feature ID"? Sure. Since the Marketplace server has (must be given) the update site URL, it could fetch the feature jars, extract what it needs from the feature.xml feature tag(s) and automatically build conformant FeatureID(s). Trigger this from a button on the Marketplace server UI in place of the manual entry of the FeatureIDs. Where more than one FeatureID is generated, or maybe always, present as a UI list for user selection. Absent this enhancement, you will eventually need to implement a FeatureID verification process to preclude errors due to the manual construction of FeatureIDs. Might as well implement as a UI-helper rather than just as a post-entry error check. Thanks for considering.
Personally I'd love to implement something like this. However currently there are technical limitations (our web servers are not allowed to initiate connections to the World Wide Web). At this point i think the closest thing i could do would be to have owners upload feature.xml files through a form and analyze them that way. I'll set at tentative target date of SR1 (September)
(In reply to comment #3) > I'll set at tentative target date of SR1 (September) Certainly appreciated. But... But a manual process of unjaring and uploading the features.xml is almost as painful. Maybe the real question is why does the Marketplace server need the featureID. Or more specifically, why does the featureID have to be so precise. It really needs to be no more than a hint as to the feature identity. (Comment #0) > An alternative would be to support wildcards in the Feature ID > for at least the qualifier and minor version number. The MPC has no limitation on accessing the update site URL, and given a feature name hint, should be able to find and feed the P2 updater with the correct feature to install. In any event, whatever the "fix", the result should be developers having as close to a one-click or one-generic-entry solution as possible. (FWIW, a simple, quick improvement would be to *not* have developers enter the full xml featureID, but rather just the plain feature path and jar name - all of the featureID attributes can be automatically derived directly from that one value.)
I (and I suspect everyone else) cannot access the Marketplace using the MPC due to an error in the featureID of some unidentified plugin. Specifically, when I do a search or click on the Recent or Popular tabs in the MPC, I get a "Problem Occurred" popup with an error "... The element type 'feature' must be terminated by the matching end-tag '</feature>'." So, it would seem that a single hand-entry error has borked the whole site.
The sample featureID at http://marketplace.eclipse.org/feature-how-to does not have a trailing "/", which is apparently essential.
(In reply to comment #4) > But a manual process of unjaring and uploading the features.xml is almost as > painful. Maybe the real question is why does the Marketplace server need the > featureID. Or more specifically, why does the featureID have to be so precise. > It really needs to be no more than a hint as to the feature identity. We use the Feature ID because it is precise. Different listings have different needs in what they want to list. Some providers will want to have everything installed from their update site and others will not. > (FWIW, a simple, quick improvement would be to *not* have developers enter the > full xml featureID, but rather just the plain feature path and jar name - all > of the featureID attributes can be automatically derived directly from that one > value.) For the record I am not a p2 developer or have any idea what the difference between a "full xml featureID", and "plain feature path and jar name" is. Can you give me an example? There is definitely room to improve the mechanism for specifying Features for MPC to consume. With Helios arriving on the 23rd MPC is in a code freeze which is why I set the target date to SR1, but for now we just have to live with the way this is implemented. (In reply to comment #6) > The sample featureID at http://marketplace.eclipse.org/feature-how-to does not > have a trailing "/", which is apparently essential. I think this may be part of the confusion. The only thing you should be entering into the FeatureID field is the id attribute. Not the full XML tag. Good >> "feature.to.install" Bad >> '<feature url="path/to/feature.jar" id="feature.to.install" version="1.x.x.x">'
I've updated http://marketplace.eclipse.org/feature-how-to to be a bit more precise in terms of what to input.
(In reply to comment #7) > > I think this may be part of the confusion. The only thing you should be > entering into the FeatureID field is the id attribute. Not the full XML tag. > > Good >> "feature.to.install" > > Bad >> '<feature url="path/to/feature.jar" id="feature.to.install" > version="1.x.x.x">' The whole of the confusion: strictly following the how-to, I was entering <feature url="www.certiv.net/updates/features/net.certiv.proguarddt.feature_0.8.0.201006142122.jar" id="net.certiv.proguarddt.feature" version="0.8.0.201006142122"> Beyond the wording of the how-to, part of the confusion stems from the fact that the feature tags that I am seeing generated by Eclipse are of the form <feature id="net.certiv.callgraph.feature.source" version="0.9.0.201006152136" label="CallGraph Viewer" provider-name="Certiv Analytics"> No URL attribute. And, "Feature ID" is not the same as "feature id" or, more precisely, "the value of the id attribute of the feature tag found in the feature.xml file". Thanks for the help
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/134.
