Thx for the in-depth review of the problem. I'm all for fixing and making things easier to use, so +1 for the idea.
If I understand you correctly, the first big step would be to incorporate your custom OSGi-compatible resolver into pax-url-aether, and include this new version of pax-url-aether into karaf. I don't really see any problem with that. Though we may need 2 things: * a boolean configuration to restore pure maven compatibility if some people need * support for the RELEASE maven version, which indicates the latest non snapshot version, we do use it at runtime, see [1] With the above, I think you should simply go and commit your changes to pax-url directly. Once that's done, do you foresee any more points to fix ? [1] https://github.com/apache/karaf/blob/master/assemblies/features/standard/src/main/feature/feature.xml#L66-L97 2017-02-01 2:05 GMT+01:00 Łukasz Dywicki <l...@code-house.org>: > Dear receivers, > I would like to summarize my research and fight to align version range > handling in different parts of karaf related projects. As some of you > might not know version ranges are working differently depending on > context we are working in. In general most of logic stays the same > while there are some edge cases which breaks up everything. But let me > start from begining. > > Karaf is OSGi related project which keeps very nice integration with > maven based repositories thanks to pax-url. Both environments do > support ranges in quite different way, an example of maven range > understanding is described in maven enforcer plugin documentation [1]. > Reason why ranges are working differently here and there is a maven > snapshot version and understanding of released version. Osgi framework > does not distinguish any of these. It has knowledge of major, minor > and micro parts of an version and uses them for comparision but the > qualifier is just a text which might be used for sorting artifacts > with same number. This means that for Maven 3.0-SNAPSHOT version is > lower than 3.0. In maven there is also knowledge of alpha, beta, rc, > cr, milestone, ga and sp (service pack) release types [2]. > > Now lets come to places which are using or might be using version > ranges in typical Karaf based project: > - OSGi framework for wiring in packages > - pax-url-mvn for installing maven artifacts > - karaf feature core for choosing dependant features > - maven for including dependant artifacts (ie. feature sets/KARs etc) > - karaf-maven-plugin for building assemblies > > When any of range definitions is crossing osgi-maven world problems > starts to happen. For example range such [2.18, 2.19) in maven will > accept 2.19.0-SNAPSHOT while in OSGi it will not. This lead to > situations that these two code parts behave completely differently > (assuming that camel-core feature is just one bundle): > <bundle>mvn:org.apache.camel/camel-core/${camel.version}</bundle> > <feature version="${camel.version}">camel-core</feature> > This will behave like above but not like bundle statement: > <repository>mvn:org.apache.camel.karaf/features/${camel. > version}/xml/features</repository> > > There are some attempts to work around that by using versions starting > from ie 2.18.1 so version beginning works just fine but still there is > problem of range end. To exclude 2.19-SNAPSHOT in maven you must use > "2.19.min" which in osgi will acceptversion 2.19.. Obviously there is > also no way to influence 3rd party so they do not release version > 4.1.0 but 4.1.1 just for our environment pleasure. > > For me it's quite big issue because hitting us on daily basis. We have > quite few modules (around 400) which are usualy moving together but > they should be keeping contract/interfaces on micro versions. This > inconsistency lives in Karaf and Pax Url since very long time and > current project infrastructure is not ready to changing that. From > other hand keeping this inconsistent will lead to ultimate fail some > day and users frustration as well (see KARAF-4105 [3]). Worth to point > that this issue pointed out brieefly this issue but didn't solve cause > but aligned just one place to maven's logic while keeping all others > the same. > > I took my chance and managed to get maven understanding osgi version > ranges thanks to core extensions mechanism they have [4]. I also > managed to correct shaded aether inside pax-url [5] so it use version > ranges in same way as maven. What I completely failed is making a > custom distro built with my pax-url. Since pax-url-mvn is a startup > bundle I can't use overrides for changing it's version and I can't > influence its classes using fragment bundle (yet). To get my own > pax-url I would ned to get rid of framework, but then I have to copy > bunch of resources. It would be fine for temporary prosthesis but I > can't rely on it forever. I also got into troubles with > karaf-maven-plugin when setting extra dependency with "my own aether". > > As you now know - there is lots of troubles with version ranges making > their usage in end-to-end build very difficult. I would love to get > this solved as soon as possible in 4.1 without holding current > release. Aligning all these version range handling is definitelly > doable because from Maven/Aether perspective there is an SPI for that. > We just need to deliver it our own VersionRangeResolver interface [6]. > Open question is shall we keep ordering of versions same as maven > breaking up a little osgi range understanding here. > > [1] http://maven.apache.org/components/enforcer/enforcer- > rules/versionRanges.html > [2] https://github.com/eclipse/aether-core/blob/1.0.x/aether- > util/src/main/java/org/eclipse/aether/util/version/ > GenericVersion.java#L183 > [3] https://issues.apache.org/jira/browse/KARAF-4105 > [4] http://markmail.org/message/z6x27umabwqhdjvy > [5] https://github.com/splatch/maven-osgi-resolver/blob/ > master/compatible-pax/pom.xml > [6] https://github.com/splatch/maven-osgi-resolver/blob/ > master/compatible-locator/src/main/java/org/apache/maven/ > repository/internal/MavenRepositorySystemUtils.java#L78 > > Kind regards, > Lukasz > -- > Apache Karaf Committer & PMC > Twitter: @ldywicki > Blog: http://dywicki.pl > Code-House - http://code-house.org > -- ------------------------ Guillaume Nodet
