Lines Matching refs:files

9 * Allow extracting the API (into signature text files, into stub API files (which
40     signature files, the SDK stub files, external annotations etc.
72   signature files for the framework as doclava1.
75   we can regenerate signature files etc for older versions according to new formats
80   IntelliJ external annotations data as well as signature files containing
95     comments in the signature files.)
98     files. This is vital now that some of these annotations become part of
104     contract, the signature files would very quickly become bloated with
131     annotations are not included in signature files) use just the simple
150 * Support for generating documentation into the stubs files (so we can run javadoc or
151   [Dokka](https://github.com/Kotlin/dokka) on the stubs files instead of the source
157 * Support for parsing Kotlin files. API files can now be implemented in Kotlin
159   as is done for Java files.
166   require you to create two signature files to diff.
169   the signature files and generated the stubs had diverged, so there was some
170   inconsistency. In metalava the stub files contain **exactly** the same signatures
171   as in the signature files.
178   the exact same API as is listed in the signature files, and once this was
192   (.class or .jar files) and it will then measure the annotation coverage of
263   files needed by Studio and lint in Gradle, which captures the typedefs (@IntDef and
273   incorrect results. Metalava uses the android.jar files themselves to ensure that
287     android.jar files (e.g. backed by bytecode) or reading previous signature
288     files.  Reading in multiple versions of an API lets doclava perform "diffing",
290     generate signature files in the new format (including data that was missing
291     in older signature files, such as annotation methods) without having to
308 on signature files: TextPackageItem, TextClassItem, and so on.
422 files, which can then be processed by Dokka and Javadoc to generate the