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