2017-02-01 11:31 GMT+01:00 Łukasz Dywicki <[email protected]>: > Thanks for your repiles. If we will manage to get pax-url accepting > different version range resolving than maven default then I think we > will not have any troubles with features left. What I was thinking > about is moving my maven-osgi-resolver to karaf tooling and extending > pax-url in the way it could pick up version range resolver > implementation from fragment bundle. This way we could keep current > behavior which might be used by someone but also let others use end to > end range support. There are more "extension points" built into > Aerther which gets normally wired by IoC. Since we can't and we do not > want to embed yet-another-ioc-tool for low level stuff we would just > need to make aether's ServiceLocator entries customizable. It is > simple Map between role and implementation classes thus would not > require anything more than bundle.findEntries. This way we could also > solve pax-url troubles with wagon not loaded up properly. >
Won't that make things a bit more complicated for the karaf maven plugin ? It does not run in OSGi, so the fragment stuff won't work. If the problem is the compatibility, it may still be easier to put the code in pax-url-eather, and only have a flag to turn the version resolver into an OSGi compatible one, so that the default would be unchanged. I honestly don't mind, I'm just trying to find the best way to handle that. > @Guillaume, we don't need to handle RELEASE flag because this part is > not subject of version range resolution but VersionResolver. This is > piece of logic we would not (hopefully) need to amend. > > If you will take a look on my current implementation there is mixed logic: > https://github.com/splatch/maven-osgi-resolver/blob/ > master/compatible/src/main/java/org/code_house/maven/ > osgi/resolver/compatible/CompatibleOsgiVersionRangeResolver.java#L87 > https://github.com/splatch/maven-osgi-resolver/blob/ > master/strict/src/main/java/org/code_house/maven/osgi/resolver/strict/ > StrictOsgiVersionRangeResolver.java#L80 > > First implementation uses Maven ordering of versions meaning it > preffers releases over snapshots in selected range. Second > implementation behaves as OSGi, meaning it will ignore snapshot and > use regular qualifier comparision but more importantly it will also > accept just 3.4.0 as a range without upper bound. > > Best regards, > Lukasz > > 2017-02-01 9:44 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: > > Hi Lukasz, > > > > Thanks for your detailed e-mail and I fully agree with you. > > > > I guess the first step would be to improve the version range support in > > Maven URL, and after in the feature resolver. > > > > Correct ? > > > > Regards > > JB > > > > > > On 02/01/2017 02:05 AM, Łukasz Dywicki wrote: > >> > >> 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 > >> > > > > -- > > Jean-Baptiste Onofré > > [email protected] > > http://blog.nanthrax.net > > Talend - http://www.talend.com > -- ------------------------ Guillaume Nodet
