Thanks, Guillaume! I updated the config as you suggested:
---------------------------------------------------------------- Pid: org.apache.karaf.features BundleLocation: null Properties: featuresBoot = aries-blueprint, bundle, config, deployer, diagnostic, feature, instance, jaas, kar, log, management, package, service, shell, shell-compat, ssh, system, wrap featuresBootAsynchronous = false featuresRepositories = mvn:org.apache.karaf.features/enterprise/4.0.3/xml/features, mvn:org.apache.karaf.features/framework/4.0.3/xml/features, mvn:org.apache.karaf.features/spring/4.0.3/xml/features, mvn:org.apache.karaf.features/standard/4.0.3/xml/features felix.fileinstall.filename = file:/usr/share/apache-karaf-4.0.3/etc/org.apache.karaf.features.cfg resourceRepositories = xml:http://my.reop.com/path/to/repo/index.xml service.pid = org.apache.karaf.features ---------------------------------------------------------------- Unfortunately, Karaf still does not “see” the provided bundles that resolve the requirements. (I also tried with resourcesRepositores, i.e. with the “s”.) I suppose I’ll have to look into trying it programmatically as you suggest. BTW, if I add a repo to my config this way, should it show up here? karaf@root()> repositories Name | Location --------------- Or is the Cave OBR somehow disconnected? The above returns empty. Would be nice to see what is in the cache. When I (re)install my feature, the old bundle keeps showing up (I suppose because it is resolvable). Cheers, =David > On Nov 19, 2015, at 5:50 PM, Guillaume Nodet <[email protected]> wrote: > > You should investigate using the FeaturesService programmatically if you need. > You can ask the resolver to add requirements using > featuresService.addRequirements(...) > You should be able to configure to point to xml repositories. > The syntax is: > resourceRepositories= [xml:url | json:url]... > So in your example, try with: > resourceRepositories=xml:http://my.repo.com/path/to/repo/index.xml > <http://my.repo.com/path/to/repo/index.xml> > > Guillaume > > 2015-11-19 9:41 GMT+01:00 David Leangen <[email protected] > <mailto:[email protected]>>: > > Hi JB, > > Thanks again for your help. My bundle requirements are still not getting > resolved, though. :-( > > I added this to my etc/org.apache.karaf.features.cfg file: > > resourcesRepositories = \ > http://my.repo.com/path/to/repo/index.xml > <http://my.repo.com/path/to/repo/index.xml> > > But unfortunately, Karaf still does not “see” anything provided by this repo. > > In OBR, I can only add a single jar at a time, not an entire repo index. Even > in the code, I noticed that cave only accepts files of type: > > application/java-archive > application/octet-stream > application/vnd.osgi.bundle > > Anything other than those files types gets ignored. > > As a side note: to make my bundles work, I needed to add to the code this > mime type: > application/x-java-archive > > I could find out that is a registered mime type, though I do not know the > history as to where there is both application/java-archive and > application/x-java-archive. > > Cheers, > =David > > > >> On Nov 19, 2015, at 2:40 PM, Jean-Baptiste Onofré <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi David, >> >> Karaf FeatureService uses capabilities/requirements provided by the >> registered features and bundles. >> You can also plug a OBR repository (directly the repository.xml or via Cave) >> using resourcesRepositories in etc/org.apache.karaf.features.cfg. >> >> In that case, the FeatureService will use the capabilities/requirements from >> the repositories. >> >> We discussed with Christian to improve the repository/resources by >> implicitly loading repository.xml per artifacts (instead of a "global/big" >> repository.xml). >> >> Regards >> JB >> >> On 11/18/2015 11:59 PM, David Leangen wrote: >>> >>> Or another, maybe better way, is to figure out how to create a feature >>> by designating the “application bundle”, and letting the >>> requirements/capabilities pull in everything else. >>> >>> enRoute very nicely allows me to create indexed OBR repositories. The >>> “application bundle” provides the ability, based on the declared >>> requirements, to pull in everything needed from the indexed repositories. >>> >>> Everything is there, it’s just creating the features.xml file that is my >>> problem. :-) >>> >>> >>> Cheers, >>> =David >>> >>> >>> On Nov 19, 2015, at 7:27 AM, David Leangen <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>> >>>> >>>> Hi, >>>> >>>> Thanks for the tip. Somehow I always overlook the Enterprise specs… >>>> >>>> I think you are right, Karaf Features are more what I want. My only >>>> problem is that I am using enRoute (and therefore gradle), and there >>>> does not seem to be any plug-in to create a Karaf Feature. To create >>>> one myself, I am discovering, will require me to really get into the >>>> details. My problem is time; if I had more time, I would be happy to >>>> do this. Since I don’t, I am looking for something “easy”. >>>> >>>> Can you suggest a way (other than the maven plugin) that I can >>>> (non-manually) create a features file from enRoute / gradle? >>>> >>>> >>>> Cheers, >>>> =David >>>> >>>> >>>> On Nov 19, 2015, at 5:51 AM, Achim Nierbeck <[email protected] >>>> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> if you are looking for a "standard" approach might want to look in to >>>>> the ESA and Subsystem specs. >>>>> Subsystems is the "standardized" way of deploying applications, >>>>> though we worked on features quite long >>>>> and regard it to be superior, because simplere though more effective. >>>>> ESA reminds me to much of an EAR like packaging, >>>>> but that's my 2 cents. >>>>> >>>>> regards, Achim >>>>> >>>>> 2015-11-18 19:28 GMT+01:00 David Leangen <[email protected] >>>>> <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>>>: >>>>> >>>>> >>>>> Hmmm, I probably should have read further than the introduction. :-) >>>>> >>>>> Seems that the “no-sharing” principle in this spec is very >>>>> strict. I can see the advantage of features, assuming that >>>>> features does not follow this “no-sharing” approach. >>>>> >>>>> Guess I’ll have to continue my quest. >>>>> >>>>> Cheers, >>>>> =David >>>>> >>>>> >>>>> >>>>> > On Nov 19, 2015, at 2:58 AM, David Leangen <[email protected] >>>>> <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>>> wrote: >>>>> > >>>>> > >>>>> > Hi! >>>>> > >>>>> > Still on my quest to figure out how to deploy my apps on Karaf >>>>> (without having to write features.xml files manually). I have >>>>> been looking at the Resolver Spec, but that seems to be more >>>>> low-level than I’d like. Looks like it is intended more for tool >>>>> and framework developers. >>>>> > >>>>> > I did come across Deployment Admin, which seems more promising. >>>>> > >>>>> > One question: It seems that Deployment Admin is not available >>>>> by default on Karaf. What is the reason to favour the >>>>> non-standard feature approach over Deployment Admin? >>>>> > >>>>> > >>>>> > Cheers, >>>>> > =David >>>>> > >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Apache Member >>>>> Apache Karaf <http://karaf.apache.org/ <http://karaf.apache.org/>> >>>>> Committer & PMC >>>>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/ >>>>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>> >>>>> Committer & Project Lead >>>>> blog <http://notizblog.nierbeck.de/ <http://notizblog.nierbeck.de/>> >>>>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS >>>>> <http://bit.ly/1ps9rkS>> >>>>> >>>>> Software Architect / Project Manager / Scrum Master >>>>> >>>> >>> >> >> -- >> Jean-Baptiste Onofré >> [email protected] <mailto:[email protected]> >> http://blog.nanthrax.net <http://blog.nanthrax.net/> >> Talend - http://www.talend.com <http://www.talend.com/> >
