nothing to add, i like it :) kind regards
On Wed, Oct 20, 2010 at 04:28:21PM +0200, Guillaume Nodet wrote: > Ok, so i've raise KARAF-251 and KARAF-252 and committed some patches, but > i'd like to discuss those before closing the jiras. > > So, KARAF-251 is about using range on features. > I've modified the parser and installation service to allow using ranges when > specifying a dependency on a feature. > I've also modified the karaf feature descriptor to leverage that by adding a > spring2 feature: > > <feature name="spring" version="2.5.6.SEC01"> > <bundle > dependency='true'>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aopalliance/1.0_4</bundle> > <bundle>mvn:org.springframework/spring-core/2.5.6.SEC01</bundle> > <bundle>mvn:org.springframework/spring-beans/2.5.6.SEC01</bundle> > <bundle>mvn:org.springframework/spring-aop/2.5.6.SEC01</bundle> > <bundle>mvn:org.springframework/spring-context/2.5.6.SEC01</bundle> > > <bundle>mvn:org.springframework/spring-context-support/2.5.6.SEC01</bundle> > </feature> > <feature name="spring" version="3.0.3.RELEASE"> > <bundle > dependency='true'>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aopalliance/1.0_4</bundle> > <bundle>mvn:org.springframework/spring-core/3.0.3.RELEASE</bundle> > <bundle>mvn:org.springframework/spring-asm/3.0.3.RELEASE</bundle> > > <bundle>mvn:org.springframework/spring-expression/3.0.3.RELEASE</bundle> > <bundle>mvn:org.springframework/spring-beans/3.0.3.RELEASE</bundle> > <bundle>mvn:org.springframework/spring-aop/3.0.3.RELEASE</bundle> > > <bundle>mvn:org.springframework/spring-context/3.0.3.RELEASE</bundle> > > <bundle>mvn:org.springframework/spring-context-support/3.0.3.RELEASE</bundle> > </feature> > <feature name="spring-dm" version="1.2.0"> > <feature version="[2.5.6,4)">spring</feature> > > > <bundle>mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.cglib/2.1_3_6</bundle> > <bundle>mvn:org.springframework.osgi/spring-osgi-io/1.2.0</bundle> > <bundle>mvn:org.springframework.osgi/spring-osgi-core/1.2.0</bundle> > > <bundle>mvn:org.springframework.osgi/spring-osgi-extender/1.2.0</bundle> > > <bundle>mvn:org.springframework.osgi/spring-osgi-annotation/1.2.0</bundle> > > > <bundle>mvn:org.apache.karaf.deployer/org.apache.karaf.deployer.spring/2.1.99-SNAPSHOT</bundle> > </feature> > > When installing a feature, the dependant features are installed as > following: > * if no version is indicated, it means [0, +oo) > * if a version is indicated, the range is closed [x, x] > * if a feature matching the range is already installed, use that one > * else find the highest version matching the range > > So if you 'features:install spring-dm' it will install spring 3.0.3 by > default. If you want to install the 2.5 version, you need to > 'features:install spring 2.5.6' and then 'features:install spring-dm'. > > The second improvement, KARAF-252 is about leveraging OBR to avoid > installing duplicate dependencies while not forcing the user into using and > maintaining OBR repositories. It can now be done by flagging dependencies > with a dependency='true' flag and resolver="(obr)". Note the parentheses > that mean the obr resolver is optional (so it will default to the previous > behavior if obr isn't installed and in that case will install all the listed > bundles). If obr resolver is present, the feature will be transitively > resolved by creating an obr repository containing all the listed bundles and > resolving only the bundles marked as not 'dependency'. So in the example > above, the aopalliance bundle is marked as a dependency, so that if another > aopalliance bundle satisfying the constraint (imported packages, etc...) is > already installed, it won't be installed. > > Thoughts? > > > On Wed, Oct 20, 2010 at 12:17, Guillaume Nodet <[email protected]> wrote: > > > 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 > > > > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
pgpqx8q4heldT.pgp
Description: PGP signature
