I agree: if the "application" is exhaustive in term of requirements, and
you define the resourcesRepositories, it should work.
Regards
JB
On 11/30/2015 11:51 AM, Guillaume Nodet wrote:
My understanding is that, as I explained in my earlier mail,
you don't need features at all.
If you have an "application bundle" and the xml repository, that should
be enough, you don't have to wrap them.
Could you please raise a JIRA and attach the artefacts needed to
"reproduce" the use case ? I.e. maybe a zip containing the xml
repository and the bundles, including the application bundle.
I'll investigate to make sure you can deploy it easily.
2015-11-30 11:39 GMT+01:00 David Leangen <apa...@leangen.net
<mailto:apa...@leangen.net>>:
Hi,
Wow! This list is really active. :-D
I think Christian explains it quite well. Allow me to add in more
concrete, low-level details to complement this explanation.
First of all, I have a “bootstrapping" bundle, with no dependencies
on any of my other bundles, but some dependencies on, for example,
Karaf. This bundle handles the deployment functions described below.
This bundle is set up as a boot feature in Karaf. Along with the
things being discussed below, it will allow me to accomplish my
objective.
In my development environment, I have several bndtools workspaces in
Eclipse. I believe this is quite typical in a bndtools environment.
Each workspace usually (but not always) has an “application bundle”,
whose purpose is to pull in all the requirements for the
“application” (what is, I believe, essentially homologous to a Karaf
feature, minus the configuration).
In my enRoute application bundles, I created a KarafFeature
annotation like this:
@ProvideCapability(
ns = "karaf.identity",
value = "type=karaf.feature"
)
@Retention(RetentionPolicy.CLASS)
public@interfaceKarafFeature
{
String name();
String description();
String version();
}
Used on my “application service” class:
@RequireTestFoo
@RequireTestBar
@KarafFeature(
name = “feature-name",
description = “Short description of feature",
version = “1.0.0"
)
public class TestInstallation
{
}
The capability output via bnd to the Manifest:
Provide-Capability: karaf.identity;description=“Short description
of
feature";version:Version=“1.0.0";karaf.identity=feature-name;type="karaf.feature"
[**Note:
The requirement for a feature is already formalized in karaf:
osgi.identity;osgi.identity=feature-name;type=karaf.feature;version="version-range"
I tried this, but apparently bnd does not like it, so in my
implementation I changed it from “osgi.identity” to
“karaf.identity”. I don’t know if this is a bug in bnd, or if Karaf
is using osgi.identity for something it should not. :-) ]
bnd provides a “release” function, which creates an OBR with all the
bundles from the workspace. This can be done via Eclipse or as a
headless build from gradle. Thus, for each workspace, on the CI
server, when a build is successful, the result is an OBR repo as the
output.
I currently use Bamboo for our CI server. It has a “deployment”
function, which we use to push the released OBR repos to a
repository server. The developer’s job ends here, as this is also
the handoff point to the deployer. I believe that the roles should
be separated. From a business perspective, if we required that a
deployer has the same level of expertise as a developer, things
would be very expensive. ;-)
In crappy ASCII art, it would be:
+-----+ +--------+
| Dev |——>[OBR Repos]<——| Deploy |
+-----+ +--------+
Once in Karaf, since I want to have a local cache of my OBR
repositories in order to completely decouple the runtime system from
any development or deployment system, I (programmatically) have Cave
populate corresponding local caches. So my deployment bundle will
first obtain and cache the OBR repositories (one for each bnd
workspace) and cache it locally via Cave.
The deployer, when initiating a deployment, will therefore pull the
released OBR repos via Cave. I then parse the respository.xml file
to find any capabilities in the karaf.identity namespace, and pull
in any information I need to create a Karaf feature on the fly.
(Probably you can imagine this, but I can show you the fairly
trivial code if necessary.)
I have an XML parser that will extract the information necessary to
generate the Karaf feature from the capabilities in the application
bundle in each Repo. However, if I could input either the bundle or
the repo and let Karaf extract the feature information, that would
be even better.
Based on the above, I could easily create Karaf commands to allow
the deployer to pull in the latest versions (deployed as OBR repos)
and deploy as necessary as features, which would be generated on the
fly from the included capabilities.
I believe that this would be a very nice, easy, and natural way to
“integrate” an eRoute (bnd) development environment with the Karaf
runtime. Developers continue to work as usual, in theory without
having to worry about which runtime is being used, while the
deployer can do her job very easily from start to finish from the
Karaf command line without having to stop the system, change
configuration, or even call on developers (unless something blows up).
Please let me know if I can provide any further info. :-)
Cheers,
=David
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
