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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
