karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [DISCUSSION] Karaf Boot
Date Thu, 10 Sep 2015 21:58:46 GMT
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é <jb@nanthrax.net>:

> 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é <jb@nanthrax.net>
>> 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é <jb@nanthrax.net>
>>>> 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é <
>>>>>> jb@nanthrax.net>
>>>>>> 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 <
>>>>>>>> chris@die-schneider.net> 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é <
>>>>>>>>>>>>> jb@nanthrax.net
>>>>>>>>>>>>>
>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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é
>>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>
>>>>>>>> Jean-Baptiste Onofré
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message