I would deal with this same way osgi does: guidelines, annotations, tools. example: * be clear if your jar is API artifact vs API consumer artifact vs API provider artifact. * @ConsumerType and @ProviderType will tell people what to expect. * enforcement plugins will quickly educate about the distinctions.
since maven is "convention over configuration", this should work. "Have you tried " - not yet, about to start :-). please share your experience. -------- Original Message -------- Subject: Re: RFP: Version Range Policy From: David Jencks <david_jen...@yahoo.com> To: Maven Developers List <dev@maven.apache.org> Date: Wed 10 Apr 2013 05:54:53 PM CDT > so you are basically saying all packages are exported. I think you will find > that few meaningful code changes will result in a non-major-version change > whether or not the intended api changes. Have you tried this out with some > real non-osgi projects to see what versions you'd come up with and whether > they correspond in any way with what the project developers think the > versions are? > > thanks > david jencks > > On Apr 10, 2013, at 3:23 PM, Andrei Pozolotin <andrei.pozolo...@gmail.com> > wrote: > >> I am more optimistic then you. here is the idea >> https://github.com/barchart/barchart-version-tester/wiki/Maven-OSGI >> >> -------- Original Message -------- >> Subject: Re: RFP: Version Range Policy >> From: David Jencks <david_jen...@yahoo.com> >> To: Maven Developers List <dev@maven.apache.org> >> Date: Wed 10 Apr 2013 12:44:19 PM CDT >>> Can you explain how you think osgi semantic versioning can reasonably be >>> applied to non-osgi-bundles? It typically takes a project a year or two to >>> figure out what semantic versioning means when converting a project to >>> osgi, I think you would find that trying to apply semantic versioning to >>> non-osgi projects will mean that every update is a major version change. >>> >>> It would be nice if all projects converted to osgi and used semantic >>> versioning correctly, but I don't think that is going to happen any time >>> soon and I don't think the majority of maven projects will be osgi any time >>> soon. >>> >>> thanks >>> david jencks >>> On Apr 10, 2013, at 10:27 AM, Andrei Pozolotin <andrei.pozolo...@gmail.com> >>> wrote: >>> >>>> *Maven Developers* >>>> >>>> 1) This is a formal request to resolve long standing version range >>>> policy problem in maven, >>>> expressed for example in the following ticket: >>>> http://jira.codehaus.org/browse/MNG-3092 >>>> >>>> THE PROBLEM: LACK OF VERSION RANGE POLICY. >>>> >>>> 2) I there are no better ideas, I suggest Maven to adopt OSGI >>>> Semantic Version Guidelines. >>>> https://github.com/barchart/barchart-version-tester/wiki/Version-Policy >>>> >>>> 3) I have working prototype based on maven 3.0.4 with back port of >>>> aether 0.9.0.M2 >>>> specifically applied to karaf use case, which could be generalized. >>>> https://github.com/barchart/barchart-maven-karaf-plugin >>>> >>>> 4) there is an Aries version check plugin, that shows generic java >>>> binary compatibility checks >>>> which should be part of the new maven semantic version contract. >>>> https://github.com/apache/aries/tree/trunk/versioning >>>> >>>> Thank you, >>>> >>>> Andrei >>>> >>> --------------------------------------------------------------------- >>> 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 > >
