The BND tool used in the (misnamed) felix maven-bundle-plugin has, in recent versions not yet used in the maven-bundle plugin, some logic to determine whether an Import-Package constraint is "uses" or "implements" and decides which segment of the version number to increment based on that.
might be useful... david jencks On Nov 9, 2010, at 4:58 AM, Jesse Glick 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
