Note that the features service does not automatically react to configuration changes, so you need to restart the bundle (or karaf). If there's a problem during the loading of the repository, you should somehow see a warning in the log.
2015-11-19 10:15 GMT+01:00 David Leangen <[email protected]>: > > 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 > > Guillaume > > 2015-11-19 9:41 GMT+01:00 David Leangen <[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 >> >> 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]> >> 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] <[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] <[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] <[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] <[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/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >> Committer & Project Lead >> blog <http://notizblog.nierbeck.de/> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master >> >> >> >> >> -- >> Jean-Baptiste Onofré >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> > >
