Difference between revisions of "Oomph Repository Analyzer"
|Line 106:||Line 106:|
==== Categories ====
==== Categories ====
Revision as of 07:17, 29 August 2019
Oomph's repository analyzer is an application for generating a detailed analysis report of one for more p2 repositories. Oomph's repository-analyzer job illustrates how to use this application to generate reports. It currently generates reports for several of Eclipse's key p2 update sites, including the latest Platform repositories and the latest SimRel repositories. Please use Bug 550361 for feedback.
There are three general page types generated.
- Pages for folders that are not themselves p2 update sites; these are useful only for navigation.
- Pages for folders that represent a p2 update site with two variants:
- Pages for composite update sites.
- Pages for simple update sites.
- Pages for each installable unit in an update site.
Update Site Pages
An update site page looks will appear as follows:
In this case, it is a page for a composite p2 repository, so an "XML" section is included For a simple p2 repository, the detailed information about site's content and artifacts is very large and is therefore provide via separate installable unit-specific pages.
In general, sections are expandable via the orange triangle. Some sections support expand all via a second orange triangle after the section title, which appears only after expanding the section itself.
The report will diagnose the specific problems as documented in this wiki in the sections that follow.
Inappropriate Absolute Locations
If the composite site specifies a location using an absolute URI that has the same host as the composite site itself, this is reported as a problem:
Such a design is problematic because it predetermines the scheme the user will use. So a user with problems accessing Eclipse via https-scheme will not be able to load this composite via http-scheme instead. Also, it will not be possible locally on the build server to access this composite purely using file-scheme.
There are current 3 valid variants of the Eclipse Software User Agreement. All features and products must use one of these three as their license. Non-conformance is diagnosed as a problem. Detailed information is provided each license and for the installable units (features and products) that use each license.
Under the covers, p2 computes a fingerprint for each license. This is displayed in report and this item can be expanded to show the full license text. The license is matched against one of the 3 valid SUAs and the mismatch is highlighted to show what's wrong.
Here we see that some type of encoding problem has occurred, and the to-be-deleted text is shown in bold red and the to-be-added text is show in bold green, in a really big font if the mismatch is small.
All content distributed from Eclipse must be signed by a valid certificate, preferably a recent one. Unsigned content is diagnosed as a problem and the offending installable units are listed:
Certificate details are displayed and each section is expandable to list the installable units that are signed with that certificate. Of course this also provides access to the list of unsigned installable units.
All content distributed by Eclipse is provided by Eclipse. Features specify the name of the provider and the branding guidelines dictate that Eclipse must always be part of the brand. Any feature that is non-conformant will be diagnosed as a problem:
This summary also shows the associated branding image of each feature. A warning icon indicates that no such image could be determined. An error icon indicates that the feature specifies an image, but doesn't actually include the image in the feature's associated artifact.
Generally all features should be brand with an associated provider and a branding image. The report includes a section for these details:
As mentioned previously, a warning icon indicates that no such image could be determined, and an error icon indicates that the feature specifies an image, but doesn't actually include the image in the feature's associated artifact.
Note that the combination of provider name and branding image is what determines the the images and grouping in the About Eclipse dialog.
In the long term, the repository analyzer should determine where a product's native executables are problem signed. Currently the report only lists the products.
The report will include a summary of all the categories. These are of course the categories present to the user when the install features.