You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by rsteppac2 <ra...@steppacher.name> on 2014/10/12 12:57:36 UTC
Why import version range if exact version of dependency is known?
Hello,
the maven-bundle-plugin by default generates import statements for maven
dependencies with a version range like "[3.0,4)" for a project dependency
that is declared like this:
<dependency>
<groupId>my.group</groupId>
<artifactId>my-artifact</artifactId>
<version>${project.version}</version>
</dependency>
In this case the exact version (3.0.0.SNAPSHOT) of the dependency is known
and still the version range is used for the import.
I found other threads and JIRA tickets discussing the ordering of versions
with and without classifiers (SNAPSHOT or else) and what would be included
in a given version range and what not. But I have not found information as
to why the ranges are used in the first place if the exact version of a
package is known?
Could someone point me to a resource explaining this?
Also, the discussions mention that it is possible to declare the exact
version of an import. I know that I can do it on a package by package basis
in the <Import-Package> section of the plugin configuration.
Is there a configuration option that enables this globally where exact
versions are known?
Thanks!
Ralf
--
View this message in context: http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Why import version range if exact version of dependency is
known?
Posted by rsteppac2 <ra...@steppacher.name>.
Alejandro,
thank you for the pointer to the configuration of the consumer and producer
policies!
I will read up on deployment manifests and OSGi subsystems asap.
I think that Karaf features also help to solve my "problem" to a certain
extent.
Thanks again for your help!
Ralf
--
View this message in context: http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123p5010216.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Why import version range if exact version of dependency is known?
Posted by Al...@grassvalley.com.
I'm in an enterprise environment as well and I can tell you two more
thoughts that haven't been mentioned
1) Over here management has the same requirement of not accepting ranges
for lack of testing all the possible permutations, so the
solution/workaround (warning, it's pretty ugly and me personally i don't
agree with it since it defeats the purpose of osgi and substitutability,
but it solves the issue at hand) is to configure the maven-bundle-plugin
with a different versioning policy
<_consumer-policy>$(range;[====,====])</_consumer-policy>
<_provider-policy>$(range;[====,====])</_provider-policy>
This will make it so that ranges are always equal in its lower and
upperbound, i.e. an exact match
2) In the last OSGi devcon I learnt about OSGi subsystems and deployment
manifests. I haven't used them yet and there's not much documentation on
them from what I can see, but it allows you to freeze dependency versions,
and it seems it came from the exact same requirement you are enquiring
about (someone please correct me if I'm missunderstanding something about
their usecase)
http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websphere.osgi.nd.doc/ae/ra_dep_mf.html
or
http://www.slideshare.net/mfrancis/subsystems-for-those-occasions-where-bundles-are-just-too-small-graham-charters
(Check slide # 17)
You will need to check your OSGi version since I believe this is only
supported in OSGi Entreprise R5 and up
Let us know how it goes, I am trying to convince management to get rid of
the fixed versioning policy so others' success stories might help
Cheers,
Alejandro Endo | Software Designer/Concepteur de logiciels
From: rsteppac2 <ra...@steppacher.name>
To: <us...@felix.apache.org>,
Date: 2014-10-12 13:47
Subject: Re: Why import version range if exact version of
dependency is known?
Ferry,
thanks for the pointer. I was aware of the concept of semantic versioning,
not in the specific context of OSGi though. I read the paper on the OSGi
wiki. And I still maintain what I wrote above.
Example:
My Maven dependency is camel-core 2.13.2. Based on the imports of the code
this is converted into one or more package imports from that bundle, e.g.
'org.apache.camel;version="[2.13,3)",
org.apache.camel.impl;version="[2.13,3)"', etc.
I might have chosen the specific version 2.13.2 because it fixed a bug in
v.
2.13.1 that affects me . Or I might have downgraded from 2.14.0 because it
introduced a bug.
Now, across all environments (development, test, integration, production,
you name it) I have to ensure that my code always runs with that exact
version of the camel-core bundle. Which is not guaranteed by the version
range [2.13,3) that has been generated for me.
As for my own code. I have a multi-module maven project. All or some
modules
will be OSGi bundles. They all have the same release cycle. Which is why I
combined them in a multi-module project. So all modules are
integration-tested against each other. At the same version. Even though
version 3.0.0 of module A has a very high probability to work with version
3.0.1 of module B, it has never been tested that way. And therefor should
never be deployed in that combination. Again, if my imports are generated
as
[3.0,4), then there is no guarantee that this cannot happen by accident.
Might be my problem is that I don't see how to distinguish between the API
and its provider. The bundle "camel-core" is both, is it not? The same is
true for almost all 3rd party libraries I normally work with. Very few
separate the API from the provider in separate bundles.
Of course with my own code I could go the extra mile maintain separate
modules for the API and its provider.
Thanks for your help!
Ralf
--
View this message in context:
http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123p5010137.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.
Re: Why import version range if exact version of dependency is
known?
Posted by rsteppac2 <ra...@steppacher.name>.
Ferry,
thanks for the pointer. I was aware of the concept of semantic versioning,
not in the specific context of OSGi though. I read the paper on the OSGi
wiki. And I still maintain what I wrote above.
Example:
My Maven dependency is camel-core 2.13.2. Based on the imports of the code
this is converted into one or more package imports from that bundle, e.g.
'org.apache.camel;version="[2.13,3)",
org.apache.camel.impl;version="[2.13,3)"', etc.
I might have chosen the specific version 2.13.2 because it fixed a bug in v.
2.13.1 that affects me . Or I might have downgraded from 2.14.0 because it
introduced a bug.
Now, across all environments (development, test, integration, production,
you name it) I have to ensure that my code always runs with that exact
version of the camel-core bundle. Which is not guaranteed by the version
range [2.13,3) that has been generated for me.
As for my own code. I have a multi-module maven project. All or some modules
will be OSGi bundles. They all have the same release cycle. Which is why I
combined them in a multi-module project. So all modules are
integration-tested against each other. At the same version. Even though
version 3.0.0 of module A has a very high probability to work with version
3.0.1 of module B, it has never been tested that way. And therefor should
never be deployed in that combination. Again, if my imports are generated as
[3.0,4), then there is no guarantee that this cannot happen by accident.
Might be my problem is that I don't see how to distinguish between the API
and its provider. The bundle "camel-core" is both, is it not? The same is
true for almost all 3rd party libraries I normally work with. Very few
separate the API from the provider in separate bundles.
Of course with my own code I could go the extra mile maintain separate
modules for the API and its provider.
Thanks for your help!
Ralf
--
View this message in context: http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123p5010137.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Why import version range if exact version of dependency is known?
Posted by Ferry Huberts <ma...@hupie.com>.
On 12/10/14 15:15, rsteppac2 wrote:
> Neil,
>
> thank you for your input!
>
> First of all, you are right in that I don't have much OSGi experience in
> general. I understand your point about substitutable alternatives for a
> given API version.
> But in my experience, in an enterprise production environment, you don't
> want any of that dynamic behavior because it may lead to hard to debug
> application behavior if the versions of the implementations are not
> enforced.
> Anyway, I think I understood that this is against the grain of the OSGi
> paradigm and if I want it to be more strict, I have to deal with the more
> explicit configuration.
>
Do read up on semantic versioning if you're going to do OSGi.
It's such an integral part of OSGi that you can't do without.
Once you've read up, you'll see your own comments in a different light ;-)
Many of the OSGi devs come from 'enterprise' backgrounds. We know when
you're at, you just don't get where we're at. After reading up you'll
better understand that :-)
> Thanks!
> Ralf
>
>
>
> --
> View this message in context: http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123p5010129.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
--
Ferry Huberts
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Why import version range if exact version of dependency is
known?
Posted by rsteppac2 <ra...@steppacher.name>.
Neil,
thank you for your input!
First of all, you are right in that I don't have much OSGi experience in
general. I understand your point about substitutable alternatives for a
given API version.
But in my experience, in an enterprise production environment, you don't
want any of that dynamic behavior because it may lead to hard to debug
application behavior if the versions of the implementations are not
enforced.
Anyway, I think I understood that this is against the grain of the OSGi
paradigm and if I want it to be more strict, I have to deal with the more
explicit configuration.
Thanks!
Ralf
--
View this message in context: http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123p5010129.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Why import version range if exact version of dependency is
known?
Posted by Neil Bartlett <nj...@gmail.com>.
The OSGi Import-Package statement is resolved at runtime, whereas the Maven build dependencies are (obviously) resolved at build-time.
At runtime it’s bad to use exact versions, or even an excessively narrow version range, since you lose the ability to substitute alternatives, and you may be unable to communicate between two components/libraries that would otherwise be able to agree to use the same version of an API.
This is one of the biggest misconceptions for people coming to OSGi from build systems like Maven. Runtime dependencies are very different to build-time dependencies. The best practices for building projects — e.g. making your build repeatable and reproducible even far into the future by locking down versions exactly — are not best practices at all when it comes to the runtime environment.
Regards,
Neil
On 12 October 2014 at 11:58:03, rsteppac2 (ralf@steppacher.name) wrote:
Hello,
the maven-bundle-plugin by default generates import statements for maven
dependencies with a version range like "[3.0,4)" for a project dependency
that is declared like this:
<dependency>
<groupId>my.group</groupId>
<artifactId>my-artifact</artifactId>
<version>${project.version}</version>
</dependency>
In this case the exact version (3.0.0.SNAPSHOT) of the dependency is known
and still the version range is used for the import.
I found other threads and JIRA tickets discussing the ordering of versions
with and without classifiers (SNAPSHOT or else) and what would be included
in a given version range and what not. But I have not found information as
to why the ranges are used in the first place if the exact version of a
package is known?
Could someone point me to a resource explaining this?
Also, the discussions mention that it is possible to declare the exact
version of an import. I know that I can do it on a package by package basis
in the <Import-Package> section of the plugin configuration.
Is there a configuration option that enables this globally where exact
versions are known?
Thanks!
Ralf
--
View this message in context: http://apache-felix.18485.x6.nabble.com/Why-import-version-range-if-exact-version-of-dependency-is-known-tp5010123.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org