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/>
