Hi David,

can you share what you set in resourceRepositories ?

Thanks,
Regards
JB

On 11/19/2015 10:15 AM, David Leangen wrote:

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
<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]
<mailto:[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]
<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

    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]>> 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]>> 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]>>:


       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]>> 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] <mailto:[email protected]>
    http://blog.nanthrax.net <http://blog.nanthrax.net/>
    Talend -http://www.talend.com <http://www.talend.com/>




--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com

Reply via email to