Oomph Repository Analyzer
- 1 Description
- 2 Page Types
- 3 Update Site Pages
- 4 Installable Unit Pages
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.
These are shown only for composite sites. 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 must use. So a user with problems accessing Eclipse via http-scheme will not be able to load this composite via http-scheme because the composite specifies they must use https-scheme.. 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; 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.
Certificates for Signed Content
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 list:
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 every project's 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 whether a product's native executables are properly signed. Currently the report only lists the products.
The report will include a summary of all the categories. These are of course the categories presented to the users when they install features.
The report will include details about each installable unit. If there are units with artifacts with unsigned content or with missing pack200 artifacts, these will be diagnosed:
If there are such problems, filters are available to show only the installable units with those problems. Details for each unit include the size of the associated artifact(s).
Installable Unit Filters
To make it easier to get a "project specific" overview, the installable units section supports pattern-based filtering along with more problem specific filters choices:
The Filter Pattern supports regular expressions and functions well in combination with the radio-button filters. Here we look only at Sirius installable units and have filtered it to the the one(s) with broken branding images, i.e., where the branding plugin specifies an image but the image is not present in the artifact, likely not specified in the build.properties to be included in the binary bundle.
Installable Unit Pages
Every installable unit displayed on the any of the Update Site pages is a link to an Installable Unit page.
The summary title includes the name, the ID, the version, when this unit's repository was built, and which repository contains this unit.
Sections for the provider, the description, the certificates used for signing, and the associated artifacts are also provided. The artifacts details are links to the actual artifacts such that you can down them.
Finally the full content metadata is displayed, including support for expand all.
Installable Unit Content Metadata
In general, p2 knows only about installable units. Bundles/plug-ins, features, products, and even categories are all represented as installable units. All the relationships between these high level concepts, and details about these are captured in the XML. The most interesting of these are the provided and the required elements. In the end, p2 resolution involves hooking up these two relations, i.e., at the root one has installable units that are required and every transitive requirement then resolves to a provided capability of some installable unit. The repository analyzer does a full analysis to determine all the provided capabilities that satisfy any given requirement, and it maintains the inverse of this relationship. These are then injected as navigable links in the XML, again with the little orange triangles that can be used to expand those relationships and then navigate them. So given any installable unit, you can determine all the other units that require it and all the units that it requires.
Installable Unit Provided Capabilities
So for this unit we can see which features require it, which other bundles require it, and we can see that no bundle imports its exported packages.
Installable Unit Requirements
For same unit as the previous section, we can see that its requirements are minimal and which capabilities satisfy those requirements:
As mentioned, each of these details links to another (or even the same) Installable Unit page. Moreover the link is anchored to the capability or requirement at the other the of the relationship; this is highlighted in the target page. I.e., navigating the first link in the above screen capture will navigate to a page that looks like this: