The shell core headers don't import blueprint, and the shell feature
doesn't depend to the blueprint feature.
What you see comes from the shell-compat feature which brings the "old"
blueprint command extender (you are right, for backward compatibility,
this feature is installed by default in the Karaf standard distribution).
What I meant is that if you remove the aries-blueprint and shell-compat
features, Karaf is still running without these dependencies.
Regards
JB
On 03/18/2016 07:24 PM, Milen Dyankov wrote:
This is what I mean:
karaf@root()> bundle:info 44
Apache Karaf :: Shell :: Core (44)
...
karaf@root()> bundle:requirements 44 | grep blueprint
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.apache.aries.blueprint 1.5.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.apache.aries.blueprint.mutable)(version>=1.2.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.apache.aries.blueprint.mutable 1.2.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.osgi.service.blueprint 1.0.0 from
org.apache.aries.blueprint.core [13]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint.container)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.osgi.service.blueprint.container 1.0.1 from
org.apache.aries.blueprint.api [11]
osgi.wiring.package;
(&(osgi.wiring.package=org.osgi.service.blueprint.reflect)(version>=1.0.0)(!(version>=2.0.0)))
resolved by:
osgi.wiring.package; org.osgi.service.blueprint.reflect 1.0.1 from
org.apache.aries.blueprint.api [11]
On Fri, Mar 18, 2016 at 7:20 PM, Jean-Baptiste Onofré <[email protected]>
wrote:
Hi Milen,
Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint
(blueprint is not defined as a <dependency/> and so not in the manifest,
even for the command extender).
Regards
JB
On 03/18/2016 07:14 PM, Milen Dyankov wrote:
I personally think DS is pretty much what OSGi Alliance is going to
promote
(together with the enRoute project) and from that perspective if any
component framework's user base is going to grow that would be DS. But if
you guys want to still do it the "hard way" that's fine too. It just means
less people will be able to contribute.
As for things that can not be done with DS, I don't think Christian meant
to say everything must be rewritten! If something needs to be done
differently (activators/tackers/...) than it can/should be. It's not all
or
nothing scenario IMHO.
Finally about Blueprint. I keep reading in posts that Karaf got rid of
Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" still
depends on Blueprint. So when you say "the bundles in Karaf are
independent"
what exactly do you mean?
Best,
Milen
On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet <[email protected]>
wrote:
I agree with Achim and Lukasz.
Here are the advantages of the current solution:
1/ No additional dependency. One thing that I really care about is that
the bundles in Karaf are independent. I.e. they do not rely on an
extender. The benefit is that you can upgrade the bundles independently
and you don't have an additional bundle which cause all the bundles to be
refreshed / restarted.
2/ Very lightweight. The current framework only consist in 3 classes :
BaseActivator, SingleServiceTracker,
SingleServiceTracker$SingleServiceListener.
Even the annotations are not included at runtime.
3/ Very fast. No xml parsing, no reflection. Just the
OSGI-INF/karaf-tracker/ property file which is loaded by the activator.
So
it's really fast at startup.
4/ Very robust. Quite the contrary to what you say, I think this very
small
framework is way more robust than blueprint or DS. I spent quite some
time
load-testing karaf 4 before the release, using the bundle:load-test
command.
5/ DS exclusively uses the OSGi registry for wiring. There's no notion
of
"internal" wiring, everything is exposed. So by default, the
capabilities
/ requirements contain much more than what is needed, with the additional
semantical change where the bundle could be wired to components coming
from
different bundles (check the bundle manifest in your branch).
So yes, the main drawback are : limited scope and not documented, but
given
is has never been written to be used outside karaf, I don't see those as
real problems. If the concern is users, I'm all for advertising the use
of DS or Blueprint for our users, I don't think they should use our
internal framework which is much more low level.
2016-03-17 16:43 GMT+01:00 Christian Schneider <[email protected]
:
We currently use some custom Activator base classes to wire the karaf
bundles. The goal of this was to avoid depending on blueprint
as it is a quite heavy dependency and makes it harder to use a different
blueprint impl or version.
There are some problems with this approach though:
- It makes it harder for new people to understand what we are doing
- The custom code is more error prone than a proven framework
So I propose to switch our own bundles to use DS to expose and wire
services.
There are some advantages:
- The DS annotation approach is easier to understand and more self
documenting than the custom code
- We get rid of the classes in util for the custom code
- The scr commands help diagnose problems
The main cost is that we need to always install the felix scr bundle.
To prove that it can work I switched bundle core in a branch
https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
The DS based code works quite nicely.
Btw. I found a small problem with our shell command extender. It only
seems to work on all commands or none. If there is any required service
missing then none of the commands is installed.
This made it hard for me to diagnose problems as I was missing all
bundle
commands ;-)
So while working on the switch I thought about two improvements to the
extender:
1. Work on each command individually. So each command can activate as
soon
as the deps are met
2. Provide a service and commands to diagnose problems like the scr
commands
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration
Email: [email protected]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
