Very cool. I'll have to check that out as well to determine how BND decided to calculate version numbers, though it's not directly applicable as osgi creates versions at the package level.
Osgi semantic versioning<http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf> seems to extend the ideas in the apache apr, and uses the terms: consumes and provides to make clear the role an package plays at runtime. At the very least this indicates the need to support several different versioning standards (apr and osgi semantic versionsing). I really like the idea that an api can have consumers and providers, and that they are not mutually exclusive in the same artifact. From the bnd guy himself<http://www.aqute.biz/Bnd/Versioning> . Makes me think about maven scopes, perhaps allow for "consumes" and "provides", and default the current compile scope to be both. Or maybe not. OSGi seems to need more info than maven can provide to auto build the manifests. Just makes me believe Jesse is correct about interfaces/abstract classes. Default to any change being a break in backwards compatibility, but provide ability to be more lax for api jar files by letting developers alter default behavior. Rex On Tue, Nov 9, 2010 at 9:51 AM, David Jencks <david_jen...@yahoo.com> wrote: > 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 > >
