clirr-devel Mailing List for Clirr (Page 25)
Status: Alpha
Brought to you by:
lkuehne
Menu
▾
▴
clirr-devel — Discussion about the source code of Clirr
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(15) |
Oct
(23) |
Nov
|
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
(76) |
Jun
(207) |
Jul
(242) |
Aug
(42) |
Sep
(33) |
Oct
|
Nov
(7) |
Dec
(1) |
| 2005 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(66) |
Sep
(38) |
Oct
(6) |
Nov
|
Dec
(2) |
| 2006 |
Jan
(17) |
Feb
(5) |
Mar
(28) |
Apr
(6) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(7) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(33) |
Jun
(4) |
Jul
(3) |
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(4) |
Feb
(3) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
(6) |
Aug
(8) |
Sep
(5) |
Oct
(20) |
Nov
(7) |
Dec
(9) |
| 2009 |
Jan
(8) |
Feb
(3) |
Mar
(20) |
Apr
(10) |
May
(40) |
Jun
(11) |
Jul
(23) |
Aug
(4) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2010 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(22) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
| 2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2015 |
Jan
(1) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <lk...@us...> - 2004-07-10 13:37:39
|
Update of /cvsroot/clirr/clirr/core/src/java/net/sf/clirr In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23600/src/java/net/sf/clirr Added Files: overview.html Log Message: moving from root directory to core --- NEW FILE --- <html> <body> The Clirr implementation. <p> <strong> WARNING: Clirr is currently in alpha state and the API is not stable. </strong> </p> <p> If you'd like to write an IDE plugin, you can use the clirr API provided here, but be aware that the API might change in the next release of Clirr. </p> <p> You should not refer to the packages labelled 'internal' in your code, though (we follow the same <a href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">guidelines</a> as Eclipse). </p> </body> </html> |
|
From: <lk...@us...> - 2004-07-10 13:37:34
|
Update of /cvsroot/clirr/clirr/core/src/conf In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23600/src/conf Added Files: clirrtask.properties Log Message: moving from root directory to core --- NEW FILE --- clirr=net.sf.clirr.ant.AntTask |
|
From: <lk...@us...> - 2004-07-10 13:35:15
|
Update of /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/core/internal/checks In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23310/checks Log Message: Directory /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/core/internal/checks added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:34:50
|
Update of /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/core/internal In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23235/internal Log Message: Directory /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/core/internal added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:32:55
|
Update of /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/core In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22980/core Log Message: Directory /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/core added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:30:59
|
Update of /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/cli In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22676/cli Log Message: Directory /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/cli added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:30:58
|
Update of /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/ant In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22676/ant Log Message: Directory /cvsroot/clirr/clirr/core/src/java/net/sf/clirr/ant added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:28:06
|
Update of /cvsroot/clirr/clirr/core/src/java/net/sf/clirr In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22124/clirr Log Message: Directory /cvsroot/clirr/clirr/core/src/java/net/sf/clirr added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:27:50
|
Update of /cvsroot/clirr/clirr/core/src/java/net/sf In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22098/sf Log Message: Directory /cvsroot/clirr/clirr/core/src/java/net/sf added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:27:34
|
Update of /cvsroot/clirr/clirr/core/src/java/net In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22016/net Log Message: Directory /cvsroot/clirr/clirr/core/src/java/net added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:26:41
|
Update of /cvsroot/clirr/clirr/core/src/conf/net/sf/clirr/core In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21878/core Log Message: Directory /cvsroot/clirr/clirr/core/src/conf/net/sf/clirr/core added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:26:25
|
Update of /cvsroot/clirr/clirr/core/src/conf/net/sf/clirr In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21846/clirr Log Message: Directory /cvsroot/clirr/clirr/core/src/conf/net/sf/clirr added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:26:04
|
Update of /cvsroot/clirr/clirr/core/src/conf/net/sf In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21787/sf Log Message: Directory /cvsroot/clirr/clirr/core/src/conf/net/sf added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:25:48
|
Update of /cvsroot/clirr/clirr/core/src/conf/net In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21734/net Log Message: Directory /cvsroot/clirr/clirr/core/src/conf/net added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:25:08
|
Update of /cvsroot/clirr/clirr/core/src/testinput In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21576/testinput Log Message: Directory /cvsroot/clirr/clirr/core/src/testinput added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:25:08
|
Update of /cvsroot/clirr/clirr/core/src/conf In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21576/conf Log Message: Directory /cvsroot/clirr/clirr/core/src/conf added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:25:08
|
Update of /cvsroot/clirr/clirr/core/src/test In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21576/test Log Message: Directory /cvsroot/clirr/clirr/core/src/test added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:25:07
|
Update of /cvsroot/clirr/clirr/core/src/java In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21576/java Log Message: Directory /cvsroot/clirr/clirr/core/src/java added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:24:31
|
Update of /cvsroot/clirr/clirr/core/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21496/src Log Message: Directory /cvsroot/clirr/clirr/core/src added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:24:13
|
Update of /cvsroot/clirr/clirr/core/xdocs In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21403/xdocs Added Files: anttask.xml changes.xml exegesis.xml index.xml navigation.xml runcli.xml Log Message: moving from root directory to core --- NEW FILE --- <document> <properties> <title>Clirr Ant Task</title> <author>Lars Kühne</author> </properties> <body> <section name="Running Clirr as an Ant Task"> <p> clirr is distributed as an <a href="http://ant.apache.org">Ant</a> task. The following text assumes that you are familiar with Ant. To run clirr, you typically </p> <ul> <li>compile the current version of the library you want to check, resulting in one or more jar file</li> <li>tell ant about the clirr ant task</li> <li>download the compatibility baseline release of your software from a central location via http (if it is not available in your local filesystem already)</li> <li>run the clirr task</li> </ul> <p> To do this you will need an ant snippet similar to the following: </p> <source> <target name="checkbinarycompatibility" depends="build"> <!-- buildtools.classpath should contain clirr.jar and the libraries it depends on --> <taskdef classpathref="buildtools.classpath" resource="clirrtask.properties"/> <property name="jar.baseline" value="${ant.project.name}-${compatibility.baseline.version}.jar"/> <get src="${url.libbase}/${ant.project.name}/${jar.baseline}" dest="build/tmp/${jar.baseline}"/> <clirr> <origfiles dir="build/tmp" includes="${jar.baseline}"/> <newfiles dir="build/lib" includes="${jar.buildresult}"/> <!-- <formatter type="xml" outfile="build/clirr.xml" /> --> <!-- TODO: example for 3rd party classpath --> </clirr> </target> </source> </section> <section name="Parameters"> <table> <tr> <td>Attribute</td> <td>Description</td> <td>Required</td> <td>Default</td> </tr> <tr> <td>failOnBinWarning</td> <td>Whether task execution should fail (break the build) on warnings about binary compatibility issues</td> <td>No</td> <td>No</td> </tr> <tr> <td>failOnBinError</td> <td>Whether task execution should fail (break the build) on binary compatibility errors</td> <td>No</td> <td>Yes</td> </tr> <tr> <td>failOnSrcWarning</td> <td>Whether task execution should fail (break the build) on warnings about source code compatibility issues</td> <td>No</td> <td>No</td> </tr> <tr> <td>failOnSrcError</td> <td>Whether task execution should fail (break the build) on source compatibility errors</td> <td>No</td> <td>Yes</td> </tr> </table> </section> <section name="Parameters specified as nested elements"> <section name="newFiles"> <p> A <a href="http://ant.apache.org/manual/CoreTypes/fileset.html">FileSet</a> that describes the current version that should be checked against the compatibility baseline. </p> <p> Clirr works with FileSets instead of individual jar files to allow splitting up or combining library distributions. An example is log4j, the 1.3.0 release splits up the earlier log4j.jar into several jar files. </p> </section> <section name="origFiles"> <p> A <a href="http://ant.apache.org/manual/CoreTypes/fileset.html">FileSet</a> that describes the compatibility baseline to check against. </p> </section> <section name="newClassPath"> <p> The 3rd party <a href="http://ant.apache.org/manual/using.html#path">ClassPath</a> that is referenced by the checked library version (newFiles). Any class or interface that occurs as a baseclass, parameter type or method return type must be included here. </p> </section> <section name="origClassPath"> <p> The 3rd party <a href="http://ant.apache.org/manual/using.html#path">ClassPath</a> that is referenced by the compatibility baseline version (origFiles). Any class or interface that occurs as a baseclass, parameter type or method return type must be included here. </p> <p> Often the origClassPath is the same as the newClassPath. In these cases you can specify these paths using the refid attribute to avoid duplicating the classpath information. Please refer to the <a href="http://ant.apache.org/manual/using.html#path">ant manual</a> for details. </p> </section> <section name="formatter"> <p> A formatter that generates Clirr output. Multiple formatters can be specified. Available attributes for each formatter element: </p> <table> <tr> <td>Attribute</td> <td>Description</td> <td>Required</td> <td>Default</td> </tr> <tr> <td>type</td> <td>The formatter type. Available types are <em>plain</em> and <em>xml</em></td> <td>No</td> <td>plain</td> </tr> <tr> <td>outfile</td> <td>The file to write to. If not specified, output is written to stdout</td> <td>No</td> <td>stdout</td> </tr> </table> </section> <p> If no formatter is specified, Clirr will write it's findings to stdout in plain format. </p> </section> </body> </document> --- NEW FILE --- <?xml version="1.0" encoding="ISO-8859-1"?> <document> <properties> <title>Changes</title> <author>Lars Kühne</author> </properties> <body> <release version="0.4-SNAPSHOT" date="in CVS"> <action dev="lkuehne" type="add" due-to="skitching"> Improved change messages if field accessibility is weakened/strengthened. </action> <action dev="lkuehne" type="add"> <!-- RFE #961227--> Detect 'pull up in class hierarchy' refactoring for methods. </action> <action dev="lkuehne" type="fix"> XML formatter did not write method and field attributes correctly. </action> <action dev="s_kitching" type="add"> Report on methods being deprecated or undeprecated. </action> <action dev="s_kitching" type="add"> Added a command-line interface, net.sf.clirr.cli.Clirr, for running checks and generating reports from the command-line. </action> <action dev="lkuehne" type="fix"> <!-- RFE #961229--> Removed abstract methods that are specified by an implemented interface are no longer reported as a compatibility problem. </action> <action dev="s_kitching" type="add"> Report on classes changing accessability (top-level classes changing between public and package, or nested classes changing between any of public/protected/package/private). </action> <action dev="s_kitching" type="add"> It is no longer an error to add a "final" attribute to a class which has no public or protected constructors, as it was always impossible to derive subclasses from it anyway. </action> <action dev="lkuehne" type="add"> Clirr now analyses code changes for source code compatibility problems as well. Note: Ant task attribute names and the output format of the XML formatter have changed to support this feature. </action> <action dev="lkuehne" type="add"> Error messages are now localized. Initial supported languages are english and german. </action> </release> <release version="0.3" date="2004-05-23"> <action dev="lkuehne" due-to="Stephen Colebourne" type="fix"> Fixed a copy + paste error in field modifier comparison logic that would lead to false alarms and undetected compatibility problems. </action> <action dev="lkuehne" type="add"> <!-- RFE #958810 --> Detect changes of field types. </action> <action dev="lkuehne" type="add"> <!-- RFE #958808 --> Ant Task fails when filesets origFiles or newFiles are empty. Empty file sets are usually a setup problem - they should not create the impression that there are no compatibility problems, just because Clirr didn't report anything. </action> <action dev="lkuehne" type="fix"> <!-- RFE #958807 --> Documented formatter subelements in Ant task. </action> <action dev="lkuehne" type="add"> <!-- RFE #958808 --> Warn about compile time constant value changes. Changing the value of a constant is not binary incompatible (you won't get any Exception), but client code compiled against the old version of the library will have the old value inlined and continue to use that old value. See the Java Language Spec, Chapter 13.4.8, for details. </action> <action dev="lkuehne" type="add"> <!-- RFE #958809 --> Warn about adding new superclasses to a class derived from java.lang.Throwable. Such changes are not binary incompatible (you won't get any Exception), but a different catch clause might get selected in client code. </action> </release> <release version="0.2" date="2004-05-22"> <action dev="lkuehne" type="add"> Initial public release. </action> </release> </body> </document> --- NEW FILE --- <?xml version="1.0" encoding="ISO-8859-1"?> <document> <properties> <title>Difference Message Reference Manual</title> <author>The Clirr Development Team</author> </properties> <body> <section name="Introduction"> <p> When clirr generates an ERROR, WARNING or INFO message about a change in the jars being compared, there is an associated message reference code. This document contains an explanation of the meaning of that message which may contain information which could not be fitted into the brief message summary. </p> <p> Messages are separated into three severity levels: <ul> <li>ERROR</li> <li>WARNING</li> <li>INFO</li> </ul> </p> <p> Errors come in two flavours: <ul> <li> Link-time failures, where an exception will be thrown as soon as code compiled against an old version of a class and the new version of the class are loaded into the same classloader hierarchy. </li> <li> Run-time failures, where an exception is thrown when code compiled against the old version of a class attempts to call a method on a new version of the class, or vice versa. </li> </ul> <p> Clirr reports "errors" for cases where it is <i>possible</i> to get a run-time failure. Whether one actually occurs can depend upon the way the library is called, ie changes reported as an error may in fact work when used as long as the patterns of use of the library do not trigger the failure situation. </p> </p> <p> Warnings are issued for situations where no link or runtime exception will occur, but where the application may behave unexpectedly due to the changes that have occurred. </p> <p> Information messages provide users with information about new features which have been added without breaking backward compatibility in any way. </p> <p> In the following sections, the term "old" is used to refer to a class, interface, method or field from the set of jars which represent the old/previous/original/baseline version of the library being inspected. The term "new" is used to refer to a class, interface, method or field from the set of jars which represent the new/current/latest version of the library being inspected. </p> </section> <section name="Messages"> <section name="7000 - Method now in Superclass"> <p>Severity: <code>INFO</code></p> <p> The old class had a method named X. The new class no longer has this method, but a parent class does define this method, so no binary or source incompatibility has occurred. </p> <p> Note that this change may have the effect of forcing the new class to become 'abstract'. If this is the case, then this change is reported separately. </p> </section> <section name="7001 - Method now in Interface"> <p>Severity: <code>INFO</code></p> <p> The old class or interface previously had a method named X. The new class or interface no longer has this method, but a parent interface does define this method, so no binary or source incompatibility has occurred. </p> <p> Note that this change may have the effect of forcing the new class to become 'abstract'. If this is the case, then this change is reported separately. </p> </section> <section name="7002 - Method Removed"> <p>Severity: <code>ERROR</code></p> <p> The old class or interface had a method named X. The new class or interface no longer has this method, and this method is not defined on any parent class or interface. </p> <p> Whether an error actually occurs at runtime for this change depends on usage patterns. The modified class can be used with existing code as long as that existing code does not attempt to call the removed method. If a call to the missing method is made, then a NoSuchMethodError exception is generated when the method invocation occurs. </p> </section> <section name="7003 - Unused"> <p>This message code is not currently used.</p> </section> <section name="7004 - Method Argument Count Changed"> <p>Severity: <code>ERROR</code></p> <p> The specified method has had arguments added or removed. This means that code which previously invoked it will no longer invoke the same method. </p> <p> If there is an inherited method definition with the old prototype, then there is no binary incompatibility; code which was compiled against the old version of this class will now invoke the inherited implementation. <em>In this situation, clirr should output an INFO message rather than an error. However at the current date, clirr does not check for this situation</em>. </p> <p> If there is no inherited method definition with the old prototype, then the change is a binary incompatibility. </p> </section> <section name="7005 - Method Argument Type changed"> <p>Binary Severity: <code>INFO or ERROR</code></p> <p>Source Severity: <code>ERROR</code></p> <p> The specified method has had the type of one or more of its arguments modified. This means that code compiled against the old version of the class will no longer invoke the same method. However exactly the same old source code, when compiled against the new class version <i>may</i> invoke this method if the argument types are assignment-compatible. </p> <p> If there is an inherited method definition with the old prototype, then there is no binary incompatibility; code which was compiled against the old version of this class will now invoke the inherited implementation. <em>At the current date, clirr does not check for this situation</em>. </p> <p> If there is no inherited method definition with the old prototype, then the change is a binary incompatibility. </p> <p> If the parameter types changed were all changed to <i>supertypes</i> of their previous declared types, or for primitive parameter types if they were changed to "larger" types in every case, then the new code is <i>source-code-compatible</i> with the previous release even if it is not binary-compatible. Note that in this situation, recompiling code which uses the library may change its behaviour from calling an inherited method to calling a method on the class which has a slightly different prototype. <em>At the current date, clirr does not check for this situation</em>. </p> </section> <section name="7006 - Method Return Type changed"> <p>Binary Severity: <code>ERROR</code></p> <p>Source Severity: <code>INFO or ERROR</code></p> <p> The specified method has had its declared return type changed. Whether a problem actually occurs at runtime when using code compiled against the old version of this library depends upon usage patterns. Old code may call other methods on this class. However any attempt to call the method whose return type has changed will result in a NoSuchMethodError being thrown when the method is invoked, because the return type is part of the "method signature". </p> <p> The change is <i>source-code-compatible</i> if and only if the new return type is <i>assignable to</i> the old return type. This means that: <ul> <li> if the old return type was a primitive type, then the new return type must be <i>narrower</i> than the old type. </li> <li> if the old return type was an interface, then the new return type must be a class or interface which implements the old return type. </li> <li> if the old return type was a class, then the new return type must be a subclass of the previously returned type. </li> </ul> Clirr does not currently check for source-code compatibility for changes in method return types; currently these are simply reported as an ERROR. </p> </section> <section name="7007 - Method has been Deprecated"> <p>Severity: <code>INFO</code></p> <p> The specified method has been declared as "deprecated". This is always a binary-compatible change as well as a source-code-compatible change. </p> </section> <section name="7008 - Method has been Undeprecated"> <p>Severity: <code>INFO</code></p> <p> The specified method was declared "deprecated" in the previous version, but is no longer deprecated in the current release. While slightly unusual, this is permitted. This change is always a binary-compatible change as well as a source-code-compatible change. </p> </section> <section name="7009 - Method is now Less Accessable"> <p>Severity: <code>ERROR</code></p> <p> The access permissions associated with the specified method have been tightened to permit less user code to access the method. </p> <p> Whether this change is truly a binary-compatibility error depends upon patterns of usage. If the change is from public to protected, and the protected method is only invoked from code which subclasses the modified class then the new accessability for the method is still adequate and no problem will occur. Old code will also continue to work correctly as long as the modified method is not invoked. If it is invoked, then an IllegalAccessException is thrown at the time of method invocation. </p> <p> Whether this change is a source-code compatibility issue or not also depends upon patterns of usage. This change is therefore always reported as an ERROR. </p> </section> <section name="7010 - Method is now More Accessable"> <p>Severity: <code>INFO</code></p> <p> The access permissions associated with the specified method have been loosened to permit more user code to access the method. This is always a binary and source-code compatible change. </p> </section> <section name="7011 - Method Added"> <p>Severity: <code>INFO</code></p> <p> A non-abstract method has been added to the specified class. This is always a binary-compatible change. </p> <p> It is also a source-code compatible change. </p> <p> Q: if the new method overrides an inherited one, then which version does code compiled against the old library invoke? </p> </section> <section name="7012 - Method Added to Interface"> <p>Binary Severity: <code>ERROR</code></p> <p>Source Severity: <code>ERROR</code></p> <p> A method declaration has been added to the specified interface. This is always reported as a binary-compatibility error, but in practice the changed class <i>might</i> be used successfully with code compiled against the old interface depending upon usage patterns. </p> <p> Old code which invokes methods upon code compiled against the new (expanded) interface will continue to work without issues. And old code which implements the old version of the interface will also continue to work correctly as long as no code attempts to invoke any of the newly-added methods against that instance. But code which (validly) invokes one of the new methods in the interface against an object which implements only the old version of the interface will cause an AbstractMethodError to be thrown at the time the method invocation is attempted. </p> <p> Adding a method to an interface is always reported as an ERROR, because classes that implement that interface must now be modified to implement the declared method. </p> </section> <section name="7013 - Abstract Method Added to Class"> <p>Binary Severity: <code>ERROR</code></p> <p>Source Severity: <code>ERROR</code></p> <p> An abstract method declaration has been added to the specified class. This is always reported as a binary-compatibility error, but in practice the changed class <i>might</i> be used successfully with code compiled against the old class depending upon usage patterns. </p> <p> If instances of objects compiled against the old class are created, then their methods can be invoked without problems. But if the newly-added abstract method is ever invoked, then an AbstractMethodError is thrown at the time the method invocation is attempted. </p> </section> </section> </body> </document> --- NEW FILE --- <?xml version="1.0" encoding="ISO-8859-1"?> <document> <properties> <title>Clirr</title> <author>Lars Kühne</author> <meta name="keyword" content="java, api, diff, compare, jar, binary, compatibility, compatible, detect, incompatibility, incompatible"/> </properties> <body> <section name="What is it?"> <p> Clirr is a tool that checks Java libraries for binary and source compatibility with older releases. Basically you give it two sets of jar files and Clirr dumps out a list of changes in the public api. The Clirr Ant task can be configured to break the build if it detects incompatible api changes. In a continuous integration process Clirr can automatically prevent accidental introduction of binary or source compatibility problems. </p> </section> <section name="Background"> <p> To learn more about binary compatibility of Java APIs the follwing articles provide some detailed background material: <ul> <li> the article <a href="http://eclipse.org/eclipse/development/java-api-evolution.html">Evolving Java-based APIs</a> on the Eclipse web site. </li> <li> the <a href="http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html">Binary Compatibility</a> section in the Java Language specification. </li> </ul> </p> </section> <section name="Features"> <ul> <li>Report all API changes (currently only partially implemented)</li> <li>Evaluate each change wrt. binary and source compatibility</li> <li>support plain text and XML reports</li> <li>Flexible failure handling (warnings vs. errors, break the build or set error property)</li> </ul> </section> <section name="Name"> <p> The name clirr is derived from the binary compatibility property that a new release of a library/component should have (cited from the above mentioned Eclipse article): </p> <p> Pre-existing <em>C</em>lient binaries must <em>li</em>nk and <em>r</em>un with new <em>r</em>eleases of the Component without recompiling. </p> <p> You can also use clirr as a verb, as in <cite>Last night the build clirred</cite>, meaning that binary incompatibility problems were detected and broke the build. </p> </section> </body> </document> --- NEW FILE --- <?xml version="1.0"?> <project name="Clirr"> <title>Clirr</title> <body> <links> <item name="SourceForge Project Page" href="http://sourceforge.net/projects/clirr"/> <item name="Hosted by SourceForge" href="http://sourceforge.net/"/> </links> <menu name="Clirr"> <item name="Overview" href="/index.html"/> <item name="Download" href="/download.html"/> <item name="Running Clirr"> <item name="From Ant" href="/anttask.html"/> <item name="From a command-line" href="/runcli.html"/> </item> <item name="Message Explanations" href="/exegesis.html"/> </menu> <!-- footer will be placed above the (c) --> <footer> Hosted by <a href="http://sourceforge.net"> <img src="http://sourceforge.net/sflogo.php?group_id=89627&type=1" border="0" alt="sourceforge"/> </a> </footer> </body> </project> --- NEW FILE --- <document> <properties> <title>Clirr Command-Line Usage</title> <author>Lars Kühne</author> </properties> <body> <section name="Running Clirr from the Command Line"> <p> Clirr provides an "uberjar" download, which bundles all the necessary code, including all required libraries, into a single executable jar file. Clirr can then be run from a commandline via the command: <code> java -jar clirr-1.0-uber.jar </code> Running clirr with no command-line arguments will display the available options. </p> </section> </body> </document> |
|
From: <lk...@us...> - 2004-07-10 13:24:12
|
Update of /cvsroot/clirr/clirr/core In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21403 Added Files: maven.xml project.properties project.xml Log Message: moving from root directory to core --- NEW FILE --- <?xml version="1.0"?> <project default="java:jar" xmlns:u="jelly:util" xmlns:j="jelly:core"> <preGoal name="test:test"> <attainGoal name="clirr:compiletestlibs"/> </preGoal> <goal name="clirr:compiletestlibs"> <u:tokenize var="testlibs" delim=", ">${clirr.testlibs}</u:tokenize> <j:forEach items="${testlibs}" var="testlib" indexVar="testlibIdx"> Compiling test input ${testlib} <j:set var="testlibclassdir" value="${maven.build.dir}/testinput/${testlib}/classes"/> <mkdir dir="${testlibclassdir}"/> <javac srcdir="${basedir}/src/testinput/${testlib}" destdir="${testlibclassdir}"/> <jar basedir="${testlibclassdir}" jarfile="${maven.build.dir}/testinput/${testlib}.jar" /> </j:forEach> </goal> </project> --- NEW FILE --- maven.xdoc.date=left maven.xdoc.version=${pom.currentVersion} # use toplevel checkstyle configuration maven.checkstyle.properties=${basedir}/../conf/clirr_checks.xml maven.checkstyle.header.file=${basedir}/../conf/javaheader.txt maven.checkstyle.fail.on.violation=true # include api overview page, will work only with Maven version > 1.0-rc1 maven.javadoc.overview=${pom.build.sourceDirectory}/net/sf/clirr/overview.html # use the toplevel license file in subproject maven.license.licenseFile=${basedir}/../LICENSE.txt # hide irrelevant stuff from the nav bar maven.xdoc.poweredby.image= maven.xdoc.developmentProcessUrl= maven.junit.fork=true # tell tests where testinput is maven.junit.sysproperties=testinput testinput=${basedir}/target/testinput # class to execute from all-in-one uberjar maven.uberjar.main=net.sf.clirr.cli.Clirr # used by test pregoal to generate test input, see maven.xml clirr.testlibs=testlib-v1, testlib-v2 --- NEW FILE --- <?xml version="1.0" encoding="ISO-8859-1"?> <project> <extend>${basedir}/../project.xml</extend> <id>clirr-core</id> <name>Clirr Core</name> <package>net.sf.clirr</package> <repository> <connection>scm:cvs:pserver:ano...@cv...:/cvsroot/clirr:clirr/core</connection> <url>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/clirr/core</url> </repository> <!-- jar files the project is dependent on --> <dependencies> <dependency> <groupId>bcel</groupId> <artifactId>bcel</artifactId> <version>5.1</version> <url>http://jakarta.apache.org/bcel</url> </dependency> <dependency> <groupId>ant</groupId> <artifactId>ant</artifactId> <version>1.5.3-1</version> <url>http://ant.apache.org</url> </dependency> <dependency> <groupId>commons-cli</groupId> <artifactId>commons-cli</artifactId> <version>1.0</version> <url>http://jakarta.apache.org/commons-cli</url> </dependency> <dependency> <groupId>commons-lang</groupId> <artifactId>commons-lang</artifactId> <version>1.0.1</version> <url>http://jakarta.apache.org/commons-lang</url> </dependency> </dependencies> <!-- build information for the project --> <build> <nagEmailAddress>cli...@li...</nagEmailAddress> <sourceDirectory>${basedir}/src/java</sourceDirectory> <unitTestSourceDirectory>${basedir}/src/test</unitTestSourceDirectory> <unitTest> <includes> <include>**/*Test.java</include> </includes> </unitTest> <resources> <resource> <directory>${basedir}/src/conf</directory> </resource> </resources> </build> <reports> <report>maven-changes-plugin</report> <report>maven-javadoc-plugin</report> <report>maven-jdepend-plugin</report> <report>maven-junit-report-plugin</report> <report>maven-jxr-plugin</report> <report>maven-license-plugin</report> <report>maven-tasklist-plugin</report> </reports> </project> |
|
From: <lk...@us...> - 2004-07-10 13:24:12
|
Update of /cvsroot/clirr/clirr/core/xdocs/images In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21403/xdocs/images Added Files: clirr.png Log Message: moving from root directory to core --- NEW FILE --- PNG 4Ò¦q »{Å#8÷ YèÑÝjy*}U)° £_Ýjµ4@£Ñh4F£Ñh4F£1%7×np= ¡¿?onú«7UwªF¦æ{írúö c}ß³ë UÄ¥ +?¥å<Þ¿OÕ´ß´+,Ö¯R ±ÍåøC¦ïûÕX¦ã j«)j¨n+~°°³uË (Õ¯Ù`>k ìERQa1K°@ Ëe»äWLÉ'A ä}±·õÓØ¥ù ²^Y¸îÕC*XZÉ5q9×e,̦#¡{UHU[má ¢j¹Æp¤ðorp l ©Ê䨵Þç K j^;¬C2 ^4·xÛ ËST¥f Z®Y¾NÈrÕ^É~û*©Ê+Ôé¯õîN"ëe ó 0!£L -ûDò«+`>'AÚÑm%÷η¦õF KÜ+Ù©b"÷@h¹5NÜÜpÊ;å$p^³h RäÞC*{M²¿uI_²ç×: ò]òÂR-ÙÆÈe×7(ÛÌW? )¶Ú D˽v8]·\$[¢âè@§òÌN½ÏE,sq5Ï ËmAX6í/0Ã{[.w8|düüð ü×3ß"õ½%Ê ~Ä2kËDÖúH:ÚIøX'Þ§ËÎû¶é)÷öh3f5]¢Öû¾_ö5ÑF£Ñh4F£Ñÿ+V÷ ÍÕ |
|
From: <lk...@us...> - 2004-07-10 13:21:28
|
Update of /cvsroot/clirr/clirr/core/xdocs/images In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21073/images Log Message: Directory /cvsroot/clirr/clirr/core/xdocs/images added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:20:56
|
Update of /cvsroot/clirr/clirr/core/xdocs In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20929/xdocs Log Message: Directory /cvsroot/clirr/clirr/core/xdocs added to the repository |
|
From: <lk...@us...> - 2004-07-10 13:19:20
|
Update of /cvsroot/clirr/clirr/core In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20578/core Log Message: Directory /cvsroot/clirr/clirr/core added to the repository |
110 messages has been excluded from this view by a project administrator.
