Thanks for the insightful comments! I'll definitely take a look at sigtest. The gpl v2 w/ classpath exception should be fine. The only current problem is that it's not in the maven repo. I don't suppose your teams usage of it is based off on an open source ant task?
Simply based on the activity of the project (recent releases) it might be a better call than clirr. Also good to have a dev team to report bugs to. My thoughts exactly on the annotation ie. hosted in a generic context. The concern I have is the number of useful open source projects that expose interfaces that clients are not required to implement. Ultimately since this style of checking is primarily used by the devs of the project, I can have them define the annotation, and whether it marks an interface as "client implements", or "client does not implement". Those might not be the best names for the annotation, as it really would mean 'Client implements it and my code will break binary compatibility, by calling it at runtime". I've seen code that uses reflection to deal to deal with enhanced apis, calls the method if it exists, otherwise not call it and carry on. It was a pretty nifty way of handling the problem. And with tools like fest-reflect<http://fest.easytesting.org/>, wasn't incredibly ugly. So I want to make sure the toolset handles this case. Though cutting a new interface is generally better programming, I dont want this tool to force developers to do that. I want this to be easily adopted by as many projects as possible. Would the ability to configure the annotation and whether the plugin should use binary or source compatibility when evaluating the interface/abstract class meet your needs for QualifiedPublic? something like <configuration> <annotation>org.blah.ClientImplementsAllMethods</annotation> <clientsExpectedToImplementAllMethods>false</clientsExpectedToImplementAllMethods> </configuration> or <configuration> <annotation>org.blah.ClientMayNotImplementAllMethods</annotation> <clientsExpectedToImplementAllMethods>true</clientsExpectedToImplementAllMethods> </configuration> Where the annotation class is optional and as no default, and the clientsExpectedToImplementAllMethods is false. Rex On Tue, Nov 9, 2010 at 4:58 AM, Jesse Glick <jesse.gl...@oracle.com> wrote: > 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 > >
