I was mostly thinking about versioning at the feature dependency level. The mvn url already supports range, so i don't think we need to do anything here. Afaik, you can already write:
mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-codec/[1.3_3,2) I'll post a bit more later today or tomorrow. On Wed, Oct 20, 2010 at 09:32, Ioannis Canellos <[email protected]> wrote: > 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> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
