Maybe it could be a standard "enRoute" repository that we can provide as
<resources-repository/> or global resource repository ?
WDYT ?
Regards
JB
On 12/02/2015 10:49 AM, Guillaume Nodet wrote:
2015-12-02 7:06 GMT+01:00 dleangen <apa...@leangen.net
<mailto:apa...@leangen.net>>:
Hi,
Guillaume Nodet-2 wrote
>>>Anyway, once I'm given a repository and a set of bundles to look at, i'm
willing to look at it.
dleangen wrote
>>Cool! Thank you very much!
>>
>>I will work on that as soon as I can. :-)
I have created a sample bndtools (enRoute) workspace on github:
https://github.com/dleangen/org.apache.karaf.demos.enroute
Although quite simplistic, hopefully it is representative of what
happens in
a typical enRoute workspace. The workspace gets released as a unit
in the
form of an OBR. To me, this “unit” is clearly homologous to a Karaf
Feature,
or at least very synergetic. The objective is in fact to take the
released
OBR, which is plain and simple OSGi, and transform it into a Feature
on the
fly.
The “driver” or “application” bundle is
org.apache.karaf.demos.enroute.application. The EnrouteApplication class
pulls in all the required dependencies. The mechanism is to annotate the
class, and bndtools uses the information in the annotations to write the
requirements in the manifest. All Karaf would need to do is wrap this
bundle, and in theory all the requirements (if available) should get
resolved.
I’m still grappling a bit with what to do about configurations with
regards
to features, but FYI I also included a simple configuration in the
"enRoute
Way” as well. You can see this in the “unrelated” bundle, which also
happens
to get pulled into the “application”. (I am not advocating that this
_should_ be the right or only way to pull in a dependency or a
configuration, just showing that it _can_ be done, and is very easy
to do.)
Once the code was ready, I performed a “release”, which creates an
OBR. This
is saved in the cnf/release directory, which I also committed to the
same
project in github. If you look at the index.xml file, you will
notice that
the application bundle indeed provides the following capability:
<capability namespace="karaf.identity">
<attribute name="description" value="Demo to show how to
deploy an
enRoute application with Karaf"/>
<attribute name="karaf.identity" value="enroute-demo"/>
<attribute name="type" value="karaf.feature"/>
<attribute name="version" type="Version" value="1.0.0"/>
</capability>
As you can probably imagine, it would be very easy to write a parser
to scan
for this “feature” and create one in runtime. In fact, I already
created a
parser (was very easy to do indeed), but got blocked because
currently Karaf
won’t let me use this info to create a Feature in runtime, as it
expects an
xml file instead.
So i've just experimented a bit with this repository.
I've added the following repository to karaf which could easily be
generated.
<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0";
name="enroute-demo">
<resource-repository>file:///Users/gnodet/work/tmp/org.apache.karaf.demos.enroute/cnf/release/index.xml</resource-repository>
<feature name="enroute-demo">
<requirement>karaf.identity;filter:="(&(karaf.identity=enroute-demo)(type=karaf.feature))"</requirement>
</feature>
</features>
After having fixed a few problems in Karaf, I was at a point where I
couldn't deploy the feature, because the above feature is not
transitively closed. It requires 2 extenders (osgi.component
and osgi.enroute.configurer), but those are not provided in the xml.
I suppose the information is somewhat given from the list below:
https://github.com/dleangen/org.apache.karaf.demos.enroute/blob/master/org.apache.karaf.demos.enroute.application/org.apache.karaf.demos.enroute.bndrun#L11-L22
But those informations should appear somewhere, else you can't figure
what to deploy in order to solve those requirements.
Anyway, I've removed the enrolee extender requirement from the xml,
deployed scr, and finally got the application deployed (but the bundle
application which can not be resolved at runtime because of the missing
extender).
My main worry now is about those un satisfied requirements.
If the generated xml repository only contains the bundles that you are
writing, we need a way to give a list of bundles that will actually
solve the requirements that are not satisfied by the generated bundles
(such as the 2 extenders above), but it could be different requirements
on packages, services, etc...
Barring any suggested improvements, then, it seems to me that the only
things to decide on to make this nice process work are:
1. Whether or not the namespace etc. should be standardised in Karaf
2. If so, what this standardisation should be, and create a
corresponding
parser
3. How to get a feature working in runtime without requiring the
use of a
features.xml file
Please let me know if I can provide any more information. Hopefully this
gives a better idea of what could be done. :-)
Cheers,
=David
--
View this message in context:
http://karaf.922171.n3.nabble.com/Bndtools-Karaf-the-right-way-tp4043765p4043974.html
Sent from the Karaf - User mailing list archive at Nabble.com.
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
