Hi
after reading this thread about two times, I finally understood the
intention and the confusion in the thread.
Let me try to summarize this to start some more confusion :-D
Initial Problem:
- learning OSGi has a steep learning curve
- initial setup for a new OSGi project needs a lot of infrastructural
"thingis"
- doing the "microservice" dance is hard as it requires to much
"extras"
to
have a simple REST service
-- including infrastructure
- Spring boot brings everything needed in one place in one
"application"
with just annotations
These are the "problems" we know of and if I did get it right are the
intention for the Karaf-Boot project.
Now let me try to summarize the idea on how to solve that.
From a simple Class file with some annotation generate
- a OSGi service, including OSGi wiring via Blueprint - via an
extra maven
plugin
- get rid of all those infrastructural "add-ons" for the first OSGi
bundle
by having a easy to use Parent-POM
- do the microservice - dance by wrapping everything together
including
CXF
in a "one-size-fits-all" executable jar, which is a
wonna-be-spring-boot
jar but made of karaf
Now some thoughts of mine ...
I somehow fear you try to mix several problems and try to solve all of
them
with one go.
Let's try to analyze those initial problems separately and we might
find a
valid approach.
Learning curve of OSGi:
right now we have different approaches to make it easier with OSGi.
- Blueprint
- DS
- CDI
- iPojo
- Felix DependencyManager
Blueprint just tastes to much like spring xml and actually isn't
state of
the art anymore. You'll get a lot of negative feedback regarding the
"old-school" xml. It's biggest plus is the Enterprise "features"
like JPA
and JTA, which isn't covered by any other technique right now
(unless you
look at non Apache Hosted OSS projects like Amdatu).
Declarative Services, especially the latest R6 looks rather promising,
especially in conjunction with MetaType. But we have specialized
annotations which again don't actually help with the learning curve.
Another downside is the missing JPA and JTA Enterprise features.
CDI, we have the Pax-CDI project which has been on the way of being
the
reference implementation of the OSGi-CDI spec. Well, we all know
how that
turned out. One of its biggest benefits is definitely the easy
transition
because of the CDI annotation which help a lot with wiring inside a
bundle
and also with extra annotations (@OsgiService) with OSGi-Services. CDI
though still lacks runtime OSGi annotation support for JPA and JTA
if we
are somehow capable to compensate that, we'll have the required EE
stack
at
hand.
iPojo ... sorry never used
Dependency Manager is a bit more low-level compared to DS but seems to
have
a nice DSL for easy wiring of Services.
So do we really need another Build-Time-Annotation which generates
another
"wiring" plan which is used during runtime (exactly what DS already
does)?
Right now I'm not convinced of this. Instead of another generation
I would
prefer to use CDI as it is known to work in classic Spring/EE world
and
OSGi. Instead we should focus on bringing the full support of
Enterprise
style annotations to the OSGi world.
Initial Setup for a new OSGi Bundle Project
Instead of a parent POM I think it would be much more beneficial to
work
with a BOM (Bill of Material) for easier development, especially when
working with std. CDI annotations plus some extra PAX-CDI ones. Maven
Archetype are actually good enough to create an initial structure
for a
maven project.
The big benefit of the spring-boot approach is to actually have a
bunch of
different BOMs that can be used to add certain functionalities to the
project, aka spring-boot-*-starter.
To start a karaf-boot I think we should first try to have a karaf:run
available as maven plugin.
The microservice dance
actually it's just add a rest-service on top of a OSGi service,
that's all
that is needed in Karaf.
Right now I'm not in favor of any certain framework. CXF seems a bit
bloated but is known to work, but requires blueprint.
Jersey, I've seen that to be working with "plain" OSGi. A bit of
polishing
and it should be quite easy to use, especially with CDI at hand.
But it needs more to dance the microservice dance, you need "small"
containers ... which is quite contrary to the way Karaf and OSGi in
general
is working with services.
But this is the point I think the karaf profiles come in handy. You
don't
need a full blown Karaf, just a basic infrastructure with your own
Bundle,
might as well ignore the shell. In the end dump that into a docker
container and if you need to do a bugfix do it the "docker" - way.
spring-boot brings it all in one go
karaf-boot should do the same, but actually I fear we do more then
needed.
For a new Project setup I'd rather would like to see different
karaf-starter-* BOMs and a karaf:run maven plugin
Some more docuementation for the profiles of Karaf could also be
helpful
:D
to build minimalistic karaf instances runnable in docker containers.
Regarding the karaf:run it might be interesting to "re-activate" the
pax:run maven plugin to run nicely with a karaf instance, or use it as
foundation for the karaf:run maven plugin.
So in the end, do we really need all this?
I'm not so sure, but we surely need an easier "to use" approach.
Therefore we should first focus on having easier setup of bundle
development.
-> karaf-boot-starter-* BOMs should take care of that
-> karaf:run should make it easier to have a running container
Do we need new annotations? I can't see that yet.
Instead we should/could focus on the following:
a) make sure DS also is capable to work with JPA/JTA and some other
enterprise annotations
b) make sure CDI works with runtime JPA/JTA annotation smoothly
c) provide more demos and archetypes with OSGi and CDI annotations
regards, Achim
2015-09-10 20:41 GMT+02:00 Jean-Baptiste Onofré <[email protected]>:
Thanks Milen,
it's an open place to discussion. We just share standpoints and
opinions:
that's the key part !!!
My goal is to give more traction on Karaf by providing easier
We all provide valid points, but I think we are not the most
setted to
argue as we are deeply involved in OSGi and Karaf. The karaf-boot
proto
came when discussing with new Karaf users, coming from "outside"
of OSGi,
or people that decided to use spring-boot (even if they like a lot
Karaf),
just because it's easier. It's hardly frustrating for us as we
just need
some tooling to provide even more traction. On the container side, I
think
Karaf is already great, and answers all needs. The part where we
should
improve what we deliver is around developer tooling: easier,
faster, key
turn.
If karaf-boot will be a success, I don't know (who knows ? ;)). But
anyway, it brings points, questions, and identify some missings in
the
current picture.
My $0.01 ;)
Regards
JB
On 09/10/2015 08:02 PM, Milen Dyankov wrote:
Well I was just referring to your example but I get your point. Which
reminds me of EnRoute <http://enroute.osgi.org/> project which
despite
the
big names and the most popular OSGI build tool behind it, doesn't
seem
to
get as much traction as I expected!
That said, I really admire your enthusiasm and wish KarafBoot can be
more
successful that that. I'm not trying to discourage you! Just it
seams
what
you are after is something that other people have tried already with
questionable success.
Best,
Milen
On Thu, Sep 10, 2015 at 7:22 PM, Jean-Baptiste Onofré
<[email protected]>
wrote:
And how to you deal with jpa, jta, rest, etc with SCR annotations ?
Regards
JB
On 09/10/2015 07:16 PM, Milen Dyankov wrote:
So correct me if I'm wrong but if I get the sample you provided
in the
first mail and replace:
- the parent pom with "maven-bundle-plugin"
- @Bean with @Component
- @Init with @Activate
wouldn't that have the exact same end result? I mean it obviously
differ
in
terms of what gets generated (Blueprint vs DS) but form end user
perspective there is no difference, right?
On Thu, Sep 10, 2015 at 6:55 PM, Jean-Baptiste Onofré <
[email protected]>
wrote:
Hey Milen,
Actually, there's too part:
1/ karaf-boot-starter will do the ready to start artifact,
embedding
karaf, but it's another point
2/ the value of karaf-boot annotations and plugin is first to
simplify
the
bundle/artifact ready to be deploy-able into Karaf (generate the
"plumbing"
easily for developers).
Regards
JB
On 09/10/2015 06:50 PM, Milen Dyankov wrote:
" ... that you deploy in Karaf ..."
OK may be I misunderstood the concept. I thought the result is
standalone
executable JAR, thus my comments above. If on the other hand
I need
to
install Karaf and then deploy my services into it I really
don't see
how
it
differs form what people are doing now?
I'm sorry if I'm not making much sense. I didn't have the
time to
experiment with your code and samples so may be I'm missing an
important
peace here.
Best,
Milen
On Thu, Sep 10, 2015 at 6:27 PM, Jean-Baptiste Onofré <
[email protected]>
wrote:
Allow me to disagree: Karaf is a perfect container for
microservices.
Image to create a microservice (using karaf-boot) that you
deploy in
Karaf
and use such service in another microservice, all wired with
OSGi
service
and Karaf: we leverage OSGi/Karaf as a microservices container.
But even without talking of microservices, new developers to
Karaf
(and
OSGi generally speaking) are frustrated by the effort on non
business
code
to do (I have to write an Activator, or a descriptor, etc,
etc).
So, a tooling to simplify this is still a valid addition IMHO.
Regards
JB
On 09/10/2015 06:23 PM, Milen Dyankov wrote:
I might be wrong but I think the whole success of SpringBoot
(apart
from
having the "Spring" in it) is the microservices hype!
it's quick and easy but most usecases follow the "create
one (or
very
few)
service(s), pack them as single executable and access them via
REST"
pattern. We can obviously do the same with OSGi and Karaf in
particular
but
personally I think this makes absolutely no sense. In such
approach
one
in
not benefiting form OSGi almost at all. Honestly speaking I
would
argue
that if one does not understand how OSGi service layer works
(regardless
of
the framework used to register/access services) it makes no
sense
to
use
OSGi at all.
Just my 2 cents!
Regards,
Milen
On Thu, Sep 10, 2015 at 6:08 PM, Christian Schneider <
[email protected]> wrote:
I already created such a maven plugin in aries. The user
can use
standard
CDI and JEE annotations and the result is blueprint xml.
How is the new approach different / better?
Why should it be good for the developer to move away from
well
defined
standard annotations and use custom annotations that bind
him to
karaf?
I mean if this is created by the spring guys I know they
want to
catch
people by perceived simplicity and then make sure to make it
difficult
to
switch. As an open source comminity I do not know why we
should
do
something like this.
Abstracting away from frameworks just means you create
another
layer
that
people then also have to learn. There were some cases in
the past
where
this make sense because the underlying frameworks sucked
(like
JEE
2).
This
is not the case today though I think.
What kind of use case do you have in mind? Every project
starts
small
but
it needs to be able to grow then. You can not start with
custom
annoations
and then tell people to later switch to something else
when the
project grows. I think it makes more sense to make it
easier for
people
to
use the standard annoations and use the right dependencies.
If we simply provide a tooling that makes it easy to start
with
SCR
or
blueprint we provide much more value for people as thery
can then
grow
without any breaking changes.
Christian
Am 10.09.2015 um 17:46 schrieb Jean-Baptiste Onofré:
Because all these annotations are runtime: here we talk about
tooling
at
build time.
More over, the purpose is to provide more high level
annotations,
which
abstract actual annotations/frameworks that we can use under
hood.
The purpose of centralizing all in karaf-boot is to have a
central
project: the developer just use karaf-boot, it doesn't
really
know
what
technologies are involved behind the scene.
For instance, in spring-boot, they use activemq, jersey,
etc,
but
all
from spring-boot. The developers don't know a rest
service use
jersey
for
instance, it's completely abstracted.
Again the purpose is to simplify life for developers:
splitting
the
annotations in different projects introduces complexity (at
least
to
find
the dependencies and core import packages).
If an advanced developer wants to use CDI, SCR, etc, he
can of
course.
Regards
JB
On 09/10/2015 05:40 PM, Christian Schneider wrote:
I am not really enthusiastic about duplicating
functionality of
cxf
or
aries. Aries supports a very nice approach for
injections, jpa
and
jta.
Why should it make sense to recreate that?
Aries blueprint also has annoation support even in two
flavors
(CDI,
custom). How does the new approach interact with this?
Instead I propose we create support for such annotations
in the
respective projects (where they are missing) and
concentrate on
karaf
as
a container not an application development framework.
By leveraging the existing frameworks we profit from
their own
development teams. Whatever we recreate will have to be
developed
by
the
very few resources of the karaf team.
Christian
Am 10.09.2015 um 16:53 schrieb Jean-Baptiste Onofré:
Hi Guillaume,
thanks for your feedback.
I fully agree about providing more high level annotations
(it's
what I
do with @jpa, @rest, @soap, @jta annotations).
I agree that the current annotations are too low level,
and
blueprint
"oriented". I just move forward a bit with the current
codebase,
just
to illustrate karaf-boot usage in the samples.
But again, you are right, and I will create a new
annotations
set.
One of the purpose of karaf-boot annotations is to
"abstract"
the
actual code/artifact that we generate. So, if now we
generate
blueprint, without changing the karaf-boot annotations, we
will
be
able to generate something else (why not SCR, etc).
I agree with a BOM, but I think it's interesting to
provide
both:
- providing a ready to use parent pom allows developers to
create
a
very simple pom.xml where all plugins and dependencies are
already
defined
- for more advanced devs, they can create their own
pom.xml
starting
from the BOM or archetype.
Thanks again for your feedback !
Regards
JB
On 09/10/2015 04:44 PM, Guillaume Nodet wrote:
I like the idea.
For the annotations, we need to keep really high
level. The
annotations in
the code base right now are much too close to blueprint.
I think we need to grab a small enough subset so that the
annotations
are
easy to understand for beginners and without any
ambiguities,
even
at
the
cost of features.
For example, I think we should restrict to constructor
injection,
so
that
we don't have any bind / rebind / init methods. We
simply
need
an
optional
@Destroy. In case the dependencies change at runtime,
simply
destroy
the
bean / service and recreate it the dependencies are
still met
after
the
change.
If blueprint is to be hidden completely, we may find a
better
alternative
in SCR or even Felix Dependency Manager, but it does not
matter
too
much
for now.
I agree with the idea of using a BOM instead of a
parent if
possible. I'm
not very familiar, but this is less invasive.
The real problems will come with the support of higher
level
annotations
for JAXRS, JPA, etc...
Not really sure how to handle those yet...
2015-09-09 16:32 GMT+02:00 Jean-Baptiste Onofré <
[email protected]
:
Hi all,
I worked on a prototype about Karaf Boot.
Let me give you some backgrounds and discuss about
that all
together.
Why Karaf Boot ?
----------------
When you develop artifacts (bundles) to be deployed in
Karaf,
you
can see
that the actual time that you spend on your business
code is
finally
largely less important that all the plumbing effort
that you
have
to
do
(writing OSGi Activator, or blueprint/scr descriptor,
etc).
It means that your "go to market" is longer, and we
should
provide
something that allows you to focus on your code.
Even if SCR annotations is a very good step forward,
some
use
cases
are
not so easy to do (JPA, JTA for instance).
And anyway, you have to prepare your pom.xml with
different
plugin
and
dependency.
Moreover, when you have your artifacts, you have to
prepare
Karaf
container, and deploy those artifacts there. Even if
it's
"container"
approach is the most important for me, we can give
even more
flexibility by
providing a way to embed and prepare Karaf in a ready to
execute
jar/artifact.
What is Karaf Boot ?
--------------------
Karaf Boot provides four components:
* karaf-boot-parent is the Maven parent pom that your
project
just
inherit: that's all ! All plugins, dependencies, etc are
described
in this
parent, you even don't have to define packaging as
bundle,
standard
jar is
fine.
* karaf-boot (coming with karaf-boot-parent) provides
annotations
that you
use directly in your business code (like @Bean,
@Service,
@Reference,
@Inject, etc): again, your focus on your code,
karaf-boot
deals
with
the
plumbing.
* karaf-boot-maven-plugin (coming with
karaf-boot-parent)
scan
the
classes
and generate a blueprint XML. For now, I'm using
blueprint
generation
(because we can cover lot of use cases, for instance,
I plan
to
provide
@rest annotation that will generate blueprint XML
with cxf
jaxrs
server,
etc).
* karaf-boot-starter is the module providing a
convenient
way
to
embed,
configure and bootstrap Karaf.
Just to illustrate this, let's take a look on the
karaf-boot-sample-simple.
The pom.xml is really simple:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
<modelVersion>4.0.0</modelVersion>
<parent>
<groupId>org.apache.karaf.boot</groupId>
<artifactId>karaf-boot-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
</parent>
<artifactId>karaf-boot-sample-simple</artifactId>
<version>1.0.0-SNAPSHOT</version>
</project>
You can see, the only thing that the developer has to
do:
define
karaf-boot-parent as parent pom. That's all.
Now, in the code, you have just one bean that we want to
run:
package org.apache.karaf.boot.sample.simple;
import org.apache.karaf.boot.Bean;
import org.apache.karaf.boot.Init;
@Bean(id = "simple-bean")
public class SimpleBean {
@Init
public void simple() {
System.out.println("Hello world");
}
}
You can see the @Bean and @Init karaf-boot
annotations. The
karaf-boot-maven-plugin will generate the blueprint
descriptor
using
this.
Current Status
--------------
I pushed Karaf Boot structure there:
https://github.com/jbonofre/karaf-boot
It's a mix of rewrapping of existing code (from aries,
pax-exam,
etc) and
additions.
I created the annotations, I'm now working on the
karaf-boot-maven-plugin
based on Christian's work in aries (I'm actually
scanning
the
boot
annotations now, and generating the XML).
I will push new changes later today and tomorrow.
Open Questions
---------------
* For now, I would prefer to be 'artifacts' and
'resources'
generator: I
think it's better than to depend to a feature running in
Karaf,
but
it's
open to discussion.
* I'm now generating blueprint. Probably native OSGi
or scr
generation can
make sense.
* I'm generating bundles: thanks to the Karaf4 features
resolver,
as
the
bundles provide requirements/capabilities metadata, I
think
it's a
good
start. However, maybe it's worth to be able to create
features,
kar,
profile.
Thoughts ?
Thanks,
Regards
JB
--
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
--
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
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
