Fully understood. A built in limitation of osgi is package level control, as opposed to class.
I'm leaning to using the (javadoc) annotations Mark pointed out, They seem a better way to modify the default clirr/sigtest severity behavior. http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/reference/api-tooling/api_javadoc_tags.htm Where the annotation would be able to push the severity of the addition of a method to an interface down from "backwards breaking" to "enhancement" with @noextends and @noimplement. Any change would be ignored with a @noreference. @nooverride would probably have no meaning for now. @noinstantiate could make changes to a constructor a no-op. What do you think? Rigid default behavior with these as the escape hatch? I'll ping the eclipse folks and see what they think, see if they have advice on the use of these.... I think I'll implement this as a separate jar that filters the results of the java-version-delta, not part of the default behavior. That way it could be used with an osgi-version-delta, provided the OsgiDelta class extends the JavaDelta class (represents one change to one class) , and other filters could replace it if this is found to be lacking. I could also a default @noextends and @noimplement filter to allow existing opensource api projects to adopt this without issue. I think we've hashed it out (and grew the scope) enough. This'll chew up all my free time for the next two-three weeks. As soon as I have all the interfaces built out and playing nice together (at least printing out the deltas) I'll post it to github or something similar and update this thread if anyone is interested in looking at it, so it can benefit from early criticism. Rex On Tue, Nov 9, 2010 at 2:47 PM, Jesse Glick <jesse.gl...@oracle.com> wrote: > On 11/09/2010 02:21 PM, Rex Hoffman wrote: > >> http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf >> > > Take note of the distinction made on pp. 5-6 between "interface" and > "package". Without some special annotations, it is not possible for a tool > to mechanically decide whether a given interface is intended to be used by a > consumer and implemented by a provider, or vice-versa (or some more complex > combination). > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Rex (415) 273-9438 http://www.e-hoffman.org
