It sounds good.
On Wed, Oct 20, 2010 at 10:18 AM, Jean-Baptiste Onofré<[email protected]
wrote:
Hi Guillaume
+1 to support dependency on features range.
Anyway, the dependency resolution is already performed by the bundle (if
it
uses Import-Package statement with a version range, for instance, in your
exemple org.apache.commons.lang;version="[2.4,2.5)").
I guess that we need to "construct" the URL compatible with PAX URL
before
delegating to PAX. The bundle will be added in the OBR repositories
(locally
to Karaf) with a "dependency" flag.
The question is how to upgrade the descriptor repository to work like
this.
I propose:
1/ the bundle version could be optional as:
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang</bundle>
In that case, Karaf will looking for the OBR to get an existing
commons-lang bundle. It fails if the bundle is not present in the OBR
2/ define a bundle version range as
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/[2.4,2.5)</bundle>
In that case, Karaf will looking for the OBR to get the first bundle
matching the version range.
3/ define the bundle version is still supported (to be backward
compatible).
What do you think ?
Regards
JB
On 10/20/2010 01:02 AM, Guillaume Nodet wrote:
I think I have a solution to partially solve the problem. Of the main
interest in OBR imho is that it knows what is installed in the framework
already, so it can be used to avoid duplicating libraries in different
versions that are not needed (if you need spring-core 3.0.3 but
spring-core
3.0.4 is installed, there's no need to install both usually).
The problem is that the use of OBR usually require OBR repositories. I
think I can get rid of that by creating a dummy OBR repository from the
features descriptors and flagging some bundles in the features
descriptor
as
optional (or dependencies).
For example, in the current descriptor repoitory we have:
<feature name="jasypt-encryption" version="2.1.99-SNAPSHOT">
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/1.3_3</bundle>
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-lang/2.4_4</bundle>
<bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.jasypt/1.6_1</bundle>
<bundle>mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT</bundle>
</feature>
But really, the key bundle here is
the
mvn:org.apache.karaf.jaas/org.apache.karaf.jaas.jasypt/2.1.99-SNAPSHOT
one, whereas the three others are just dependency whith versions that
could
be changed (provided they are still in the required range). This would
mean
that if commons-lang-2.5 has already been installed through another
feature,
there's no need to install another version of it.
In addition, I think supporting dependency on feature ranges would be
really
important as it would help greatly when depending on spring 2.x or 3.x
for
example.
On Mon, Jul 5, 2010 at 09:29, Guillaume Nodet<[email protected]> wrote:
That could be a good way. I haven't experimented that really, but I
think it would at least give the freedom to the resolver to reuse
locally installed bundles, so that's obviously a really good start.
As for OBR itself, I've added to the maven bundle plugin a goal that
can be used to build an obr repository out of a maven repository in a
directory. This goal can also generated maven urls instead of the
file:// urls that it would give. Thus giving an additional
indirection in the url instead of pointing directly to the http
location.
I think from a production pov, what would be needed is some kind of
maven repository (nexus or archiva) coupled with an OBR repository.
This way, the deployer would be responsibe for adding authorized
artifacts in the repository and that would automatically update an obr
repository descriptor with the added artifacts.
The problem is that this way of seeing the problem does not work well
in a non controlled environment such as most users do when they allow
access to maven central ... So in that case, your approach of using
the maven dependencies could be a good solution.
On Fri, Jul 2, 2010 at 18:34, David Jencks<[email protected]>
wrote:
On Jul 2, 2010, at 8:03 AM, Guillaume Nodet wrote:
I've just added support for pluggable resolvers for features.
I've also created an OBR based resolver that is installed with the
obr
feature.
Now you can do the following:
<feature name="xx" version="yy" resolver="obr">
<bundle>bundle:(&(symbolicname=org.apache.camel.camel-blueprint)(version>=2.4.0)(version<2.4.1))</bundle>
</feature>
If OBR has been configured with the needed repositories, it will
install camel-blueprint bundle with all the required dependencies.
The benefit is that you don't have to specify all the dependencies,
but only the key bundles. The added benefit is that the deployment
will leverage what is already installed and you don't have to
maintain
an homogeneous set of repositories (for example, you should not have
to specify which version of spring you want to use and obr will reuse
the one installed if possible, or choose which one to install based
on
the constraints expressed by the bundles).
I haven't updated the feature descriptor yet, mostly because we don't
have a obr repository which contain all the bundles we need.
I have one locally that contain all the bundles present on maven
central, but it's a bit too big to be used in this context, so not
sure how to handle that yet.
Anyway, just wanted to give a heads up on that.
One of the points of friction I see between maven and osgi is that in
maven you explicitly specify which artifacts supply your needed
dependencies whereas in osgi they magically appear from something like
OBR.
I've always wondered where the OBR-like info is supposed to come from.
On
the other hand, if you are using maven to build, you have a reasonable
set
of candidate artifacts in the maven dependencies (assuming they are all
bundles).
Something I started experimenting with in geronimo is to, for each
feature, construct an OBR xml file out of the maven dependencies. Just
before you try to install the feature, you add the obr fragment to the
OBR
instance you are using for resolving the feature. This pretty much
assures
that something that will enable the bundles in the features to resolve
will
be available.
Writing the code for this was easy, but we weren't relying enough on
OBR
at the time to find out how well it works in practice. I have been
wondering if anyone else would think this is a reasonable approach to
investigate.
thanks
david jencks
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
*Ioannis Canellos*
http://iocanel.blogspot.com
Integration Engineer @ Upstream S.A.<http://www.upstreamsystems.com>
