On 11/08/2010 02:21 AM, Rex Hoffman wrote:
project: java-version-delta
By the way, you should look at https://sigtest.dev.java.net/ if you have not done so already. I'm not sure if the license & feature set suits your needs but it would make a potentially useful alternate impl. This is the tool used by some of Oracle's teams to check (primarily binary) compatibility of Java APIs.
My background: for netbeans.org API modules we run this tool to check for compatible & incompatible changes among packages marked public. Currently we have an idiosyncratic Ant build (is there any other kind?) so comparisons are done against the modules as they existed in the last product release, but of course in a Maven setup we would use the policy you are proposing: x.y -> x.(y+1) may have compatible but not incompatible changes, etc.
The apache portable runtime version standard does want the name of a library to include it's major version number, so for ubuntu/debian xerces look like: libxerces2-java_2.9.0-1_all.deb
Not sure this is applicable to most Java development. If you are using a container (such as OSGi) which supports class loader isolation, *and* this container permits multiple components with the same ID (but possibly different versions) to be loaded in parallel, then it is unnecessary. Containers with isolation but which enforce uniqueness on loaded IDs might benefit, so long as it really makes sense to load two copies of the component - true for plain old class libraries, not necessarily true for "active" components which might register services of some sort. Apps not using a container are unlikely to benefit since you could only use multiple versions of a library in case the package hierarchy was also renamed. Anyway, I agree that this is not likely something that an API compatibility plugin should address (a separate enforcer rule would suffice).
the default would be to assume that a client of an artifact is not expected to implement [any interfaces]
This seems like a poor default - directly contradicts the longstanding Java compatibility policy. (*) If anything, I would place the burden on API designers who publish interfaces (or abstract classes) they expect no one else to implement, despite there being no such enforcement from the Java language. (**) An annotation for this purpose makes some sense, but it would have to be hosted in a very generic place quite unrelated to a Maven plugin. In the short term, plugin configuration to exclude implements checking on certain types or packages may be a better workaround.
(*) For binary compatibility it is permitted to add an interface method without breaking existing implementers, so long as this method is never called - but that condition is unlikely, since why would there be a method no one is calling? You cannot even check whether a given object implements a new method or not without using reflection. Better to just introduce a new interface (possibly extending the old one) when you want to change signatures.
(**) If the API designer wants, it is possible to expose an abstract class which can be implemented only within the same component. JSR 294 would be very helpful here, but it is possible today so long as all the implementations are in the same package, *or* the component uses a format (such as OSGi bundle) which permits restrictions on the exported types or packages. In http://bitbucket.org/jglick/qualifiedpublic I have been playing with a more fine-grained system but for now it requires javac from JDK 7.
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
