japitools (0.9.5+cvs20060115-2) debian-dir only changes

Summary

 debian/changelog    |   26 +++++
 debian/compat       |    1 
 debian/control      |   21 ++++
 debian/copyright    |   25 ++++
 debian/dirs         |    2 
 debian/doc-base     |   11 ++
 debian/docs         |    5 
 debian/index.html   |  266 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 debian/japicompat.1 |  104 ++++++++++++++++++++
 debian/japilist.1   |   32 ++++++
 debian/japiohtml.1  |   32 ++++++
 debian/japiotext.1  |   32 ++++++
 debian/japize.1     |   94 ++++++++++++++++++
 debian/manpages     |    5 
 debian/rules        |   22 ++++
 debian/watch        |    2 
 16 files changed, 680 insertions(+)

    
download this patch

Patch contents

--- japitools-0.9.5+cvs20060115.orig/debian/rules
+++ japitools-0.9.5+cvs20060115/debian/rules
@@ -0,0 +1,22 @@
+#!/usr/bin/make -f
+# debian/rules file for japitools (uses cdbs)
+
+include /usr/share/cdbs/1/rules/debhelper.mk
+include /usr/share/cdbs/1/class/ant.mk
+include /usr/share/cdbs/1/rules/simple-patchsys.mk
+
+export UPSTREAM_VERSION = $(shell head -1 debian/changelog | cut -f2 -d\( | cut -f1 -d\) | cut -f1 -d\-)
+
+JAVA_HOME := /usr/lib/jvm/default-java
+
+DEB_JARS := $(ANT_HOME)/lib/ant-launcher.jar
+
+DEB_ANT_BUILD_TARGET := main
+
+install/japitools::
+	install -m 644 share/java/japitools.jar debian/japitools/usr/share/java/japitools.jar
+	install -m755 bin/japicompat debian/japitools/usr/bin/japicompat
+	install -m755 bin/japilist debian/japitools/usr/bin/japilist
+	install -m755 bin/japiohtml debian/japitools/usr/bin/japiohtml
+	install -m755 bin/japiotext debian/japitools/usr/bin/japiotext
+	install -m755 bin/japize debian/japitools/usr/bin/japize
--- japitools-0.9.5+cvs20060115.orig/debian/control
+++ japitools-0.9.5+cvs20060115/debian/control
@@ -0,0 +1,21 @@
+Source: japitools
+Section: devel
+Priority: optional
+Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
+Uploaders: Michael Koch <konqueror@gmx.de>
+Build-Depends: debhelper (>= 7), cdbs, ant, default-jdk
+Standards-Version: 3.8.3
+
+Package: japitools
+Architecture: all
+Depends: default-jdk, ${misc:Depends}, ${perl:Depends}
+Description: Java API compatibility testing tools
+ It consists of two simple tools designed to test for compatibility between
+ Java APIs. They were originally designed for testing free implementations
+ of Java itself for compatibility with Sun's JDK, but they can also be used
+ for testing backward compatibility between versions of any API.
+ .
+ The tools are japize and japicompat. Japize is a Java program which emits 
+ a listing of an API in a machine-readable format. Japicompat then takes two
+ such listings and compares them for binary compatibility, as defined by Sun
+ in the Java Language Specification.
--- japitools-0.9.5+cvs20060115.orig/debian/compat
+++ japitools-0.9.5+cvs20060115/debian/compat
@@ -0,0 +1 @@
+7
--- japitools-0.9.5+cvs20060115.orig/debian/changelog
+++ japitools-0.9.5+cvs20060115/debian/changelog
@@ -0,0 +1,26 @@
+japitools (0.9.5+cvs20060115-2) unstable; urgency=low
+
+  * (Build-)Depends on default-jdk.
+  * Moved Build-Depends-Indep to Build-Depends.
+  * Build-Depend on debhelper >= 7.
+  * Depends on ${misc:Depends}.
+  * Rewrote debian/copyright to be more accurrate.
+  * Use doc-base section 'Programming'.
+  * Removed Wolfgang and added me as uploader.
+  * Updated Standards-Version to 3.8.3.
+
+ -- Michael Koch <konqueror@gmx.de>  Mon, 14 Sep 2009 21:22:39 +0200
+
+japitools (0.9.5+cvs20060115-1) unstable; urgency=low
+
+  * New upstream cvs snapshot
+  * kaffe compiler transition
+
+ -- Wolfgang Baer <WBaer@gmx.de>  Mon, 16 Jan 2006 15:32:32 +0100
+
+japitools (0.9.5+cvs20051006-1) unstable; urgency=low
+
+  * Initial release
+
+ -- Wolfgang Baer <WBaer@gmx.de>  Thu,  6 Oct 2005 15:52:05 +0200
+
--- japitools-0.9.5+cvs20060115.orig/debian/dirs
+++ japitools-0.9.5+cvs20060115/debian/dirs
@@ -0,0 +1,2 @@
+usr/bin
+usr/share/java
--- japitools-0.9.5+cvs20060115.orig/debian/japiohtml.1
+++ japitools-0.9.5+cvs20060115/debian/japiohtml.1
@@ -0,0 +1,32 @@
+.TH JAPIOHTML 1 "October 6, 2005"
+
+.SH NAME
+japiohtml \- Convert japicompat output to pretty html format.
+
+.SH SYNOPSIS
+.B japiohtml
+.I <file>
+
+.SH DESCRIPTION
+.B japiohtml
+is part of japitools, designed to test for compatibility between Java APIs. 
+.br
+It is used to convert the output produced by japicompat to html.
+
+.SH OPTIONS
+.TP
+\fB\fR <file\fR>\fP
+the file produced by japicompat to convert.
+
+.SH SEE ALSO
+.BR japize (1) 
+Produce a listing of an API in a machine-readable format.
+.br
+.BR japicompat (1) 
+Test Java APIs for binary backwards compatibility.
+.br
+.BR japilist (1) 
+List the contents of japi files.
+.br
+.BR japiotext (1) 
+Convert japicompat output to readable plain text format.
--- japitools-0.9.5+cvs20060115.orig/debian/watch
+++ japitools-0.9.5+cvs20060115/debian/watch
@@ -0,0 +1,2 @@
+version=3
+http://sab39.netreach.com/Software/Japitools/Download/43/ .*/japitools-([\d.]+)\.tar\.gz
--- japitools-0.9.5+cvs20060115.orig/debian/docs
+++ japitools-0.9.5+cvs20060115/debian/docs
@@ -0,0 +1,5 @@
+design/genericnotes.txt
+design/japi-spec-0.9.7.txt
+design/japi.css
+web/jcompat.txt
+debian/index.html
--- japitools-0.9.5+cvs20060115.orig/debian/manpages
+++ japitools-0.9.5+cvs20060115/debian/manpages
@@ -0,0 +1,5 @@
+debian/japicompat.1
+debian/japize.1
+debian/japiotext.1
+debian/japiohtml.1
+debian/japilist.1
--- japitools-0.9.5+cvs20060115.orig/debian/index.html
+++ japitools-0.9.5+cvs20060115/debian/index.html
@@ -0,0 +1,266 @@
+<html><head><title>japitools: Java API compatibility testing</title></head>
+<body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#8800ff">
+<h1>japitools: Java API compatibility testing tools</h1>
+<p>japitools consists of two simple tools designed to test for compatibility
+between Java APIs. They were originally designed for testing free
+implementations of Java itself for compatibility with Sun's JDK, but they can
+also be used for testing backward compatibility between versions of any API.</p>
+<p>The tools are <a href="#japize">japize</a>
+and <a href="#japicompat">japicompat</a>. Japize is a Java program which
+emits a listing of an API in a machine-readable
+format. Japicompat then takes two such listings and compares them for binary
+compatibility, as defined by Sun in the
+<a href="http://java.sun.com/docs/books/jls/html/13.doc.html">Java Language Specification</a>
+(and as amended
+<a href="http://java.sun.com/docs/books/jls/clarify.html">here</a>).</p>
+
+<h3>Usage</h3>
+<p>Using japitools is a two-step process:</p>
+<ul><li>Use japize to generate a .japi file for each of the versions you want
+to compare.</li>
+<li>Use japicompat to compare one for backwards compatibility with the
+other</li></ul>
+<h4><a name="japize">japize</a></h4>
+<p>The general usage of japize is as follows:</p>
+<pre>$ japize [unzip] [as &lt;name&gt;] apis &lt;zipfile&gt; | &lt;dir&gt; ... +|-&lt;pkgpath&gt; ...</pre>
+<p>At least one +&lt;pkgpath&gt; is required. &lt;name&gt; will have
+".japi" and/or ".gz" appended as appropriate.</p>
+<p>The word "apis" can be replaced by "explicitly", "byname", "packages" or
+"classes". These options indicate whether something of the form "a.b.C" should
+be treated as a class or a package. You may specify this unambiguously by using
+one of the forms "a.b.cpackage," or "a.b,CClass".</p>
+<p>That's the one-paragraph overview, pretty much equivalent to what you get if
+you type "japize" with no arguments. In detail, the options available are as
+follows:</p>
+<h4>[unzip]</h4>
+<p>Specifying the "unzip" option indicates that japize should not gzip its
+output. Zipping the output is highly
+recommended since it saves huge amounts of space (japi files are
+large but extremely compressable because they contain large numbers of duplicate
+strings. Factor-of-ten compression seems to be typical). The only situations
+where you might not want to use gzip compression are when memory and CPU usage
+are extremely tight (zipping and unzipping both require more memory the larger
+the file gets, and require more CPU usage - on todays computers this is rarely
+an issue, though) or if your JVM does not implement GZIPOutputStream correctly
+(in which case you might still want to gzip the resulting file manually).</p>
+<h4>as &lt;name&gt;</h4>
+<p>Specifying this option tells japize to write its output to a file with the
+specified name. When writing to a file with the "as" option, japize insists on
+writing to a file name ending in .japi.gz for compressed files, or .japi for
+uncompressed files. If the filename you specify doesn't have the right
+extension, japize will add parts to it to ensure that it does.</p>
+<p>If the "as" option is omitted, japize will write to standard output. In this
+case japize has no control over the filename you use, but it is strongly
+recommended to use a filename with the correct extension (".japi.gz" unless the
+"unzip" option was specified). If you use any other extension, japicompat and
+other tools may be unable to recognize the format.</p>
+<h4>apis | explicitly | byname | packages | classes</h4>
+<p>This option has a dual role: it indicates the boundary between japize options
+(unzip, as) and other arguments (files and packages), but also tells
+japize how to deal with ambiguously specified arguments. See
+"+|-&lt;pkgpath&gt;" below for details on the behavior of each option. If you
+are unsure which to specify, "apis" is a safe choice.</p>
+<h4>&lt;zipfile&gt; | &lt;dir&gt;</h4>
+<p>Any arguments after "apis" that do not start with "+" or "-" are taken to be
+zipfiles or directories. These should be specified exactly as you would put
+them in your CLASSPATH (except separated by spaces rather than colons). Anything
+that's a file will be assumed to be a zip (or jar) file, so you can't specify
+a .class file directly - if you need to do that you should specify the folder
+containing it and then name the class for processing.</p>
+<h4>+|-&lt;pkgpath&gt;</h4>
+<p>To specify which classes are included, use +pkgpath to add pkgpaths to be
+scanned and -pkgpath to exclude sub-pkgpaths of these. You MUST specify at least
+one +pkgpath option to specify which pkgpath to include, otherwise Japize could
+happily scan through all the zipfiles and directories but not actually process
+any of the classes. Since that would be a useless thing to do, japize gives an
+error instead.</p>
+<p>A "pkgpath" refers to either a package (which includes, by implication, all
+sub-packages of it) or a single class. A pkgpath for a package looks like
+"com.foo.pkg.sub," and a pkgpath for a class looks like "com.foo.pkg,Cls". The
+existence and placement of the comma indicates unambiguously which type of path
+is intended.</p>
+<p>Most of the time, though, it's a pain to have to put in commas in names that
+are familiar with dots instead, and get the comma placement exactly right. For
+this reason, japize accepts pkgpaths containing only dots, and lets you tell it
+what to make of those names. The interpretation of "a.b.c" as a pkgpath depends
+on whether you specified apis, explicitly, byname, packages, or classes.</p>
+<dl>
+  <dt>apis</dt>
+  <dd>a.b.c is tried both as a package <i>and</i> a class. This will always do
+      what you want (which is why apis is described as the safe default) but at
+      the expense of possibly doing extra unnecessary processing trying to find
+      the wrong thing.</dd>
+  <dt>explicitly</dt>
+  <dd>pkgpaths of the form a.b.c are illegal - you must use the explicit
+      form.</dd>
+  <dt>byname</dt>
+  <dd>a.b.c will be processed as a package if "c" starts with a lowercase
+      letter, or as a class if it starts with an uppercase one. This usually
+      does what you want but fails on things like org.omg.CORBA.
+  <dt>packages</dt>
+  <dd>a.b.c will be processed as a package. If processing for a class is needed,
+      it must be specified explicitly.</dd>
+  <dt>classes</dt>
+  <dd>a.b.c will be processed as a class. If processing for a package is needed,
+      it must be specified explicitly.</dd>
+</dl>
+<h4>Example</h4>
+<p>As an example, Sun's
+JDK 1.1 includes classes in java.awt.peer and in java.text.resources that are
+not part of the public API, even though they are public classes; however, every
+other class in the java.* package hierarchy is part of the public API. The
+syntax to construct a useful jdk11.japi.gz would therefore be:</p>
+<pre>$ japize as jdk11 apis classes.zip +java -java.awt.peer -java.text.resources</pre>
+<p>Note that since all pkgpath arguments here are packages, you could save a
+small amount of processing by doing this instead:</p>
+<pre>$ japize as jdk11 packages classes.zip +java -java.awt.peer -java.text.resources</pre>
+<p>or even this:</p>
+<pre>$ japize as jdk11 explicitly classes.zip +java, -java.awt.peer, -java.text.resources,</pre>
+<p>Another example, this time doing the same thing for kaffe:</p>
+<pre>$ japize as kaffe packages $KAFFEHOME/share/kaffe/Klasses.jar $KAFFEHOME/share/kaffe/rmi.jar +java -java.awt.peer -java.text.resources</pre>
+<h4><a name="japicompat">japicompat</a></h4>
+<p>Next, you can perform the test for compatibility between these two files:</p>
+<pre>
+$ japicompat jdk11.japi.gz kaffe.japi.gz
+</pre>
+<p>The full list of flags supported by japicompat is as follows:</p>
+<pre>japicompat [-svqhtjw] [-o &lt;outfile&gt;] [-i &lt;ignorefile&gt;] &lt;original api&gt; &lt;api to check&gt;</pre>
+<p>The meanings of these options are as follows:</p>
+<h4>-s</h4>
+<p>By default, japicompat tests for binary compatibility as defined by the JLS,
+plus a couple of additions (see below for details). You can turn off these
+additions by passing the -s flag to japicompat, for example:</p>
+<pre>
+$ japicompat -s jdk11.japi.gz kaffe.japi.gz
+</pre>
+<p>The s stands for "sun", "standard", "specification", or if you like more
+colorful language, "single-buttocked" (one buttock=half an...). See "What exactly
+does japicompat test?" below for exactly what tests get turned off by this
+flag.</p>
+
+<h4>-v</h4>
+<p>By default, japicompat only checks for errors that break binary compatibility.
+However, japicompat can also check for some "minor" compatibility problems. To
+activate these additional checks, use the "-v" flag. The v stands for "verbose".</p>
+<pre>
+$ japicompat -v jdk11.japi.gz kaffe.japi.gz
+</pre>
+<p>Specifically, the -v flag enables the following additional checks:</p>
+<ul>
+  <li>SerialVersionUID checking: japicompat reports a minor error if a Serializable
+      class has a different SerialVersionUID between the two releases.</li>
+  <li>Deprecation checking: japicompat reports a minor error if a class or member
+      was deprecated in the original API but is not deprecated in the API being
+      checked.</li>
+</ul>
+
+<h4>-q</h4>
+<p>By default, japicompat provides progress reports as it runs. In unix
+terminology, these are sent to stderr (the actual results are sent to
+stdout unless the -o flag is used). The -q flag turns off these
+progress reports - only real errors will be sent to stderr.</p>
+
+<h4>-h</h4>
+<p>Generate output in HTML format. The HTML files produced depend on the
+japi.css file in the design directory to get attractive presentation.</h>
+
+<h4>-t</h4>
+<p>Generate output in text format. This is the default.</p>
+
+<h4>-j</h4>
+<p>Generate output in raw machine readable form. The format produced is called
+"japio" format, and by convention should be saved with a ".japio" file extension.
+The standalone japiotext and japiohtml utilities can be used to convert this
+format into html or text (actually, japicompat calls japiotext or japiohtml
+internally if the -h or -t flags are used). Japio files can also be used with
+the -i flag to support ignoring errors caused by incompatibilities between
+JDK versions.</p>
+
+<h4>-w</h4>
+<p>By default japicompat will produce warnings if run against japi files
+originally generated by older versions of japitools that had known bugs that
+japifix cannot eliminate. Use the -w flag to turn off these warnings, or better
+yet, generate your japi files with the latest version ;)</p>
+
+<h4>-o &lt;outfile&gt;</h4>
+<p>Send the output to &lt;outfile&gt; instead of stdout. The format of this file
+depends on the -h, -t and -j flags.</p>
+
+<h4>-i &lt;ignorefile&gt;</h4>
+<p>Suppose you are attempting to implement the Java API. You have (pretty much)
+completed coverage of the early JDK versions (1.0 and 1.1) but still have some distance
+to achieve full coverage of 1.4 (this is an accurate description of all Free
+Software Java implementations at the time of writing). Using japicompat to compare
+your implementation with JDK 1.4 gives accurate results, but you might also want to
+show your coverage of the earlier versions.</p>
+<p>Unfortunately Sun has not followed their own binary compatibility rules between
+JDK releases, let alone the expanded rules that japicompat tests for. So when you
+run a comparison between JDK 1.1 and your implementation, you will get spurious
+error reports when you're compatible with 1.4 but not 1.1.</p>
+<p>Obviously what you really want is to ignore errors like this, and japicompat
+provides a way to do so. First, run a comparison between 1.1 and 1.4 using the
+-j switch. Then run the comparison between 1.1 and your implementation, passing
+the "-i" option with the output of the previous run. For example:</p>
+<pre>
+$ japicompat -jvo ignore-11-14.japio jdk11.japi.gz jdk14.japi.gz
+$ japicompat -hvo jdk11-myimpl.html -i ignore-11-14.japio jdk11.japi.gz myimpl.japi.gz
+</pre>
+<p>(In this example I also passed the -v flag but didn't pass -s. You should use
+the same combination of these two flags for both runs of japicompat to avoid getting
+bad results)</p>
+<p>You can also get the same effect by running:</p>
+<pre>
+$ japicompat -hvo jdk11-myimpl.html -i jdk14.japi.gz jdk11.japi.gz myimpl.japi.gz
+</pre>
+<p>This is obviously simpler and quicker to type, but requires the comparison
+between jdk11 and jdk14 to be run every single time. Making the japio file
+manually allows for it to be saved and used again the next time, which lets
+japicompat run about twice as fast.</p>
+<h4>&lt;original api&gt; &lt;api to check&gt;</h4>
+<p>The japi files corresponding to the APIs to be compared.</p>
+<p>japicompat specifically tests that the second argument is
+backwardly-compatible with the first. Therefore, a perfect implementation of
+JDK 1.1 would produce no errors regardless of the order of the arguments, but a
+perfect implementation of JDK1.1 plus <em>parts</em> of JDK1.2 should be tested as
+follows:</p>
+<pre>$ japicompat jdk11.japi.gz myimpl.japi.gz
+$ japicompat myimpl.japi.gz jdk12.japi.gz</pre>
+<p>It is probably impossible to make an implementation that passes both these
+tests, since Sun's own JDK1.2 produces numerous errors when tested against
+JDK1.1. See the discussion of the -i option above for a way to cope with this
+situation.</p>
+<p>Either compressed (.japi.gz) or uncompressed (.japi) files can be passed to
+japicompat: The file extension is used to determine whether or not to pipe input
+through gzip or not.</p>
+
+<h3>What exactly does japicompat test?</h3>
+<p>As mentioned above, japicompat tests for binary compatibility as defined
+by Sun in the JLS. A full summary of what does and does not break binary
+compatibility according to Sun is <a href="jcompat.txt">here</a>.</p>
+<p>However, japicompat also performs some checks that are not specified by the
+JLS, for the simple reason that I believe the JLS is wrong to omit them. You can
+omit these four extra checks by passing the "-s" flag to japicompat, although
+I'm not sure why you would want to...</p>
+<p>The specific checks that I believe the JLS should include are:</p>
+<ul>
+<li><i>Adding an exception to the throws clause of a method or constructor
+    violates binary compatibility</i>, because a class calling that method may
+    not catch or specify the newly thrown exception. The JLS claims that the
+    VM does not perform any checks on thrown exceptions; I hope this has
+    changed because it makes it trivially easy to write a method that throws
+    any exception you like without specifying it.</li>
+<li><i>Removing an exception from the throws clause of a method or constructor
+    violates binary compatibility</i>, because a subclass may be overriding
+    the method and throwing the exception. This only applies to non-final
+    methods, but it is worth enforcing this rule for all methods and
+    constructors because otherwise it is possible to break source code
+    compatibility by rendering code in a catch block unreachable.</li>
+<li><i>Adding a method to an interface violates binary compatibility</i>,
+    because a class that implemented the original version of the interface
+    may not implement the newly added method.</li>
+<li><i>Adding an abstract method to an abstract class violates binary
+    compatibility</i>, because a concrete class derived from the original
+    version may not provide a concrete implementation of the new method.
+</ul>
+
+</body></html>
--- japitools-0.9.5+cvs20060115.orig/debian/doc-base
+++ japitools-0.9.5+cvs20060115/debian/doc-base
@@ -0,0 +1,11 @@
+Document: japitools
+Title: Manual for japitools
+Author: Stuart Ballard
+Abstract: This is the manual of japitools, a collection of Java API
+ compatibility testing tools. It consists of two simple tools designed
+ to test for compatibility between Java APIs.
+Section: Programming
+
+Format: HTML
+Index: /usr/share/doc/japitools/index.html
+Files: /usr/share/doc/japitools/index.html
--- japitools-0.9.5+cvs20060115.orig/debian/japiotext.1
+++ japitools-0.9.5+cvs20060115/debian/japiotext.1
@@ -0,0 +1,32 @@
+.TH JAPIOTEXT 1 "October 6, 2005"
+
+.SH NAME
+japiotext \- Convert japicompat output to readable plain text format.
+
+.SH SYNOPSIS
+.B japiotext
+.I <file>
+
+.SH DESCRIPTION
+.B japiotext
+is part of japitools, designed to test for compatibility between Java APIs. 
+.br
+It is used to convert the output produced by japicompat to human readable plain text.
+
+.SH OPTIONS
+.TP
+\fB\fR <file\fR>\fP
+the file produced by japicompat to convert.
+
+.SH SEE ALSO
+.BR japize (1) 
+Produce a listing of an API in a machine-readable format.
+.br
+.BR japicompat (1) 
+Test Java APIs for binary backwards compatibility.
+.br
+.BR japilist (1) 
+List the contents of japi files.
+.br
+.BR japiohtml (1) 
+Convert japicompat output to pretty html format.
--- japitools-0.9.5+cvs20060115.orig/debian/japicompat.1
+++ japitools-0.9.5+cvs20060115/debian/japicompat.1
@@ -0,0 +1,104 @@
+.TH JAPICOMPAT 1 "October 6, 2005"
+
+.SH NAME
+japicompat \- Test Java APIs for binary backwards compatibility.
+
+.SH SYNOPSIS
+.B japicompat
+.I [-svqhtjw4] [-o outfile] [-i ignorefiles] <original_api> <api_to_check>
+
+.SH DESCRIPTION
+.B japicompat
+is part of japitools, designed to test for compatibility between Java APIs. 
+
+They were originally designed for testing free implementations of Java itself for compatibility with Sun's JDK, but they can also be used for testing backward compatibility between versions of any API.
+
+The tools are japize and japicompat. Japize is a Java program which emits a listing of an API in a machine-readable format. Japicompat then takes two such listings and compares them for binary compatibility, as defined by Sun in the Java Language Specification.
+
+.SH OPTIONS
+.TP
+\fB\-s\fP
+disable additional binary compatibility checks (only do checks defined by the JLS).
+
+.TP
+\fB\-v\fP
+enable checks for minor compatibility problems.
+
+SerialVersionUID checking: japicompat reports a minor error if a Serializable class has a different SerialVersionUID between the two releases.
+
+Deprecation checking: japicompat reports a minor error if a class or member was deprecated in the original API but is not deprecated in the API being checked.
+
+.TP
+\fB\-q\fP
+disables progress reports.
+
+.TP
+\fB\-h\fP
+generates output in HTML format. The HTML files produced depend on the japi.css file to get attractive presentation.
+
+.TP
+\fB\-t\fP
+generates output in text format. This is the default.
+
+.TP
+\fB\-j\fP
+generates output in raw machine readable form. The format produced is called "japio" format, and by convention should be saved with a ".japio" file extension. The standalone japiotext and japiohtml utilities can be used to convert this format into html or text (actually, japicompat calls japiotext or japiohtml internally if the -h or -t flags are used). Japio files can also be used with the -i flag to support ignoring errors caused by incompatibilities between JDK versions.
+
+.TP
+\fB\-w\fP
+disable warnings for running against old buggy japi files. By default japicompat will produce warnings if run against japi files originally generated by older versions of japitools that had known bugs that japifix cannot eliminate. 
+
+.TP
+\fB\-4\fP
+use 1.4-compatible mode. This works as long as the APIs to compare does not contain 1.5-only items.
+
+.TP
+\fB\-o\fR <outfile\fR>\fP
+Send the output to <outfile> instead of stdout. The format of this file depends on the -h, -t and -j flags.
+
+.TP
+\fB\-i\fR <ignorefiles\fR>\fP
+Suppose you are attempting to implement the Java API. You have (pretty much) completed coverage of the early JDK versions (1.0 and 1.1) but still have some distance to achieve full coverage of 1.4 (this is an accurate description of all Free Software Java implementations at the time of writing). Using japicompat to compare your implementation with JDK 1.4 gives accurate results, but you might also want to show your coverage of the earlier versions.
+
+Unfortunately Sun has not followed their own binary compatibility rules between JDK releases, let alone the expanded rules that japicompat tests for. So when you run a comparison between JDK 1.1 and your implementation, you will get spurious error reports when you're compatible with 1.4 but not 1.1.
+
+Obviously what you really want is to ignore errors like this, and japicompat provides a way to do so. First, run a comparison between 1.1 and 1.4 using the -j switch. Then run the comparison between 1.1 and your implementation, passing the "-i" option with the output of the previous run. For example:
+
+$ japicompat -jo ignore-11-14.japio jdk11.japi.gz jdk14.japi.gz
+.br
+$ japicompat -ho jdk11-myimpl.html -i ignore-11-14.japio jdk11.japi.gz myimpl.japi.gz
+
+You can also get the same effect by running:
+
+$ japicompat -ho jdk11-myimpl.html -i jdk14.japi.gz jdk11.japi.gz myimpl.japi.gz
+
+This is obviously simpler and quicker to type, but requires the comparison between jdk11 and jdk14 to be run every single time. Making the japio file manually allows for it to be saved and used again the next time, which lets japicompat run about twice as fast.
+
+
+.TP
+\fR <original_api\fR>\fR <api_to_check\fR>\fP
+The japi files corresponding to the APIs to be compared.
+
+japicompat specifically tests that the second argument is backwardly-compatible with the first. Therefore, a perfect implementation of JDK 1.1 would produce no errors regardless of the order of the arguments, but a perfect implementation of JDK1.1 plus parts of JDK1.2 should be tested as follows:
+
+$ japicompat jdk11.japi.gz myimpl.japi.gz
+.br
+$ japicompat myimpl.japi.gz jdk12.japi.gz
+
+It is probably impossible to make an implementation that passes both these tests, since Sun's own JDK1.2 produces numerous errors when tested against JDK1.1. See the discussion of the -i option above for a way to cope with this situation.
+
+Either compressed (.japi.gz) or uncompressed (.japi) files can be passed to japicompat: The file extension is used to determine whether or not to pipe input through gzip or not.
+
+
+.SH SEE ALSO
+.BR japize (1) 
+Produce a listing of an API in a machine-readable format.
+.br
+.BR japilist (1) 
+List the contents of japi files.
+.br
+.BR japiohtml (1) 
+Convert japicompat output to pretty html format.
+.br
+.BR japiotext (1) 
+Convert japicompat output to readable plain text format.
--- japitools-0.9.5+cvs20060115.orig/debian/japilist.1
+++ japitools-0.9.5+cvs20060115/debian/japilist.1
@@ -0,0 +1,32 @@
+.TH JAPILIST 1 "October 6, 2005"
+
+.SH NAME
+japilist \- List the contents of japi files.
+
+.SH SYNOPSIS
+.B japilist
+.I <file>
+
+.SH DESCRIPTION
+.B japilist
+is part of japitools, designed to test for compatibility between Java APIs.
+.br
+It is used to list the contents of japi files.
+
+.SH OPTIONS
+.TP
+\fB\fR <file\fR>\fP
+the japi file.
+
+.SH SEE ALSO
+.BR japize (1) 
+Produce a listing of an API in a machine-readable format.
+.br
+.BR japicompat (1) 
+Test Java APIs for binary backwards compatibility.
+.br
+.BR japiohtml (1) 
+Convert japicompat output to pretty html format.
+.br
+.BR japiotext (1) 
+Convert japicompat output to readable plain text format.
--- japitools-0.9.5+cvs20060115.orig/debian/japize.1
+++ japitools-0.9.5+cvs20060115/debian/japize.1
@@ -0,0 +1,94 @@
+.TH JAPIZE 1 "October 6, 2005"
+
+.SH NAME
+japize \- Produce a listing of an API in a machine-readable format.
+
+.SH SYNOPSIS
+.B japize
+.I [unzip] [as <name>] apis <zipfile>|<dir> ... +|-<pkgpath> ...
+
+.SH DESCRIPTION
+.B japize
+is part of japitools, designed to test for compatibility between Java APIs. 
+
+They were originally designed for testing free implementations of Java itself for compatibility with Sun's JDK, but they can also be used for testing backward compatibility between versions of any API.
+
+The tools are japize and japicompat. Japize is a Java program which emits a listing of an API in a machine-readable format. Japicompat then takes two such listings and compares them for binary compatibility, as defined by Sun in the Java Language Specification.
+
+At least one +<pkgpath> is required. <name> will have ".japi" and/or ".gz" appended as appropriate.
+
+The word "apis" can be replaced by "explicitly", "byname", "packages" or "classes". These options indicate whether something of the form "a.b.C" should be treated as a class or a package. You may specify this unambiguously by using one of the forms "a.b.cpackage," or "a.b,CClass".
+
+.SH OPTIONS
+.TP
+\fBunzip\fP
+disable zipping of the output with gzip. Zipping the output is highly recommended since it saves huge amounts of space. The only situations where you might not want to use gzip compression are when memory and CPU usage are extremely tight or if your JVM does not implement GZIPOutputStream correctly (in which case you might still want to gzip the resulting file manually).
+
+.TP
+\fBas\fR <name\fR>\fP
+Specifying this option tells japize to write its output to a file with the specified name. When writing to a file with the "as" option, japize insists on writing to a file name ending in .japi.gz for compressed files, or .japi for uncompressed files. If the filename you specify doesn't have the right extension, japize will add parts to it to ensure that it does.
+
+If the "as" option is omitted, japize will write to standard output. In this case japize has no control over the filename you use, but it is strongly recommended to use a filename with the correct extension (".japi.gz" unless the "unzip" option was specified). If you use any other extension, japicompat and other tools may be unable to recognize the format.
+
+.TP
+\fBapis\fP | \fBexplicitly\fP | \fBbyname\fP | \fBpackages\fP | \fBclasses\fP
+This option has a dual role: it indicates the boundary between japize options (unzip, as) and other arguments (files and packages), but also tells japize how to deal with ambiguously specified arguments. See "+|-<pkgpath>" below for details on the behavior of each option. If you are unsure which to specify, "apis" is a safe choice.
+
+.B apis
+.br
+a.b.c is tried both as a package and a class. This will always do what you want (which is why apis is described as the safe default) but at the expense of possibly doing extra unnecessary processing trying to find the wrong thing.
+
+.B explicitly
+.br
+pkgpaths of the form a.b.c are illegal - you must use the explicit form.
+
+.B byname
+.br
+a.b.c will be processed as a package if "c" starts with a lowercase letter, or as a class if it starts with an uppercase one. This usually does what you want but fails on things like org.omg.CORBA.
+
+.B packages
+.br
+a.b.c will be processed as a package. If processing for a class is needed, it must be specified explicitly.
+
+.B classes
+.br
+a.b.c will be processed as a class. If processing for a package is needed, it must be specified explicitly. 
+
+.TP
+\fB\fR<zipfile\fR> | \fR<dir\fR>\fP
+Any arguments after "apis" that do not start with "+" or "-" are taken to be zipfiles or directories. These should be specified exactly as you would put them in your CLASSPATH (except separated by spaces rather than colons). Anything that's a file will be assumed to be a zip (or jar) file, so you can't specify a .class file directly - if you need to do that you should specify the folder containing it and then name the class for processing.
+
+.TP
+\fB+\fP|\fB-\fR<pkgpath\fR>\fP
+To specify which classes are included, use +pkgpath to add pkgpaths to be scanned and -pkgpath to exclude sub-pkgpaths of these. You MUST specify at least one +pkgpath option to specify which pkgpath to include, otherwise Japize could happily scan through all the zipfiles and directories but not actually process any of the classes. Since that would be a useless thing to do, japize gives an error instead.
+
+A "pkgpath" refers to either a package (which includes, by implication, all sub-packages of it) or a single class. A pkgpath for a package looks like "com.foo.pkg.sub," and a pkgpath for a class looks like "com.foo.pkg,Cls". The existence and placement of the comma indicates unambiguously which type of path is intended.
+
+Most of the time, though, it's a pain to have to put in commas in names that are familiar with dots instead, and get the comma placement exactly right. For this reason, japize accepts pkgpaths containing only dots, and lets you tell it what to make of those names. The interpretation of "a.b.c" as a pkgpath depends on whether you specified apis, explicitly, byname, packages, or classes.
+
+.SH EXAMPLE
+
+Sun's JDK 1.1 includes classes in java.awt.peer and in java.text.resources that are not part of the public API, even though they are public classes; however, every other class in the java.* package hierarchy is part of the public API. The syntax to construct a useful jdk11.japi.gz would therefore be:
+
+$ japize as jdk11 apis classes.zip +java -java.awt.peer -java.text.resources
+
+Note that since all pkgpath arguments here are packages, you could save a small amount of processing by doing this instead:
+
+$ japize as jdk11 packages classes.zip +java -java.awt.peer -java.text.resources
+
+or even this:
+
+$ japize as jdk11 explicitly classes.zip +java, -java.awt.peer, -java.text.resources,
+
+.SH SEE ALSO
+.BR japicompat (1) 
+Test Java APIs for binary backwards compatibility.
+.br
+.BR japilist (1) 
+List the contents of japi files.
+.br
+.BR japiohtml (1) 
+Convert japicompat output to pretty html format.
+.br
+.BR japiotext (1) 
+Convert japicompat output to readable plain text format.
--- japitools-0.9.5+cvs20060115.orig/debian/copyright
+++ japitools-0.9.5+cvs20060115/debian/copyright
@@ -0,0 +1,25 @@
+This package was debianized by Wolfgang Baer <WBaer@gmx.de> on
+Thu,  6 Oct 2005 15:52:05 +0200.
+
+It was downloaded from <http://savannah.nongnu.org/projects/japitools/>
+
+Copyright: (c) 2004-2009 Stuart Ballard <stuart.a.ballard@gmail.com>
+                         Jeroen Frijters <jeroen@frijters.net>
+
+License:
+
+   This package is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; version 2 dated June, 1991.
+
+   This package is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this package; if not, write to the Free Software Foundation,
+   Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
+
+On Debian systems, the complete text of the GNU General
+Public License can be found in `/usr/share/common-licenses/GPL-2'.