What I like about this is the *minimal* part. I've built rpm and deb
packages one could use to easily install karaf on linux with yum or
apt-get (still a bit of work left to be fully workable). It has less to
do with the OSGi functionality and more with deployment and operation
related aspects. Once you have the container up and running the rest can
be installed directly from karaf. The impact @dkulp mentioned is
certainly there, but I would prefer it to be addressed in a different
way than making the minimal less minimal.
From the peanut gallery,
Hadrian
On 12/05/2013 11:36 AM, Ioannis Canellos wrote:
Well, when I started that POC, I wasn't targeting any future release
of Karaf, as I was not sure if people will like it anyway.
I don't want to stall Karaf 3.0.0, that's true. But if we can prepare
the ground and finally add this in a Karaf 3.x (as Dan suggested) it
would be a HUGE win for everyone. Mostly, because we will be able to
ship it without rushing a Karaf 4.x which would mean extra overhead in
maintaining multiple major version (especially when we can hardly
managed 2.x and 3.x).
@Achim: The original idea was to replace blueprint with scr and make
blueprint optional for all distros (not installed by default, but
being available as an option just like spring). The benefits:
i) A better tool for the job.
ii) Smaller footprint.
iii) Freedom for the user to use the impl and version of blueprint of
his choice.
@Johan: By no means I'd like to limit the users options. But that
doesn't mean that we should use the same things that the users will
do. The users are building apps and they can pick the most fitting
tool and we on the other hand are building a runtime and we need to
pick the best tool for our job. It doesn't have to be the same tool.
