Provide a mechanism allowing exclusion of specified API packages, classes, and members (methods, fields, constructors) from signature files.
1. The mechanism should allow SigTest to ignore the specified API parts of signatures during signature test checking.
All specified API parts should be ignored and any error messages related to those API parts will be suppressed.
2. There should be a simple way to exclude mutliple similar API items. For example all classes whose names ends with BeanInfo, or a method inherited by many classes.
Example:
IGNORE org.omg.stub.* 6317640
3. The mechanism should allow SigTest to exclude specified API parts without re-building the JCK product. It should be possible to specify exclusion manually or via some automatic tool (like ELE for jtx files)
4. It should be relatively easy for JCK users to use this feature
5. It should be relatively easy for JCK developers to adapt (acceptable impact on existing tools and processes used by JCK team)
6. This feature should be implemented as an non-public feature; It should not be easily discovered and exploited by ME customers.
7. There should be some form of security imposed on Exclusion Files (and associated/generated) Signature Files such that it is not easy for a casual user to create their own exclusion list (eg. ex 1: Encrypted file, SigTest tool owns private key, ex 2: signed jar -- at this point, we favor using 'signed jars').
1. The mechanism should allow SigTest to ignore the specified API parts of signatures during signature test checking.
All specified API parts should be ignored and any error messages related to those API parts will be suppressed.
2. There should be a simple way to exclude mutliple similar API items. For example all classes whose names ends with BeanInfo, or a method inherited by many classes.
Example:
IGNORE org.omg.stub.* 6317640
3. The mechanism should allow SigTest to exclude specified API parts without re-building the JCK product. It should be possible to specify exclusion manually or via some automatic tool (like ELE for jtx files)
4. It should be relatively easy for JCK users to use this feature
5. It should be relatively easy for JCK developers to adapt (acceptable impact on existing tools and processes used by JCK team)
6. This feature should be implemented as an non-public feature; It should not be easily discovered and exploited by ME customers.
7. There should be some form of security imposed on Exclusion Files (and associated/generated) Signature Files such that it is not easy for a casual user to create their own exclusion list (eg. ex 1: Encrypted file, SigTest tool owns private key, ex 2: signed jar -- at this point, we favor using 'signed jars').
- relates to
-
CODETOOLS-5109689 no way to exclude invalid signatures from checking
-
- Closed
-