Software Repository Reports - 2019-12
The reports are listed in approximate order of priority. Such as, bundles must not have missing legal files, and all
bundles need to be signed (with few exceptions), and all bundles must use 4 part version numbers. The remaining reports
are important, and ideally would be "clean", but normally would not prevent the release, or inclusion in the common
repository. Except where noted, the checks are done directly are jars in the main common repository directories. That
is, it does not check the "trusted repositories" we point to via composite indirection. See the Reports FAQ for more information about
the code that generates the reports.
Remember, these automated reports test a minimal view of the repository. For example, a bundle may have an about.html
file, so is not listed in "missing files" report, but that does not mean the content of the about.html file is correct.
In other words, Committers and Project Leads are still responsible for correctness -- these reports are more focused on
obvious incorrectness, usually things that happen by small oversights, and which are often hard to "spot" until too
late. Note too that many of the "errors" these reports list, can be caught at development time, in Eclipse IDE, by
proper setting of PDE compiler settings.
Also, remember, especially since these reports are "new" in this context, the reports may contain out-right errors
and will certainly need improvement over time. Contributions welcome. Please open a bug in cross-project component if
you see problems or have new contributions.
-
Bundles missing required files
- This report lists bundles and features that are missing important, required files. It looks directly at jars in
the common repository. (Currently, does not check those "trusted repositories" we point to via composite
indirection). Missing legal files are usually considered a "stop ship" issue, since Eclipse is well known for its IP
quality.
-
Unsigned bundles and features
- This report lists bundles and features that are that are not signed. Pretty serious issue, though there are a
few exceptions. (well, only one code exception is known ... see below).
-
Nested packed jars (if any)
- This report lists packed bundles that have nested packed jars, which are undesirable when using Java 7.
-
Jars that fail to verify (if any)
- This report lists jar files (that did not have a corresponding pack.gz file) that fail "jarsigner -verify" in a serious way (more than simply "not signed", but more likely "not valid" or "tampered with". Indicates a project build issue. Re-processing or re-signing jars?
-
Feature versions compared to reference repository
- This report goes through the repo, looking for "groups" (features) and tabulates the comparison to reference repository.
The comparisons to pay most attention to are those that "decrease" from last release, to the current release.
-
Bundle versions compared to reference repository
- Similar to the "Feature versions" report, this report scans the repo, looking for "non-groups" (bundles) and tabulates the comparison to reference repository.
The comparisons to pay most attention to are those that "decrease" from last release, to the current release. Note: this report does not correctly handle cases where
there are more than one version of a bundle in the repo. Sometimes those are not valid to have anyway, but sometimes it is valid, and this report does not
have enough logic to know what to do with those that occur with same ID, but multiple versions. You can usually just ignore those comparisons in this report.
-
Bundles and Features not using 4 part versions
- To have p2 update correctly and OSGi to resolve bundles as expected, it is essential that bundles and features
use the required 4 part versioning rules. Every build.
-
Consistent, current licenses (SUA) in features
- Check to make sure features use the current, correct license. The report also lists features in repository with
no license (SUA) in the content metadata. This report uses the repository's content metadata, instead of the jar
files themselves, in contrast to the "missing files" report, above. Both are important to be correct, as different
parts of Eclipse code use one or the other to present information to the user depending on the task.
-
reports/greedyReport.html Optional Runtime Requirements and Greediness
- NOTE: This "greediness test" has been disabled until memory issues can be fixed/improved.
See bug 424376
This report summarizes the 'required' element in the content.jar/xml file and lists those that appear to be
created with the new p2 publishers and those with old (and, cases where this results in overlap: some greedy, some
not.
-
Use and Distribution of Bundle-RequiredExecutionEnvironment
- Interesting report showing what BREEs are in use, and which bundles are missing it. All bundles with Java code
should have one, but it is not required in resource-only bundles.
-
Jars missing corresponding Pack200 file
- Pack200 compression is important to save bandwidth. This report will never be perfect ... that is, there are
cases where it is known that a jar can not be cleanly compressed with pack200. But nearly all can. So one or two
from a project should be ignored as "OK" ... but a pattern of all jars/bundles from a project not being compressed
indicates the project simply has not implemented that yet in their build or contribution process.
-
Feature names report
- Check this report for features using incorrect names or incorrect localization settings. While we can not
automatically know what the correct name of a bundle is, we can be sure it does not start with '%', and is not
"Feature-Name" or "feature", etc. This test is ran against the content metadata of the repository.
-
Bundle names report
- Check this report for bundles using incorrect names or incorrect localization settings. While we can not
automatically know what the correct name of a bundle is, we can be sure it does not start with '%', and is not
"Bundle-Name" or "plugin-name", etc. This test is ran against the content metadata of the repository.
-
Provider name report
- Check for bundles using incorrect provider names (Bundle-Vendor directive) or incorrect localization settings.
The best form of provider name is "Eclipse <project name>". Some projects have chosen a slightly different
form, and can not automate every name check, but, again, we know it should not start with '%', not be
"provider-name" nor be empty (null). This test is ran against the content metadata of the repository.
-
Feature Copyrights
- List copyrights used by Features.
-
Feature Descriptions
- List descriptions used by Features.
-
List of non-unique versions
- List those bundles (technically, IUs) for which there are multiple versions. It is often quite normal for there
to be multiple versions (e.g. when differ by major or minor versions), but sometimes looking at the multiple version
report can spot unexpected cases where there are multiple versions. Even if so, it will usually not cause problems,
but can at least be inefficient use of space (e.g. if differ only by qualifier).
-
Version Qualifier Patterns
- This is an exploratory report of the the types or patterns of version qualifiers by bundles and features in the
repository. Longer term, this report can be improved to spot typos and also find bundles or features in the
repository that do not use 4 part versioning. (A report, above, also detects lack of 4 part versioning, but is based
on jars, found in common directory, rather than all of content metadata in repository.)
-
Use of Eclipse-SourceReferences
-
List those bundles which are, and which are not, using the Eclipse-SourceReferences
directive and the value of that directive. This directive (and report) is useful for some projects to help their
community find their source code directly from their repository (to help make providing patches easier), but is not
useful or appropriate for all projects. Use the directive, and the report, however your project deems appropriate
and useful.
-
Feature Directory Lengths
- This is an exploratory report of the length of feature directories length, if feature was installed, (not
including the .../eclipse/features part of name). Its purpose it to alert the interested of exceptionally long
feature names, which might cause some issues on some operating systems. This report is exploratory, since it is
unclear what, if any, should be considered the maximum length, which depends on many factors. But ... if you are
creating new features, it'd be best not to exceed the typical sizes.
-
Signing test report (info)
-
Signed bundles exceptions
- Just to document it, there are a few known cases of jars in the repository that are not or should not be
signed.
-
Correctly signed bundles
- Again, just documentation of jars we found correctly signed.